Anatomy
- Header: The section at the top of the table that defines the data categories and provides context for the rows below.
- Header cell: An individual cell within the header that labels a specific column, helping users understand the type of data it contains.
- Row: A horizontal grouping of cells that represents a single record or entry in the dataset.
- Cell: The smallest unit in the table, containing a single piece of data at the intersection of a row and a column.
Usage Guidelines
When to use this component
- To present structured data that users can scan across rows and columns, often with tools like sort or filter to aid comparison.
- For datasets where patterns or relationships matter.
When not to use this component
- For simple views or single values that don’t require comparison.
- For narrative or unstructured content.
Best Practices
Use a table when you need to navigate through a lot of information and compare data among rows and columns.
Do not use a table when you need to display simple or non-comparative values. Consider a non-tabular format instead, like a list.
Place a table within a card component and use the card header if needed to provide context.
Do not use a table when there are columns where the cells are usually empty. Consider listing the items instead.
Do not display a table without content.
Table header
Table heads are built with short header labels that describe the data in their respective columns. These headers are additionally used to sort rows by the column data in ascending or descending order.
Keep headers clear and concise.
Do not misalign headers with their respective content in the column.
Display header labels in one line to avoid wrapping. Wrapping will misalign the header labels and make them harder to scan.
Do not sort values randomly. Sort data in an intuitive order, for instance, showing the most recently created items first. Rows will be re-ordered when the user updates the sorting parameters.
Table body
The table body refers to the sum of the rows and the content displayed within the table cells, such as text, numbers, or any other data type.
Include a textual indicator for empty cells, so they cannot be mistaken for data missing or failing to load.
Don't fill cells with long-form content like paragraphs or long lists.
Use the right alignment of the content to better scan and compare numbers, or at the last column of the table if there are actions in the row.
Do not use symbols such as "x", "ø" for empty cells as they might disrupt the experience for assistive technologies like screen readers.
Do not mix data in a column cell that isn't described by the column header.
Do not use a primary button in every table row.
General Component Behaviors
Selectable rows
Rows can be made selectable, allowing users to perform actions such as modifying or deleting multiple items in bulk.
Column width
By default, columns adjust dynamically based on their content and the available table space. This behavior can be modified: you can set a width to define a preferred size of the specific column (it won’t exceed that value but may shrink if space is limited), or a minimum width to ensure the column never shrinks below a certain threshold.
Sticky columns
The first and/or last column can be fixed when horizontal scrolling occurs, keeping key information such as identifiers, names, or actions visible at all times.
Loading
Table supports two loading states: Skeleton and Spinner with overlay. Read our loading pattern to understand when to use them.
Custom content
While tables default to text, any column can be customized to display rich or interactive content if necessary.
Responsive Behavior
Table can be horizontally scrolled, if the content exceeds the available width.
States
Row
Header cell
Variants
Default
Default data table.
Selectable rows
Data table with selectable rows
Loading
Skeleton
Spinner overlay
Known Gaps
- Table component will undergo a full design review to improve:
- Bulk selection, editable cells /row, basic behavior, etc
- Accessibility guidelines