On using tables for html layouts

Ok, so the standardistas decry using tables for layouts, using divs and css is the one true way. You lose the ability to restyle things drastically by changing just the stylesheet, they say. But do you really lose that? It has been my experience that if you have a site with complex layouts, to do it all using css you end up layering hack upon hack to deal with browser incompatibilites and css deficiencies that your supposedly clean markup is layered with extra divs and ids that to a large extent fix things to your current layout. Let’s look at a simple example.

A two column fixed layout. This article has what I found to be the simplest version of this idea. You start with this html:

<div id="container"> <div id="content">This is<br />some content</div> <div id="rail">This is the rail</div> </div> <p>

And this css:

#container{
background-color:#0ff;
overflow:hidden;
width:750px;
}
#content{
background-color:#0ff;
width:600px;
border-right:150px solid #f00; »
/* The width and color of the rail */
margin-right:-150px; /* Hat tip to Ryan Brill */
float:left;
}
#rail{
background-color:#f00;
width:150px;
float:left;
}

If you were using tables you would have this (I’m using old time table tags for this just to keep it simple, some of these attributes would probably be better off in the stylesheet):

<br /> <table width="750"> <tr> <td width="600" bgcolor="#0ff">This is<br />some content</td> <td width="150" bgcolor="#f00">This is the rail</td> </tr> </table> <p>

So the css version’s html is slightly simpler, but it makes up for that with it’s css. The css is fairly simple, the hack to overcome css’s inability to have two equal height columns is annoying but easy. However, if you want to have a margin between these two columns, you also have to add in a margin and some extra work to deal with ie’s box model differences.

Also in the css model you need this extra container div that adds no semantic value, in fact it reduces the semantic value by defining a sibling relationship between two not necessarily related components of the page. What happens when you want to take the elements of the rail and actually move them into a header position? With some extreme css-fu you could probably do some hacking to move it to display outside the container, but what happens when the place you want to move it to also requires an extra container to work? Well, now you have to go back into the html and add more non-semantic html. And while you’re in there you may as well move it out of the container div and add a new container div above the old one to put the rail into.

Plus you have to deconstruct a ton of CSS work, figure out which pieces go where, which hacks are no longer needed in the new world, etc.. Obviously what I outline is an extreme scenario, but when you’re doing a redesign of a site, that can definitely happen.

In the table model, you don’t have hacks (some might view using the table itself as the hack, but it’s very obvious and very easy to deconstruct). If you want to move the rail above the table, you obviously have to go in and take it out of that table and reformat it a little bit, but the html is so simple you don’t have to unwind any hacking for browser incompatibilities. The process is almost identical to what you did above in the css version.

And in the world of dynamic websites, typically things are divided up nicely into include files and sub-modules so widespread html changes are pretty easy to enact across the board. Using these techniques, structural pages can be kept almost separate from content based pages, so that the html above could actually look something like that. If you’ll pardon my pseudo include code below:

<br /> <table width="750"> <tr> <td width="600" bgcolor="#0ff">[[INCLUDE - content]]</td> <td width="150" bgcolor="#f00">[[INCLUDE - rail]]</td> </tr> </table> <p>

So that looking at the structure it’s super easy to understand what you’ve layed out and can change it quite easily.

Now I’m not saying css structuring is bad and tables are good. I’ve laid out a situation here that tries to show that in this case, it would be reasonable to use table’s to lay things out. Every website is a snowflake and people have different reasons for wanting to do different things. There is no one true way and I am trying to make the case that sometimes it’s OK to use tables to structure things. Sometimes it might not make sense - people get crazy with tables nested within tables nested within tables. But I think some people go too far in demanding semantic trueness. A man much more smarter than me said, “there’s more than one way to do things.”

← newer Oracle Acquisitions  ↑  Apple Should Start a VC Arm older →