Why CSS in place of tables

Tables are slow
In almost every browser out there, unless table widths are specified explicitly, all the text in the table needs to be rendered before the browser can figure out how wide to make the various table cells. This means that pages load slowly. Note that using CSS for layout doesn’t necessarily help here, since there’s the same problem if the widths aren’t specified explicity. I’m guilty of this myself. Take a look at my quotes page (which doesn’t need to be a table, as a list with a floating element to the right of each list-item for the link would do just fine) or my list of CDs. Notice how slowly they load. Both pages use a table to line up the data.

Tables don’t have to be slow (as Todd Hoff points out) if you put each row in a separate table, but then you lose the alignment between rows. For a blog, that may not be much of a problem, but for data that actually wants to be in tabular form, it’s still a problem.

Tables can be inflexible
One of the common tricks to make tables load more quickly is to specify the widths for all the table columns. This means that the table renders pretty quickly, and the user can see your text right away. The problem is that you’ve just specified the width for the page. Again, note that you can have this exact same problem with CSS if you specify all the widths explicitly.

Accessibility issues are easier with CSS
Thanks to Harold Levin for the question about accessibility (see the followups). Tables also mean you have to present the information in the same order you want it displayed. You have to present data in the left column before the columns to the right. Using CSS for layout, you can present the data in a logical order and use CSS to control the appearance. For example, in a three-column layout using tables, you’ll see left-column then center column then right column in that order. Using CSS, you can put whichever of the three columns is most important first, and keep the layout separate (which is the whole point of CSS). A real important point that I missed on the first pass. I don’t know what I was thinking.

Tables don’t degrade
The most important reason why using tables for layout is that they don’t degrade gracefully. For a good example of this, take a look at any page on this site. If your browser window is wide enough, you get a nice, two-column layout, just the way I intended. But if you’re using a narrower browser window, or a web TV (I still preview all my pages with the WebTV Viewer to make sure they look reasonable there), the page falls down to a single column with what used to be on the right down below the more important part of the page (or at least what I think is more important to most people). Tables don’t let the page degrade gracefully, and that’s their biggest problem.

Tables don’t print as well
A huge problem with tables (pointed out by a reader, this is another one I missed on the first pass) is that they don’t print terribly well. With CSS, you can use a print style sheet to give another look to the page. This style sheet can also include page-breaks that are under your control. You can also have elements that only show up when rendered to a screen, but not to a printer (headers and footers, for example). Or elements that show up when printed, but not to a screen (useful for expanding links so they’re visible when printed). Take a look at How to use valid code to make your life easier for a swell example. Now look at it using Print Preview if your browser supports that.

Tweet

Share

Save