Tables Vs. CSS - A Fight to the Death

Stage 3: Tables? We don't need no stinkin' tables!

This is it. We'll see what standards-based CSS coding makes of the design. I'll start by marking up the content. I try my best to make this semantically correct (every element should be marked up), and try to avoid extra markup.

The main header is an image, but it is still a header, so I'll mark it up like this:

<h1>Butterfly Watchers Association. They flutter. We watch them.</h1>

I'll worry later about making this display correctly (the ideal here is to think as much as possible about the content and as little as we can about the layout). The other headers (News, Sightings and Membership) will be marked up as <h2>.

The menu is ultimately an unordered list, so it will be marked up as such. Paragraphs won't have classes (we'll use descendant selectors to "hang" them from their containing divs). I'll save a version of the original document and when the design is done, I'll check how much extraneous markup I had to add in concession to the layout (we should strive to avoid that).

The finished document is here. Take a look at the source. It's valid XHTML 1.0 transitional. Notice that all elements have been enclosed in appropriately named <div>s. Dates in the news have been enclosed in <span>s with class "date". As you can see, the code is very simple. We'll try to keep it that way.

Hour 1

Set "container" border to 1px. Have to center the thing. For Explorer, I set text-align: center; to the body style. For the rest of the browsers, margin: 0 auto; (that translates to top=0, right=auto, bottom=0, left=auto) on the "container" style does the trick. Centering the div isn't nearly as easy as it was with tables...

Specifying top and bottom margin in the style of "container" to get the whitespace over and under the design works for most browsers. Explorer screws up the bottom part. How nice.

Adding 20px top and bottom padding to the body instead of margin for "container" works for all browsers. Lovely.

The unordered list items (<li>) must be styled with display:inline; so that the list is displayed horizontally. I add the custom bullets between the elements by specifying 23px left padding on each <li>, setting the bullet as no-repeat background and using appropriate x and y values to position it:

background: url(menuBullet2.gif) no-repeat 4px 9px;

Menu rollovers use the :hover pseudo class of the links. No need for fancy JavaScript here.

To style the header with our butterfly image without compromising accessibility I'll set it as background for the <h1> and use a really big negative text-indent property as shown here. This moves the text far to the left, to take it away from the browser window, and leaves the image in place. The text is still accessible to screen readers and robots. Score one for CSS.

Hour 2

The first item of the menu (HOME) uses a different bullet. I'll have to hide the background (the other bullet) for this item in particular, and replace it with the appropriate bullet. There is a CSS pseudo-class (E:first-child) that targets this element, but support for it is iffy at best. I'll have to settle for adding an extra id (frst) to the first item in the list. That way, I can target it for styling like this:

#hMenu ul li#frst

This kind of thing should be avoided if possible -- modifying document content to account for layout is not a good idea in general.

For the bullet on the other side (CONTACT), I'll use the background of the <ul>:

background: transparent url(menuBullet3.gif) no-repeat 615px 9px;

We can't really have two columns automatically extend to the same height in CSS. Luckily, we can fake it with an image. A simple gray image with a right border will do nicely.

I'll set it as background of the "container" <div> and specify repeat-y:

background: #fff url(bgMain.gif) repeat-y;

So far, we have this.

Hour 3

Making boxes is so much easier with CSS than it is with tables. Having the ability to specify borders separately is really useful.

Time to style the <h2> headers. Bullets are added by the method I explained before (add left padding to the <h2>, set bullet as non-repeating background, position until it looks right).

To make the columns, I just set specific widths to the "sightings", "membership" and "news" divs. I float the "news" to the left and the "sightings" and "membership" to the right. The "copyright" <div> gets clear: both; so that it lands under the floated divs (this is pretty much standard procedure for footers, since floats remove themselves from normal flow of the document).

News positioning involves a bit of fiddling with padding and negative margins.

Having a true float property means we can wrap the paragraph around the butterfly image in the "sightings" section without much fuss. The frame is provided by specifying a solid 1px border and adding padding to the image.

Just noticed a freak rendering error in Explorer: upon first displaying the layout, the copyright section is without border and overlaps the sections above it. Resizing the window restores the border but the div still overlaps the other section. Darn.

