You don’t use HTML tables for layout. Every standards-based Web designer knows this.
As of June 2008, this notion is so deeply buried in the conventional wisdom about Web page design that just about nobody ever thinks about it anymore; the idea of using a table for anything other than Tabular Data is met with scorn and derision from developers. And so the lowly <table> tag sits alone in the lunchroom, friendless, with nobody to talk to except its perpetual hangers-on <td> and <tr>.
Now of course, we don’t use tables for layout at White Whale. Ever. How could we? It’d be like driving an SUV, listening to a Zune, or voting Republican— it’s something cool people just don’t do. We (as a company) couldn’t design a site with layout tables and look at ourselves in the morning.
But I don’t like conventional wisdom, and as a result I often find myself thinking about tables— in particular, how there are some things you can do with <table> that you can’t do with <div>, no matter how hard you try. (At least across all browsers, and without using Javascript.)
What makes it worse is that these are some REALLY, REALLY SIMPLE THINGS. Like attaching a footer to the bottom of the viewport, or the bottom of the content area, whichever is appropriate. Like displaying two columns of content, and having the width of the two columns be determined by whatever makes sense for the amount of content they contain. Like setting a content area at, say, 10% width, unless your content contains a word like “supercalifragilisticexpialidocious,” in which case the content area won’t get any narrower.
Now, I know not many people read this blog, but if this were a serious CSS design blog (which we modestly hope it someday may be), I’m sure we’d get commenters tossing out <div>-based solutions for all these cases. I am pretty good at CSS, but I’m certainly not a black belt, and it wouldn’t surprise me at all if there are some decent solutions out there. But here’s the thing—all this stuff is built into <table>. And all browsers get it. Automatically.
<table> is a relic from a simpler time, when there was a general idea that common sense ought to govern how browsers render Web pages. <div> is a creature of the present— all it knows is rules. It knows nothing of “common sense.” As a result, much of CSS design— even the high end stuff— becomes an attempt to duplicate in CSS behavior that comes naturally to a <table>.
Here’s a quick site I did last summer for a kickball league we started in Oakland. If you resize it a bit, making the page really small, really big, etc., you’ll see how there’s a 250px wide side column, a title at the top that changes color as it crosses the color line, and background images pegged to page bottom. I must have spent four hours getting that to work in CSS, without success; once I decided to use a table, I coded it in five minutes.
But of course, that’s a personal site; we could never have done that for a client site. Now, those of you who know us know that Donald is the most standards-obsessed Whale; he handles all our initial CSS buildouts once designs are approved. We often have conversations like this:
Jason: Why isn’t the buildout done yet?
Donald: Grrr! I’m having a hard time getting (insert awesome design feature here) to work in IE6.
Jason: Well, you know, you could use a table for that.
Donald: No I can’t.
Jason (knowing D hates when I ask this): Why?
Donald: Because tables aren’t accessible.
Jason: Are you suggesting that an audio browser isn’t able to interpret a one-row table? Do you suppose, then, that this page, which uses a table for layout, is inaccessible?
Donald: It’s just not best practices.
Jason: Well, if it can be rendered by a screen reader, and it works across all modern browsers, and actually involves less code than a CSS solution, how is that not best practices?
Donald: People will laugh at us.
Jason: OK, fine. But if we don’t get it solved by tomorrow afternoon, I’ll use tables and code it myself.
And then Donald stays up all night and figures it out.
The fact is, I’m fine with <div>; I just wish sometimes it had some common sense. And just like a former cigarette smoker might occasionally step out behind the house and indulge in the guilty pleasure of an old bad habit, I reserve the right to use tables occasionally in my own work.
You can follow any responses to this entry through the RSS 2.0 feed. Respond to this post.
We constantly waste time around this problem.
At this point, we use a table at the top .Master page level (.NET environment) to get a basic column structure, then resort to divs withing the columns.
Our alternative approach has been to create fixed-height divs for rows, then float “column” divs left within the row. This is really unpalatable since the row div isn’t smart enough to change it’s height to contain the columnar children.
Let’s get Donald to name his uppity CSS Druids, so we can force them to lay out the clean, simple, best practices which give us the control we need without having to resort to tables. If they can’t provide this answer, we should hang them…
Good luck with the blog.
Hi David, thanks for the comment.
Don’t get me wrong, there are definitely best practices out there that will allow precise layout control within a div-based environment. (100% height is the bugbear of standards-based design, but there are ways.) There are no tables in our new site for Berkeley Law, for example (preview: http://berkeleylaw.babywhale.net/).
The real problem is that this level of standards-compliance is hard to maintain when people use a variety of tools to maintain their sites. We’re moving toward an official position on this: the full-on div-based standards-obsessed buildout can only be executed in very constrained, autocratic authoring environments. If anyone’s using Dreamweaver to edit their site— which we fully support in situations where it’s already working— fancy div columns probably aren’t sustainable.
(There will probably be a Part 3 to this topic on the blog. Hell, there will probably be a Part 8.)
Keep in mind that anyone working with online WYSIWIG editors within a CMS will need to use tables to get the kind of results they want. It is really hard for non-geeks to handle special CSS codes to lay out tables well.
It CAN be done, but it really is still a pain. I’m like Donald (though not as badass for sure) and try to be pretty strict, and I really really try not to use tables in my own work but sometimes you gotta. Email is another place where you just HAVE to use tables to be sure the presentation is solid for all browsers.