Article Surfing Archive

This is an article that questions the dogmatic elimination of tables from web page design, and suggests a more relaxed approach that benefits from both HTML tables and CSS.

I recently inherited an auto insurance consumer information website (http://insurance.truxncars.com) for maintenance and ongoing development. I was pleasantly surprised by the features and the way the resources were organized in the directories, then I took a look at the source code - tables, tables, tables everywhere.

As you can imagine, with the mantra of "tables bad, css good, tables bad..." echoing from every HTML style guru I've read for the past couple of years, seeing all those nested tables made me a little glum. Then I started looking through the code, matching what I was seeing in the code with what was appearing in the generated page, and I found that it wasn't all that difficult to find my way around. Obviously, I have the benefit of looking through the php code, but even looking at the "View Page Source" output there are landmarks and helpful comments from the original designer that assist with navigation.

Now, I have seen abysmal pages where tables are tortured into achieving radically non-grid layouts using invisible spacer gifs, extensive column and row spanning, and multiple nesting with widths of the innermost cells carefully calculated to align images in the outermost table - a true Frankenstein of a table. The code I was reviewing didn't commit any of these sins; it was simply trying to present various items of information in a grid. Some of those items were themselves in the form of grids, but they are logically independent. This seems like a reasonable excuse for nested tables - are we truly justified in condemning the design because it uses them?

At this point I decided to compare the strengths and weaknesses of tables and css positioning.

1) Internet Explorer still doesn't play fair with css block dimensions, divs can nest nicely like Russian dolls in one browser but be completely misaligned in the next. Choosing a "strict" DocType helps enormously, but it's still a crapshoot.

2) CSS encourages the proliferation of "magic numbers" - one of the ultimate sins in programming. When elements are given absolute positions, naturally we have to specify the coordinates through the use of left, top, or optionally right, bottom. As the number of page elements grows, it can become a real chore to ensure that all the values are correct when changing the position of an element.

To make maintenance of a css site easier, take advantage of the centralization achievable with external css files; keep all the positioning together in a css file, and put comments in there showing how the offsets are derived. Also, take advantage of local offsets - an absolute-positioned element within an absolute-positioned parent div has offsets relative to the top-left corner of the parent. This means you can reposition the parent div, and all the elements within it are shifted to match. But I digress...

3) Tables are really bad at absolute positioning. Don't do it - if element A really must be in a specific position, exactly 219 pixels from element B, just use css. Don't fight it.

4) Tables are good at making best use of the available browser window area. They also fail gracefully. Without adding any extra code, if the visitor resizes the browser window then the table will adjust the contents as best it can, and if it can't make itself any smaller, it just stops shrinking - the visitor can scroll the page to see the rest of the table, his choice. What a table won't do is to decide to push the rightmost table cell down and against the left side of the browser window - exactly what will happen to a 'float' positioned div unless you take precautions with a container div that has a minimum-width property set.

Pause for thought... if we're nesting divs and manually adding minimum-widths to ensure that the elements appear where we designed them to be, how exactly are we adding clarity of design, compared to a table?

5) Select your favorite search engine, look for techniques to create multi-column page layouts where all the columns are the same height. The contortions you have to go through to achieve this are extraordinary - then you have to make sure your implementation works across all the major browsers. Compare the css multi-column method with a simple three-column table, which is straightforward and has always worked exactly as expected.

6) Content laid out using a table will never have unintentionally overlapping text when displayed using a screen resolution or window size not anticipated by the designer. Sadly, this is an increasingly common problem on a wide variety of websites and seems to be driven entirely by the perceived need to position everything explicitly using css.

It's plain to see that both css positioning and table layout have their place. CSS has finer control, and should be the method of choice. It allows powerful centralized control across a whole website from a single file, and can lead to cleaner and faster-loading pages. On the other hand, tables are excellent at adaptive layouts free from unexpected side-effects. If used as intended - primarily without arcane inherited positioning artifacts where the contents of an inner cell performs critical positioning of an outer element - then tables can form a robust, low-maintenance framework for your page.