This is where we stand.

Hour 4

The rendering error was related to the float:right; of the "sightings" and "membership" sections. Floating them to the left fixes the problem. It's weird, but not completely unexpected.

I'm going to try this for the first time in Firefox. I hit "preview" and, with clenched teeth, take a peek. It's not half bad actually! (This, I find quite surprising). The menu has too much left padding and the bullets are a few pixels off.

It's nothing we can't fix with a bit of fiddling. Here's where we dive headfirst into the ugly reality of CSS hacks.

That wasn't too difficult. A few judiciously applied extra rules fixed it for non-IE browsers. To feed a different value to non-IE browsers, I'm using the !important property, which specifies that that particular rule should take precedence over others for the same element. This is not supported by Explorer.

background: url(menuBullet2.gif) no-repeat 4px 6px !important;  
 background: url(menuBullet2.gif) no-repeat 4px 9px;

In CSS, values are read from top to bottom and, if multiple values are specified for the same element, the last one is used. Since Explorer doesn't support !important, it takes the second value, while other browsers take the first one.

It is done. Here's the result.

Conclusions

On Table-based Design…

I've seen that design in every browser I can, under Linux, Windows and Macintosh platforms, and it looks practically the same. It's rock solid. Score one for the tables.

Then again, that's a lot of code to wade through every time we want to change something in the site. That could be a problem. If a Content Management System (CMS) is used, it will also add extra complexity to the way the content must be formatted -- not exactly user-friendly.

I think it took me this long to whip out the design because I was very rusty on the methodologies involved. If I had to do it again, I'd probably cut that time by one or two hours.

I would describe the experience of working with table-based design as being a lot of grunt work. I was constantly amazed at the way the design advanced, though. Working with pure CSS-based design, I've become accustomed to breaking up designs all the time and having to trace back my steps to hunt down bugs selectively. I didn't have to do any of that here. I just had to keep pumping tables into the design. Let's see how the CSS fares.

On CSS-based Design…

Building the design in CSS felt much better. The immediacy of the changes and clarity of the code made me feel more in control of the process. Whereas working with tables felt like building with lego bricks, with incremental changes, CSS felt more like working with a highly trained professional -- I issued a set of orders and watched as they were carried out.

There are significant savings in bandwidth, too. By placing the styles in their own file and using the same file for the whole site, they would be even more visible.

Keeping the layout information apart from the content also provides all sorts of benefits. In the future, I could redesign this site completely without touching the content, as exemplified by the css Zen Garden. There's also the added value of accessibility. In all likelihood, a screen reader would choke on the table-based design. Robots may find this one better too (remember: Google is your most important blind visitor).

After finishing the design, I tested it in a wide variety of platforms and browsers. Explorer 5.5 and 6 render it great. Explorer 5.0 mangles up the menu, some paddings, and misplaces the header image as seen here.

This can undoubtedly be fixed, provided another hour of tinkering. I won't do it, though. For the scope of this article, I think this is good enough, but if this was a real client, I wouldn't sacrifice Explorer 5.0 support. That would mean hunting more bugs and playing with the design until it's ready. Older browsers do a horrible job of rendering it:

IE4

Netscape 4.7x

It's better to use unsupported rules (like @import for Netscape) to serve an unstyled version of the document to those browsers.

Although CSS-based design is really fast when you get used to it, you must spend a significant amount of time getting to know the rules, the box model differences, browser quirks and other theory. This comes through practice and practice only. In short: it's much easier to just use tables. If you want to make pure CSS designs, be prepared to invest time in learning. Even if you're already a seasoned developer, be prepared to hunt down bugs relentlessly, sometimes investing several hours in the process.

The Winner!

CSS and standards-based design take the match. One look at the source of each design is enough to make me choose this one. CSS offers multiple other benefits, mostly having to do with accessibility. But, ultimately, this is about me being lazy. If I made this design with tables, and the client contacted me one year later to request changes, I'd tell him I joined the foreign legion and flee the country. If I made it with CSS, I'd give it a shot without thinking twice.

Acknowledgements
Thanks to Ava McBride, for facilitating the use of the Browsercam service for testing of this design.