Data tables (with sorting, filtering, etc.)

[LeaVerou]

From the preliminary State of HTML 2023 data, it looks like the missing element respondents seem to need the most (even more than tabs!) is …a humble data table:

(34,794 total selections spread across 12,472 responses)

For context, this was the question:

There have been a few issues discussing aspects of data tables:

• Native ability to text search tables #803 (no discussion)
• Native ability to sort a <table> #800
• Add the ability to show/hide table rows/columns in a <table> #799
• (Can’t find anything for filtering)

There has been some discussion about doing this in a new element (e.g. <datagrid>), or augmenting the existing <table> element. The former allows us to start from a clean slate and avoid the many warts of tables, but ultimately, I think progressive enhancement should prevail. Doing it by augmenting <table> also allows us to ship this as individual composable features, rather than one monolithic new element that will take years.

That said, there are relationships between them: Sorting would require some mechanism of specifying what value to sort by (otherwise we're either stuck with lexicographical sorting, which is rarely what you want, or parsing numbers from contents which is another can of worms), which filtering could also take advantage of.

In terms of the features discussed above, it seems that if we want to tackle from easiest to hardest, the order would be:

1. Show/hide columns (just a matter of allowing existing primitives to work together)
2. Sorting (well established UI conventions, minimal UI surface)
3. Searching
4. Filtering (requires a lot of UI, which to be useful needs to be stylable)

[jimmyfrasche]

Maybe as a start there could be an attribute added to th that hides the associated respective row(s)/col(s). That would simplify implementing 1 and 4, perhaps even allow it to be toggled with the invoker api.

[LeaVerou]

Issue: how to assign metadata to table columns?

@jimmyfrasche wrote:

Maybe as a start there could be an attribute added to th that hides the associated respective row(s)/col(s). That would simplify implementing 1 and 4, perhaps even allow it to be toggled with the invoker api.

This brings up an important general problem: a lot of these features require assigning metadata to columns. HTML has the <col> element for that, but it's fairly unpopular (used only in 0.35% of websites) and for good reason: it is a separate element, specified in a separate place, entirely disconnected from the columns it describes. It is only associated with columns sequentially, so it's easy for the association to get out of sync.

One solution would be to improve the DX of the <col> element, if we decide it's salvageable, for example:

1. Provide a way to associate with columns by identifier (name attribute?) so that it's not affected by reordering
2. Allow nesting <col> within <th> and then it's scoped only to the columns that apply to that particular <th>
3. ???

Alternatively, we could do away with <col> and figure out new paradigms for specifying metadata on table columns, such as:

1. Specify new column metadata on the corresponding <th>. The main issue with that is that not every column has a corresponding <th>. E.g. col groups with a single <th> may still need to specify different metadata about their columns.
2. ???

[bkardell]

Just linking up I know we have several isssues on this, here's one:

#800

[LeaVerou]

Just linking up I know we have several isssues on this, here's one:

#800

This is linked in the first post.

[jimmyfrasche]

There's also the headers attribute.

My thought with tying it to th specifically is that th already targets (groups of) rows or columns so it could deliver a lot of sophisticated behavior while encouraging correct markup.

[github-actions]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.