Tables? Oh, the horror!

May 15, 2004 2PM PST

Apparently there remains some confusion after my Thursday-afternoon rumination on the potential use of tables, as opposed to pure CSS-based layouts. I’m going to share some of my experience to help clear this up.

Some of the comments on this site were discouraging, it sounds like the original piece was interpreted to advocate laziness. Some of the replies on other sites perpetuated this interpretation, so once more, tables should be considered only with the proper education to use them responsibly. This means attention to accessibility, as well as offloading all other presentational attributes to the CSS, leaving the simplest of layout-structural tables.

The point I was clear to make was that I am not talking about dropping CSS and going back to 1997-era coding techniques. Standards-based coding practices aren’t so fragile that a small injection of common sense and/or objective analysis will excuse full-scale dismissal, so let’s not pretend like the world is going to use this discussion as a springboard to revert; chances are the people who would are doing so anyway.

I am suggesting merely that in some cases, it might make sense to explore a layout table. Again, I do not mean three-level-deep nested tables rife with the required colspans. I mean a light table with two or three columns to keep a layout together, sans all other presentational markup. This is what I have in mind:

<table cellspacing="0">
 <tr>
  <td>
    (Column One)
  </td>
  <td>
   (Column Two)
  </td>
  <td>
   (Column Three)
  </td>
 </tr>
</table>

The cellspacing remains simply because the CSS equivalent (margin: 0 applied to <td>s er, that is, border-spacing is what I was looking for here [thanks to those who clarified]) isn’t well supported. The <tr> remains merely because it’s still required. The important piece of this table is that three columns keep the layout together, as expected.

Why am I saying this might be preferable over floats or absolute positioning? First of all, the pitfall of absolute positioning is that placing a footer below the three columns is near impossible. Creating this layout using absolute positioning causes a reliance on one of the columns to be longer than the others; given a dynamic site, if you build this reliance in to your work you’ll get bitten by it sooner or later. Pages will start looking funny when a column grows longer than intended, as the content area grows shorter.

Floats, then, are the more reliable way to achieve your three columns. Except that they have their own glitches too. The most popular browser on earth, IE6, has spectacularly inconvenient error-handling in this regard. Anyone who has built more than one or two sites with floats knows what I’m talking about: a placed element too wide for its container, be it an <img> or a <pre>-wrapped chunk of text, will cause the parent element to grow to contain it. Other browsers let the content overflow to no ill effect other than a bit of overlapping, but because the parent element resizes in IE, the column gets bumped all the way below the others and you have a situation no one is happy with.

I’m hearing contention against the claim that proper CSS design is hard. Okay, fair enough, learning the basics isn’t terribly difficult. Learning the basics well so that you know how to keep the above scenarios from happening is a different matter, and requires browser-specific tricks that go against the nature of what CSS is meant for. Anyone can build a fixed-pixel layout in CSS with known font sizes, that’s easy stuff. Build me a liquid three column layout that allows for text scaling in Internet Explorer, and watch how easy it is to break by increasing your font size. Especially once the code leaves your hands. This is where it gets hard, folks.

Which brings me to my next point — working with other team members and clients. I mentioned this on Thursday, but it bears repeating. There are many different working conditions out there which don’t match your own. Assuming because you know how to maintain your layout integrity with CSS that everyone else can is a leap of faith, or the by-product of a cozy environment that doesn’t test your endurance.

I’ve worked in settings both where I’ve dictated all markup start to finish, and where I’ve had to rely on others to continue producing valid, well-formed, structural markup. The first scenario makes it dead simple to assure a site’s continued abstraction of presentation, the second does not. Even if you have the most responsive team members, you’re still limited to what they know. Like it or not, many people look at markup from a presentational standpoint, ie. “this form element needs to sit below this label, insert <br /> here.” Either you have to clean this up after them, or more likely, you’ve moved on to other projects by this point and don’t have the time to.

A little bit of presentational markup isn’t going to hurt things, and probably, alone, isn’t a justification for a structural table. What is is how likely the chances are that anyone not-you is going to trigger something like the IE float problem mentioned above. Anecdote: I built a site earlier this year that worked fine with my sample data. When passed off to the client for implementation, breakage occured. The culprit turned out to be a small piece of non-semantic markup that was used in various spots over years of accumulated content. I was not contracted to clean up the content; the client had no desire to fix years worth of material. The seemingly easiest fix was to throw the page into a structural table. I knew a CSS hack or two to work around this, and we didn’t end up using it after all; but would everyone?

Let’s also not forget that we’re talking amongst people who have spent a lot of time working with this stuff, and that there are those who haven’t. For a beginner transitioning to CSS-based design, a few iterations of table layouts that move more and more presentation to the CSS is one of the better ways to learn. Even once the intricacies of positioning are fully understood, it takes time to become comfortable with them. Let’s cut these folks some slack; their continued use of a table is just fine if they’re continuing their education so one day they don’t have to.

And finally, let’s talk semantics. I hate discussing semantics, personal interpretations (unavoidably) shade the conversations. But let’s do it anyway. This is the point that’s going to get me into the most trouble because everyone is going to have a different take, but I’m going to throw it out there. Using a table for tabular data is universally accepted as being proper use of a table. Which carries with it the assumption that the table is structural and not presentational in that case. Fair enough.

But if tabular data is structurally tabular, then what inherently (besides a fear of the past) makes a two- or three-column layout structurally non-tabular? Two columns invariably end up in a pair of <div>s, or a pair of <td>s. What makes the former structural, but the latter any less so? A pair of <div>s implies two distinct, separated blocks of structure; a pair of <td>s does the same, and carries with it the further implication that the blocks are structurally side-by-side columns. Two columns may be presentational to some, but they may be structural to others.

I’m not committed to the notion, but it’s something to think about. There are those who would advocate multiple nested lists (scroll down to Tantek’s technique) as a structural replacement for the <div>s we use today, so if there are two ways to look at semantic representation of data, there are just as easily three.

Anyway, at the risk of sparking a howl over the last point and ignoring what went before it, I’ll finish by saying this is based on the sum of my experiences in real-world situations. There are many factors at play here, and boiling this discussion down to “tables bad, CSS good” is counter-productive at best.

I’ll end with the contentious quote of the day, coming from Joe Clark:

If smart, informed people are using b or i, it’s because they have made smart, informed decisions to do so. We’re not slacking off; we’re not making a mistake; we’re not harming the grand ideals of semantics or accessibility. We’re not doing anything but using b or i.

Different argument, misappropriated quote, but similar sentiment. Semantics only get you so far; at some point, you have to compromise and just use the tools you have at your disposal.