HTML: Sometimes “correct” just isn’t worth it
It is widely understood and accepted in the upper echelons of web design that tables are not to be used for layout purposes. The only time tables are “allowed” is for exactly what its name implies: tabular data, such a train schedule or a table of figures. For anything else, tables are semantically incorrect. There are several good reasons for this (and a few priggish ones). The internet is rife with explanations and arguments both ways; I won’t repeat them here, but I will provide one link just to whet your appetite. There are many more, but this one is at least entertaining.
What do we do instead, you ask? We use div’s and CSS, for the most part. In a very simple example, this:
< table >
< tr >
< td width="40%" >
stuff
< /td >
< td width="60%" >
more stuff
< /td >
< /tr >
< /table >
Becomes this:
< div id="left" >
stuff
< /div >
< div id="right" >
more stuff
< /div >
(spaces added for formatting purposes)
The div’s are supported by CSS that configures their positions and sizes:
#left {width: 40%; float: left;}
#right {width: 60%; float: right;}
There’s actually more to it than that; gutters, padding, margins and the like have to be dealt with as well, but you get the idea. If you add other div’s, things can get even more complicated. But, designing in such a way allows for a lot of great tricks and advantages over stodgy old tables.
So, I always try very hard to stick to that convention: CSS over tables. However, on one recent project I ran into one of the big problems with this approach. It turns out that, because the div’s in the example above are not tied or linked together in any way, their heights are also independent. This means that, if the content is longer in the “left” div, its height will be greater than the “right” div. This causes a lot of problems in layouts with background colors or images; users want clean edges, not a jaggy bottom edge that changes every time the content does. We want this:
Not this:
Tables don’t suffer this problem, because the elements are all tied together by the table’s framework. In tables, all of the elements are spatially related.
There are a few different fixes for this problem, all of varying degrees of complexity and success. There are both pure CSS fixes and Javascript fixes. In my experience, though, these can get very hairy or fail altogether with nested div’s or any other complex design choices…they’re very finicky. Everything has to be just so.
I spent a good deal of time trying to get these fixes to work on the project in question. I added javascript, made jQuery calls, dinked with the CSS and on and on. Nothing seemed to work like it should. I finally had to take a step back and ask myself what my options were; how was I going to fix this problem so that I could move on with the rest of the site? After all, this was a relatively silly problem; it was a dime holding up a dollar, as my boss is fond of saying. That’s when it dawned on me…I knew how to fix the problem. Screw semantics, let’s use a table. I scrapped my containing div’s and CSS floats and all of that, wrapped the content in a simple two-column table, and bam! Equal columns, just like that.
Now the howling will begin. There is no doubt a non-table solution to my problem; I just need to spend the time to find it. But, like many grunts in the trenches, I really don’t have that time–I need to move on and finish the project. If that’s selling out, then so be it. Am I happy about it? No way. Do I accept it? You bet.
So, there you go. Next time around, I will still try my best to use the CSS approach. In fact, this is the only time it’s ever stumped me. I’m not willing to throw the baby out with the bath water and ignore good practices, but I am willing to make informed compromises. That’s one of the things the working man has to do: know when to let it go.












