Name	Status	Price
Landinator 9000 New	Completed	$300
Hammer	Waiting	$20
Computer	Processing	$500

<table class="table">
  <thead>
    <tr>
      <th>Name</th>
      <th>Status</th>
      <th>Price</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Landinator 9000 <span class="badge ~neutral">New</span></td>
      <td><span class="chip ~positive">Completed</span></td>
      <td>$300</td>
    </tr>
    <tr>
      <td>Hammer</td>
      <td><span class="chip ~urge">Waiting</span></td>
      <td>$20</td>
    </tr>
    <tr>
      <td>Computer</td>
      <td><span class="chip ~info">Processing</span></td>
      <td>$500</td>
    </tr>
  </tbody>
</table>

---

Overview

Tables are surprisingly hard to get right. The table element applies to the top-level <table> element and results in nice-looking (albeit somewhat opinionated) tables.

Tables are one of the few elements in a17t that are more complex than a single class. The .table selector specifies styles for thead, tfoot, tr, tbody, td, and th. It automatically also applies itself to <table> elements inside the .content selector.

Considerations

Responsiveness — As a UI element, tables generally don’t work well on smaller devices. (Just look at the Google Sheets app.) If a fluid mobile layout is important to you, consider using a card layout instead.

Width — This element by default is set to use all the horizontal space available to it. This is usually correct, but you can safely change the .table width and the content will automatically reflow.

Variants

Tables do not directly respond to tone variants; that information is simply passed down to child elements (e.g. chips).

Accessibility

Tables have complex accessibility requirements. For more information, consult this guide to WCAG standards for tables. While a17t encourages you to use a standard table structure through its selectors and default styling, the most valuable thing you can do is to structure your tables in a way that’s consistent with WCAG standards.

Examples

---