There’s a faint tendency in my work to operate in threes. I wrote a theory book, a reference book, and a practical book, for example, even referring them to the three legs of a stool. (Okay, so I’ve written more since then.) Hopefully, this will serve as the third of three posts on tables and layout, and not the third of more than three. I have other things I want to write about that have been delayed, and honestly, I grow weary of tromping the same ground again and again.

Brad Bice pointed out that my example markup could be noticeably reduced in size by doing the following:

That brings the CSS approach roughly into line with the weight of the table-based approach, which is good. That still leaves us with the larger problem that Explorer still doesn’t support the application of table-related display values to non-table markup, so the layout will completely fall apart in IE/Win, which is bad. I suppose you could script your way around the problem, a la IE7. I wonder how you’d account for the lack of things like rowspan and colspan, though. CSS doesn’t offer anything comparable.

There were a few responses to the effect of “what Eric fails to say is that table elements already have a predefined meaning”. True, I failed to say that, mostly because I didn’t think it was important to bring up. I think it’s fairly safe to assume that if you’re worrying about any of this stuff, then you’re going to try to use semantically appropriate elements when you can. However, if you accept that there are times when a grid layout system is needed, then you have to accept that need will override any concerns about defined element meanings. In other words, the defined semantics of table markup are important, but they aren’t important enough to block the use of table markup when it’s needed for layout purposes.

Some would say that if you can’t accomplish your design without violating markup semantics, then you should create a different design, one that doesn’t require the use of table markup. That’s one of those “you can choose any color you want as long as it’s black” arguments that just make me sadly shake my head. There’s no argument that will change that kind of thinking: it rejects reality in favor of internal consistency. If that works for you, great, but I can’t operate that way. We’ll just have to agree to disagree.

Then there were the responses that ran something like “okay, so tables are necessary for a few things, but for almost every type of Web design you don’t need to use tables”. Yes. I said that. I said it several times, in fact, in different ways. Maybe that was a mistake. So, if I may, allow me to summarize the points I’ve apparently been obscuring over the past few days.

In the vast majority of Web design cases, you can accomplish your layout without the use of table markup, and you can do so in today’s browsers. This applies even to most layouts that appear to be grid-based at first glance.

There are a few cases, very rare ones, that require grid-driven layout where all the grid pieces line up both horizontally and vertically, both side to side and top and bottom, and the contents of the pieces have dimensions that cannot be predicted in advance.

At the current stage of the Web’s evolution, such layouts require table markup if you want the design to work as intended in Explorer as well as more recent browsers.

The table markup used in such designs can and should be very light-weight, and use CSS for presenting all of the visible content within the table. The table itself can also be styled using CSS for the most part, although row- and column-spanning still has to be done at the markup level.

From this point on, anyone who uses these posts to claim that I’m saying tables should always be used for layout is either not paying any attention, has an agenda to promote, or both. Probably both.