Data table

A plain table is read. A data table is worked. The moment people need to reorder rows by a column, pick some of them out, and run something on what they picked, the markup stops being a block of prose in a grid and becomes a small application: header cells turn into controls that carry a sort direction, rows carry a selected state, the header stays put while the body scrolls, and a bar above or below the rows reports how many are selected and offers the actions that apply to them.

Two decisions separate a good one from a bad one. Sorting and filtering must run over the whole set, not over the page of rows that happens to be on screen, or the control quietly lies about what it did. And selection must survive whatever sorting does next: picking three invoices and then sorting by amount should leave the same three invoices picked, wherever they land. The demo here sorts a column and holds a selection across the reordering for exactly that reason.

The accessibility vocabulary is where the aliases come from. A static tabular structure is role="table", which is the name the ARIA Authoring Practices Guide gives it; once the cells are interactive and arrow keys move between them, the same markup becomes role="grid", documented as a separate pattern. That is why people say “grid” for this component and why “data grid” reads as the heavier end of the family: spreadsheet behaviour, inline cell editing, frozen columns, virtualized scrolling. Shopify’s Polaris calls its version an index table, and “list view” is inherited from desktop file managers, where it names the columned view rather than the icon one.

Reach for something else when the rows are not comparable across columns. If each record is a paragraph of mixed shapes (an avatar, a title, a timestamp, a status), a list of rows reads better than a table whose columns are mostly empty, and if there is only one attribute worth showing, a plain list is the honest answer.