To Table or Not to Table...

Posted Monday 16th May, 2005

Thanks to the wonders of XHTML and CSS, table based design is becoming a thing of the past. We’ve all discovered that, even though columns are easier to layout with tables, they damage our markup, annoy the search engines and play havoc with accessibility legislation. However, its also apparent that tables should be used in web sites to control tabulated data. But what defines tabulated data?

Let’s take a look at some good XHTML table markup:

<table cellspacing="0" id="toTableDemo1">
  <thead>
    <tr>
      <th scope="col">Name</th>
      <th scope="col">Bananas</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Tim</td>
      <td>32</td>
    </tr>
    <tr>
      <td>Paul</td>
      <td>1</td>
    </tr>
    <tr>
      <td>Stuart</td>
      <td>100</td>
    </tr>
    <tr>
      <td>Suzy</td>
      <td>75</td>
    </tr>
  </tbody>
</table>

This would display the following (with a little help from CSS):

By incorporating a thead section we have defined a title for each column: making it easier to read for normal users and also for those using text readers.

Unfortunately, not all tabulated data can be presented in a way that allows us to clearly seperate the header, body and footer sections using the thead, tbody and tfoot tags. A good example of this would be tabulated data that requires a legend down both axis of the grid. This would be similar to a spreadsheet in design. Below is an example:

And the markup:

<table cellspacing="0" id="toTableDemo2">
  <tr>
    <th scope="col">&nbsp;</th>
    <th scope="col">Mon</th>
    <th scope="col">Tue</th>
    <th scope="col">Wed</th>
    <th scope="col">Thu</th>
    <th scope="col">Fri</th>
    <th scope="col">Sat</th>
    <th scope="col">Sun</th>
  </tr>
  <tr>
    <th scope="row">Tim</th>
    <td>1</td>
    <td>2</td>
    <td>3</td>
    <td>4</td>
    <td>5</td>
    <td>6</td>
    <td>7</td>
  </tr>
  <tr>
    <th scope="row">Paul</th>
    <td>7</td>
    <td>6</td>
    <td>5</td>
    <td>4</td>
    <td>3</td>
    <td>2</td>
    <td>1</td>
  </tr>
  <tr>
    <th scope="row">Stuart</th>
    <td>100</td>
    <td>100</td>
    <td>100</td>
    <td>100</td>
    <td>100</td>
    <td>100</td>
    <td>100</td>
  </tr>
  <tr>
    <th scope="row">Suzy</th>
    <td>100</td>
    <td>34</td>
    <td>3667</td>
    <td>3</td>
    <td>19</td>
    <td>20</td>
    <td>21</td>
  </tr>
</table>

As you can see, I’ve defined the legends using the th tag. This method is less confusing than using the thead section in this particular instance.

Now that we have two examples of good table markup in XHTML, let’s think about the role of the table on an XHTML page. Functionally, the table makes the data easier to read, allowing us to follow the rows and columns easily and associate the values with the relevant headers. With the design, the table also allows us to make data more presentable, which also makes it easier to read. Ultimately then, the XHTML table is simply about data presentation.

So what have I been leading up to? Recently I was arranging an XHTML form for a client when I found myself looking at the presentation from a different angle. Normally I would try and arrange the form fields within labels, those labels in turn would then be arranged within fieldsets. I can then arrange the fieldsets, labels and fields using floats and absolute positioning in the CSS to cobble together a nice table-less design. Of course, in the old days, I would have slapped the whole lot in a table and not thought twice about it. These days, however, table based design is, as we discussed earlier, frowned apon. But in this context, is it really so bad?

Imagine we lay out our form like so (here’s the markup followed by what it would display):

<form>
  <fieldset>
    <table cellspacing="0" id="toTableDemo3">
      <tr>
        <th scope="row">
          <label for="input1">Name:</label>
        </th>
        <td>
          <input id="input1" name="input1" type="text"/>
        </td>
      </tr>
      <tr>
        <th scope="row">
          <label for="input2">Rank:</label>
        </th>
        <td>
          <input id="input2" name="input2" type="text"/>
        </td>
      </tr>
      <tr>
        <td colspan="2">
<input id="sub_form" name="sub_form"
type="submit" value="Submit"/>
</td>
      </tr>
    </table>
  </fieldset>
</form>

<table cellspacing="0" id="toTableDemo3">
  <tr>
    <th scope="row"><label for="input1">Name:</label></th>
    <td><input id="input1" name="input1" type="text" /></td>
  </tr>
  <tr>
    <th scope="row"><label for="input2">Rank:</label></th>
    <td><input id="input2" name="input2" type="text" /></td>
  </tr>
  <tr>
    <td colspan="2"><input id="sub_form" name="sub_form" type="submit" value="Submit" /></td>
  </tr>
</table>

As you can see, the labels are in th tags (because that is effectively what they are) and the inputs themselves are considered standard data - much the same as if you were entering data into a spreadsheet. This markup is not only logically valid but also allows us flexibility in design. However, I still find myself struggling to lay things out without using the table because something inside me feels dirty. Really dirty. And although I might like feeling dirty, the CSS Nazi in me is disgusted.

So what do you think? When laying out forms, are tables valid markup or nasty, dirty, filthy markup?

Edit: In reply to Stuart’s comment below, I have added the scope attribute to my th tags. This allows the browser or text reader to have a better understanding of the header.