Tables are still good for layout
Update: Internet Explorer 7 added support for the CSS max-width property. Since most web surfers are using IE7, or a modern standards-supporting browser, the issues this page talks about are no longer relevant.
The idea that tables were only designed for tabular data is one of these urban myths that I keep hearing. I hear that we should be using CSS for all of our layout, which will make browser testing will be a thing of the past, and, best of all, we will be "standards compliant".
As of early 2005, CSS is plain simply not ready to be used for layout. Let me take that back. The CSS specs may be ready to do anything that was possible back in 1997 with tables. However, the specs are just so much ink on dead trees until the people surfing your web site use software that implements them.
Unfortunatly, browers are not CSS compliant. Let me take that back. One browser is not CSS compliant [1]. Internet Explorer. The one that 80% of the web surfing population uses. Basically, a web designer's choices are limited: They can design around IE's bugs, and have CSS that looks OK on IE but is broken on other browsers, or they can code to other browsers and have the web site look bad on IE.
The other option is to do some ugly hacks that take advantage of subtle CSS parsing bugs so that IE sees one CSS page and other browsers see a different CSS page. The problem here is that there is no guarantee that the next version of IE will parse the same way; a page with these hacks is waiting to be broken by Microsoft's next IE release.
Wait a minute. We just said hacks. We just said making one browser see one CSS and having another browser see a different CSS. This should remind one of the mid-1990s, where web servers would return different HTML pages to different user agents. Wasn't standards complance supposed to move us pass those days of having to test a web page on every browser we could get our hands on to see? Well, CSS certaintly hasn't brought us any closer to the holy grail of "code and test on one browser, and it will look fine on all browsers". Not with Microsoft dragging their feet.
So, CSS hasn't brought us any closer to "write once read anywhere". Indeed, it is a step backwards. Table layouts and how they render on a screen have been around for a decade, and haven't changed significantly since the Netscape 2.0 days. When I design a web page that is arranged with tables and test it on, say, Firefox 1.0, the web page will look just about the same on Internet Explorer or any other modern browser. It is the most cross-browser way of arranging web pages. Indeed, many minority browsers (Dillo, Links) honor table layout but have no CSS support.
CSS has made it possible to separate the layout from the content. Except for one little catch: CSS is not as fluid about different browser window sizes and font size as the old table layouts are. The most common way to use CSS for layout is something like this:
#something {
position: absolute;
top: 42px;
left: 7px;
width: 200px;
font-family: wharver;
etc: and so on it goes;
}
In English, this says "We want some data to be locate 42 pixels from the top
of the web page and seven pixels from the left of the web page. We want this
element to be precisely 200 pixels wide". This tells the browser where exactly
on the screen to put the element. It tells us exactly how large the
given box is. It allows the web master to control exactly what the web
page looks like.
However, the problem is this: Screen resolutions come in a lot of different sizes. 800x600, in particular, is still quite common: 30% of web surfers browse at this resolution. If I design a web page to look good at 1024x768 in CSS, the 800x600 users will have to navigate left and right with the scroll bar to use my web page. If I design a web page to look good at a given font size, people with less-than-perfect vision (or high DPI monitors) who increase the font size will have the layout runined by text bleedover. CSS, as it currently exists (on IE, that browser 80% of the surfing population uses), will only look good when your user has a browser window as big as your browser window, using the same font size you used to design the web page [2], and has the same vision that you have.
See this for yourself. Go here to see a web page I designed using tables for layout. Resize the window larger and smaller. See how the web page remains usable and doesn't create a horizontal scrollbar when the browser window becomes narrower than the web content. Change the font size to be smaller or larger; the content on the page remains the same and text does not overlap.
Now, go here to see the same web page using <div> and CSS for layout. Resize the window--as soon as it becomes narrower than the content width, a horizontal scrollbar appears at the bottom and it becomes painful to use the site. Change the font size. While I have gone to some pains to minimize problems with changing the font size (a lot of CSS developers, mind you, don't bother), there is still ugly text overbleed when the font becomes too big in Firefox.
With table layout, a given specified width (in <td>) is a suggestion, not an ironclad rule. It is, basically, a minimum width for the row; if more room is needed to fit content, a table cell will widen to fit the content. If the browser window is too small to fit the table at the sugessted width, the browser will make the table cells narrower to accomidate the smaller browser window. A web site can have the same overall look at a wide variety of different resolutions and font sizes without the ugly font overflow or horizontal scrollbars CSS is plagued with.
Yes, CSS2 has the max-width attribute that tries to emulate this behavior, but here is the clincher: Internet Explorer doesn't support max-width. Heck, there are CSS tags for specifying a table in CSS, which, you got it, Internet Explorer doesn't support.
So, for layout, tables are the way to go. They are more cross-platform, support different font sizes and screen resolutions better, and do not require you to understand the bugs in the IE5 CSS box model.
This is not to say that CSS is bad. CSS allows far more flexibility with font size, margins control, floating elements (such as an image you want on the side of a page), mouseover highlighting of links without ugly Javascript, and, yes, it makes it easier for your modern web page to look fine in Lynx and screen readers for the blind. However, at the current level of CSS techology, tables are better for most page layout tasks.
Actually Netscape 4 also isn't CSS compliant, but since that's 2% of the surfing population, one can just use a @import url(file.css) to keep Netscape blissfully ignorant of any CSS on your page. The only people who need to code around Netscape 4 are the maintainers of home.netscape.com.
Yes, it is possible to make a CSS page look the same at different font sizes by using em instead of px for measurment. However, this method makes it impossible to make the fonts bigger and have the page fit in a given browser window size.