Web designers have been using the <table> element type to achieve layout since it existed, as it is convenient and highly flexible. But it is also plainly wrong to do so. Let's take a good old 3-column layout as an example, with a rich navigation menu on the left, advertising on the right, and the main text in the centre.

This is bad for the following reasons:

• It ties items of content to a particular style, which might not be suitable for all rendering environments. In particular, it forces the sections to be laid out side-by-side, and so its minimum width is the sum of the columns' minimum widths. This is going to be greater than the maximum of those minima, so the page strains even more to fit into a narrower environment,

• Even if there is only one column, the text will try to fill the column rather than the window. If the column happens to contain something that can't adapt by slimming to fit (e.g., a wide image), it will force the text to its width, which will then require horizontal scrolling to be read.

• Even if the <table> isn't rendered as a table (e.g., through lack of support), the ordering of the basic content is still there, as determined by the goals of the intended layout. In the example, the page appears to begin with a huge amount of navigation, then the content follows some screenfuls down. Getting the table right has imposed a certain ordering on the underlying markup which is unsuitable when not interpreted as a table.

• It's also potentially bad in a non-visual environment. Again, a certain order has had to be chosen to make the table work visually, but that order might not suit a different medium. From HTML 4.01, section 11.1:

  Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media.

  If an aural browser has any support for tables, it must assume that the three elements of the table are somehow related to each other in a certain order, and will try to express that. This can then confuse the listener, who wonders why such significance is placed on their actually rather arbitrary ordering.

  • WebAIM: Creating Accessible Tables — Content Linearization
    How <table>s have to be used for layout carefully

• Finally, there is no robust way for a browser to make an intelligent decision about whether a <table> is intended to represent a real table or just to do layout. Therefore, it cannot selectively enable and disable table support on a per-table basis. However…

  • WAVE 3.0 - Web Accessibility Versatile Evaluator
    This tool apparently has a way to determine whether a <table> is being used for layout. Maybe real tables tend not to have <Hn> elements in them…?

  I'm also trying out a client-side Greasemonkey script to identify layout tables by detecting the summary attribute (which a layout table could never reasonably have) and the presence of <Hn> elements.

My alternative advice is to not use a <table> for layout – or, indeed, for anything other than real tables. Instead, assume a possibly non-visual medium where CSS is disabled, then set out the page in a usable and sensible way in that medium, then get your visual CSS to apply your chosen layout — as one is supposed to.

Unfortunately, CSS isn't quite rich enough to give the full flexibility of <table>, and you're forced to apply lots of benign <div>s and <span>s, producing a mess possibly with no satisfactory result. You end up going back to <table> for layout because you can find nothing better at the moment.

However, there are features in the pipeline (Media Queries and Template Layout) which should be able to solve the problem:

• Template Layout [formerly Advanced Layout] will allow the content of the page to have any ordering or structure that is convenient for a basic rendition (i.e., without CSS, etc.), while the appropriate stylesheets, when applied, will effectively re-order the content into a tabular layout more aesthetic for the current medium.

• Media Queries will allow you to use different CSS-specified layouts for variations of the same medium, e.g., wider or narrower windows.

• Media Queries
  Choosing presentation to suit the medium
• CSS Template Layout
  A proposed layout method completely separate from HTML

Combine these two features, and you can enable a popular multi-column layout only when sufficient space is detected, defaulting to a simpler linear layout in smaller windows. You would structure your HTML very plainly:

<body>
  <div id="head">
    <!-- Heading and short navigation -->
  </div>
  <div id="content">
    <!-- Main content -->
  </div>
  <div id="nav">
    <!-- Extensive navigation or sitemap -->
  </div>
  <div id="ads">
    <!-- Advertisments -->
  </div>
</body>

Then you would apply a width-hungry layout on the condition that space was available:

@media screen and (min-width: 80em) {
  /* This section is disabled if Media Queries
     are not available. */

  body {
    /* We need all of the space we've detected. */
    max-width: none;

    /* Lay out as three columns with a banner
       heading. */
    display: "aaaaa"
             "bcccd";
  }

  #head    { position: a; }
  #content { position: c; }
  #nav     { position: b; }
  #ads     { position: d; }
}

Assuming the proposals don't change too much, you can start using these features now. If you design your page to remain usable even when they're not available (e.g., by assuming a narrow window when the media query isn't understood, as above), you'll still get your message across. If they are available, they're a bonus.

If you're not satisfied expressing your layout using these features (e.g., because support is so poor), don't even try — it's not a job that HTML is supposed to tackle, and CSS at version 2.1 is not up to it.

I sincerely hope that W3C will push forward Template Layout and Media Queries, so that browsers can start implementing them effectively, and that designers can have something better to hand than abusing <table>. If that seems like a vain hope, then it damn-well shouldn't be!