Rows and inputs: tables and forms

Read it inside out: cells sit in rows, rows sit in the table. The browser draws the grid for you - column widths, alignment, all of it. Your only job is to put the right content in the right cell, one row at a time.

<table>
  <tr>
    <th>Language</th>
    <th>Job</th>
    <th>Born</th>
  </tr>
  <tr>
    <td>HTML</td>
    <td>Structure</td>
    <td>1991</td>
  </tr>
  <tr>
    <td>CSS</td>
    <td>Style</td>
    <td>1996</td>
  </tr>
</table>

• th is not "bold td". It declares "this cell names the others" - machines lean on that claim, so make it honestly.
• Every row carries the same number of cells. Miss one and the grid quietly shifts - the table version of an unclosed tag.

A sighted reader scans a table in two dimensions at once. A screen reader visits one cell at a time - so the markup has to say what each cell means. Three additions do it:

• <caption> - the table's title, first thing inside <table>. Announced before any cell, so listeners can skip tables they don't need.
• <thead> and <tbody> - name which rows are headers and which are data. <tfoot> holds totals.
• scope="col" on column headers, scope="row" on row headers - now every data cell can be announced with its full address: "HTML, Born, 1991".

<table>
  <caption>Languages of the web</caption>
  <thead>
    <tr>
      <th scope="col">Language</th>
      <th scope="col">Job</th>
      <th scope="col">Born</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">HTML</th>
      <td>Structure</td>
      <td>1991</td>
    </tr>
    <tr>
      <th scope="row">CSS</th>
      <td>Style</td>
      <td>1996</td>
    </tr>
  </tbody>
</table>

Here is the diagram above as living markup - a monitoring table any data team would recognize. Every technique from Part 1 in one place, plus <tfoot> for the totals row.

<table>
  <caption>Pipeline health - last 7 days</caption>
  <thead>
    <tr>
      <th scope="col">Pipeline</th>
      <th scope="col">Runs</th>
      <th scope="col">Rows/day</th>
      <th scope="col">Status</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">orders_daily</th>
      <td>7</td><td>1.2M</td><td>healthy</td>
    </tr>
    <tr>
      <th scope="row">events_stream</th>
      <td>168</td><td>40M</td><td>healthy</td>
    </tr>
    <tr>
      <th scope="row">crm_sync</th>
      <td>5</td><td>80k</td><td>2 failed</td>
    </tr>
  </tbody>
  <tfoot>
    <tr>
      <th scope="row">Total</th>
      <td>180</td><td>41.3M</td><td></td>
    </tr>
  </tfoot>
</table>

The decision is the same one you make before reaching for a dataframe: multiple records, shared fields, comparison across them? Table. One field per item, order or grouping is the point? List (Session 2). Two smells tell you the choice went wrong:

• The single-column table - one field means it is a list wearing a table costume. Simpler markup, same meaning: use <ul>.
• The merged-cell maze - colspan and rowspan stacked three deep means the data is not really rectangular. Split it into two honest tables, or rethink the shape.

<form action="/where" method="post"> wraps the inputs. action says where the data goes when submitted; method says how (get puts answers in the URL - fine for searches; post sends them in the request body - right for anything personal).

The honest part: receiving form data needs a server. Your page on GitHub Pages (Session 6) has no server - so a form there either opens the visitor's email app (action="mailto:you@example.com", clunky but zero setup) or points at a free form-handling service. We wire that up in Session 6; today we build the form itself, which is most of the work anyway.

Every input gets a <label>, and the label's for attribute holds the input's id. That one wire does three jobs: screen readers announce the label when the input gets focus, clicking the label focuses the input (a huge tap target on phones), and your form documents itself.

<label for="name">Your name</label>
<input id="name" type="text">

<label for="topic">Favorite data topic</label>
<input id="topic" type="text"
       placeholder="e.g. dbt, DuckDB, evals">

One element, <input>, changes personality with its type attribute. Declaring the right type buys you the right keyboard on phones, the right picker widgets, and free validation:

<p>How do you take your data?</p>
<label><input type="radio" name="fmt" checked> CSV</label>
<label><input type="radio" name="fmt"> Parquet</label>
<label><input type="radio" name="fmt"> JSON</label>

<p>Extras - each checkbox is independent:</p>
<label><input type="checkbox" checked> Send charts</label>
<label><input type="checkbox"> Weekly digest</label>

<label for="d">Start date</label>
<input id="d" type="date">

Wrapping the input inside its label (as above) is the second legal way to pair them - no for/id needed. Handy for radios and checkboxes.

Sprinkle constraint attributes on inputs and the browser enforces them at submit time, with its own error bubbles, in the visitor's own language. Zero code:

• required - may not be empty. type="email" - must look like an address.
• min/max for numbers and dates, minlength/maxlength for text, pattern for regex-shaped rules.

Two more elements complete the kit: <textarea> for multi-line text, and <select> with <option> children for dropdown lists. A <button> inside a form submits it by default.

<form action="#" method="post">
  <label for="n">Name</label>
  <input id="n" type="text" required>

  <label for="e">Email</label>
  <input id="e" type="email" required>

  <label for="how">How did you find me?</label>
  <select id="how">
    <option>LinkedIn</option>
    <option>GitHub</option>
    <option>Search</option>
  </select>

  <label for="msg">Message</label>
  <textarea id="msg" rows="4"
    minlength="10" required></textarea>

  <button>Send</button>
</form>

• <fieldset> + <legend> - group related inputs under a caption. For radio groups it is the polite move: the legend ("How do you take your data?") gets announced with every option, so listeners always know which question they are answering.
• autocomplete - values like autocomplete="name" or "email" let the browser offer its saved answers. One attribute, dramatically faster forms - and an accessibility win for anyone who finds typing hard.
• <datalist> - attach a list of suggestions to a free text input via its list attribute: a dropdown that still accepts anything. The relaxed cousin of <select>.