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):

Name Bananas
Tim 32
Paul 1
Stuart 100
Suzy 75

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:

  Mon Tue Wed Thu Fri Sat Sun
Tim 1 2 3 4 5 6 7
Paul 7 6 5 4 3 2 1
Stuart 100 100 100 100 100 100 100
Suzy 100 34 3667 3 19 20 21

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.

Included in: Accessibility, CSS, Design, Development, Web Standards, XHTML

Categories:

  1. Accessibility
  2. Agile
  3. Ajax
  4. Apache
  5. API
  6. Architecture
  7. Books
  8. Browsers
  9. CMS
  10. CouchDB
  11. CSS
  12. Design
  13. Development
  14. Django
  15. Email
  16. Events
  17. Gaming
  18. Grammar
  19. Hardware
  20. HTML
  21. HTTP
  22. Humour
  23. Idea
  24. Information Architecture
  25. JavaScript
  26. jQuery
  27. Lean
  28. Life
  29. Linux
  30. Literature
  31. Mac OS X
  32. Management
  33. Meme
  34. Microformats
  35. Monday
  36. MySQL
  37. Networking
  38. News
  39. Personal
  40. Photoshop
  41. PHP
  42. Process
  43. Python
  44. Reference
  45. REST
  46. Science
  47. SEO
  48. Server
  49. Site
  50. Sitepimp
  51. Social
  52. Spelling
  53. Syndication
  54. Testing
  55. The Future
  56. Thoughts
  57. Tools
  58. Tutorial
  59. Tutorials
  60. Typography
  61. UI
  62. UNIX
  63. Virtualisation
  64. Web
  65. Web Standards
  66. Widgets
  67. Wii
  68. Writing
  69. Xbox
  70. XHTML