Skip to: Navigation | Content | Sidebar | Footer

Weblog Entry

Table-less Design

April 08, 2003

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…)

Reader Comments

paul says:
April 09, 04h

i’ve coded my last half-dozen or so sites in mostly DIVs. i say mostly because i do still use tables within the DIVs if they make sense. even tho table-less design is “all the rage” designers/coders should still actually *think* about the solution they’re programming and which will work best. it sucks to just follow a trend because it’s a trend (even if the trend is a good one).

altho one trend i’ve fallen victim to on my new 230 site (launching soon) is using UL and LI tags for making navigation lists. i coded my nav using those, and just straight div tags, and it worked out to be half the lines of code needed. i didn’t just code it a new way bc it’s a new way tho, i tested it out against the old way first, to see how it held up.

but that’s just me, mr smartie-pants ;)

Dave says:
April 09, 05h

Maybe that’s what it is. Maybe it’s the blindly spewing of dogma about how evil it is to use anything but the latest specs from the W3, regardless of how well supported they are, that makes this whole argument so tedious.

Hell, I’ve seen opinions on evolt that say you should code for the latest nightly Mozilla build and force everyone to upgrade to use your site. (exaggerating a little, but not by much). It sure is easy to say when the only coding you do is for a personal site, but try dumping today’s latest into a content management system from 2 years ago that spits out crap code.

Still, daily practicality aside, I’m moving more into CSS-positioned design and I’m liking it. I’ve built only a few sites using nothing but, and so far the experience has been a good one. I positively relish the simplicity of the resulting XHTML at the end, it just looks nice.

But I can’t always go that route; CSS doesn’t always work. Even this site is still a mess of tables. The little logotype/links on the bottom right — that’s why. No way of vertically positioning it, other than a td align. How sad is that?

Dave says:
April 09, 07h

In thinking about this, I’ve tried to figure out why the whole issue gets me going to begin with. I mean, it’s a semantic geek thing that really isn’t going to change the world, right, just make our lives easier.

It’s because it’s a better way. It simply is. It’s far easier for us, as developers, and the whole portability thing is pretty cool too. (I have yet to really play with a wireless device and see how well the promise is delivered upon, though.) It’s just that tiny percentage running 1997 browsers holding the rest of us back from diving right in, which in 2003 seems almost inexcusable.

It’s also because I’m surrounded by people who just don’t have the first clue about any of this. They’re stuck in 1997 coding practices because they’re too lazy to learn anything about modern html, and it drives me freakin’ nuts.

So pardon any excessive ramblings on my part, because sometimes I just need to vent.

haze says:
April 09, 12h

the argument of filesize is an utter joke when used to justify the use of fowards or backwards compatible code.

any monkey can code. how well the person uses the technology (be it tables or divs) determines how lean their code is. ppl who code poorly will use divs inefficiently and spew out crappy, bloated products. professionally done code, even if its done with tables (or a mixture of the two), can be leaner in filesize.

chris (from was able to write a space invader game within 5 kilobytes. i couldnt write a space invader game within 5 megs… this has nothing to do with emerging technology or new compliancy, it has to do with THE MAN. is it the clothes that make the man? i hope not ;)

Dave S. says:
April 09, 12h

Naturally I can’t find it anywhere now that I’m referring to it, but I’ve seen the argument made that a couple of simple lines in a DIV translates to 50 lines of TABLEing. It was completely over-exaggerated to make the point, with far more table code than was necessary.

But I think it’s still a valid argument that in an overall sense, CSS positioning will result in smaller files. Bad coders abound, and they’re generally the sort of people who have learned only the bare minimum needed to throw together a site. I’ve had to work with a few, and for the time being anyway, they’re still stuck in the old-school tables mindset. Who knows, maybe CSS-based design will even add formidable enough of a learning curve to weed out some of the hacks.

haze says:
April 10, 10h

my perspective comes from a different view simply because ive been forced to work with projects where presentation supercedes content (and vice versa). because each client is different, their target audience will also be different. it’s impossible to say that ONE existing method will work for all; even if that method might be better.

this presents the question of whether we do what we do because it’s easier for us, or whether the project demands it. adopting a better method of coding IS better in the longrun, but should we blindly apply it to everything? i associate this with paul’s thirst for running. running is better than walking. it takes us places faster and makes us healthier, but running shouldnt be done ALL the time simply because it is better. conversely, walking shouldnt be necessarily abandoned on the account that it isnt as good as running.

this is how i see projects. we’re in the business to solve some of our clients’ many problems; it would be a shame if we lost sight in that.

Dave S. says:
April 10, 10h

Kris: I’ve never experienced a full-on separation of style/structure at the day job, so I’ll take your word for it. It strikes me that that should be the case, but it’s nice to hear confirmation.

haze: good points. I really like the argument you made in this thread (damn myself for not having done something about anchored comments) about targetting the audience.

Has your mindset about targetting jobs changed in the past few years? What I’m getting at, is now that NN4 is at all-time low usage, is it still as valid as it was two years ago to say that tables are a good option for consistent presentation?

I think back to 1998 and how willing many were to target 3.0 browsers and up, screw the 2’s. Usage of those was, if I recall correctly, somewhere around 5 to 10% at the time. The difference being, Netscape 4 now can, with a lot of hacking and browser-specific coding, do what you want it to. Back then 2.0’s just weren’t up to any task involving Javascript. Maybe the technology needs at the time were more important than the presentation is today.

Kris says:
April 10, 12h

Simpler code means improved continuity of the project among designers in a firm. Also, separation of style from structure separates a great deal of dependance on one another between for instance a front-end designer and a backend PHP developer. I see it every day. My boss too. That is why my entire company is moving towards this practice.

I have to agree though, there is still a lot to learn. I don’t preach table based layouts, but I don’t bash them either. I will never use them anymore though, unless strictly necessary. For me it has become a whole new way of thinking; HTML structure is no longer a visual format for me, in practically no way.

haze says:
April 17, 06h

i see that the demand is still quite strong since a lot of companies (new and old) still recognize NS4 as a browser they “need” to support.

now, in that small percentage, a portion will require this support because they’ve got older systems that MUST see the site; these clients you have no choice to develop for.

on the other hand, there is also an extremely LARGE percentage of ppl who can be easily sold on fotward compatibility IF you know how to properly sell it. for the most part, clients are more inclined to drop NS4 support when they hear of how compliancy code will separate the seas, walk on water, and usher in a new era of human evolution… wait… oh i’m thinking of comic books.

Dave says:
April 17, 08h

That’s about my experience too. We just did a re-vamp of a university’s international education department, and their people still run NN4.x. They figured their target audience would be coming from all sorts of underdeveloped countries, so technology levels might be a bit lower. NN4 coding was necessary, so a transitional layout was the route I took.

What’s ironic is that my code was pretty freakin’ good. I didn’t have to do a lot of hacking, just common sense “okay, NN doesn’t support that, so I’ll use this instead” and so forth. It’s when they tied the content management system in that it all fell apart. Go figure… there’s now a pop up “upgrade your browser, please” for 4.x and below.