Table-less Design

April 08, 2003 11PM PST

The bottom line: transitional, table–based layouts work, and will continue to, no matter how ugly a solution they seem. The table tag isn’t going anywhere due to the continuing (valid) need for tabular data, and let’s face it, we’ve long worked out the bugs in table–based design. We’re only beginning to knock off the bugs of the more popular CSS configurations.

This is an area where standards advocates shoot themselves in the foot. “Code for the future,” we say. “Drop the tables, and you’ll never look back. Er, no, I’m not sure why IE5 is doing that. Um. What was I saying again?”

Table–less design gets lumped into the standards argument as if the only way you can write valid XHTML is with divs. This is not intentional in many cases, but the overwhelming impression is that if you’re going to bother with validation, you’d better be using CSS positioning to build your document.

Which simply isn’t true. Well–formed tables are entirely valid markup for any flavour of XHTML 1.0. The code is always larger than it needs to be, and it looks horrible in alternative browser, yes. Anyone who has spent a bit of time gritting their teeth and figuring out how to throw together a CSS–based layout realizes that after the learning curve it’s a far more elegant and desirable way to build a document. But it’s not the only way.

Transitional layouts have the advantage of working in older browsers. Nobody in their right mind tests in a 3.x browser these days, but if you’re building an e–commerce site that gets even a few thousand 4.x visitors, you’d better be damn sure they have a way to buy from the site. It’s far less important to target users of web–enabled cell phones, for example, since they stand very little chance of buying a product based on a text–only screen.

Still, there are other ways. I recently built a table–free site for a small non–profit group. (they were getting free work out of me, they’d better not complain about my markup choices, after all) The original design was tested against the major standards–friendly browsers (IE 5/6, NN7, Opera 6, Mozilla), and then it was time to deal with the old, ugly Netscape. It was a mess, as you can well expect, but by moving key elements into an @imported .css file I was able to target NN4 a little more.

After shifting some text around, dropping some background colours, moving some images… it actually worked. It looked only vaguely reminiscient to my original concept, and as a design it didn’t hold up very well on its own. But the layout worked. Netscape 4 got one thing right, believe it or not: absolute positioning. With some creativity, this can be used advantageously to create table–free site foundations that work in almost every browser being used in the wild today. (see Craig Saila’s site for an example)

So it is possible to build table–less layouts that work back to 4.x browsers, if design can be compromised for that 2% of the market. In 2003, it’s awfully hard to make a case that 20% of a site’s budget should be spent on these browsers, 1.5% of the market, but some people still just don’t get it.

Today we have choices; we can go in either direction. Both ways are correct. CSS positioning is a far more elegant solution, and provides more flexibility for later upgrades and alternate browsers. Table–based design is a relic, but one that is tried and true, and remains valid markup. Both are perfectly justifiable in their own right, and will continue to be so for time to come.

(In response to Keith’s response to my response to another article…)