Assessing the Benefits

Assessing the Benefits

In describing a conversion process like the one we've undertaken in this project, you might meet with some bewilderment. "Why bother, when tables already work?" is the usual question. There are two good reasons.

First, the document structure is a lot cleaner and thus a lot easier to edit and generally maintain. Let's say you had an unclosed element somewhere in your markup, and it was completely messing up the layout. Would you rather sift through the HTML design, choked as it is with font tags and tables nested inside tables, or the relatively clean structure we had at the end of the conversion process? Probably the latter.

Second, there is a noticeable savings in terms of file size. Table 1.1 compares the file sizes, element counts, and server hits that are (or may be) necessary for each of three approaches: the all-HTML design, the converted document with embedded style sheet, and the converted document with the style sheet made external and linked in.

Table 1.1. A Qualitative Comparison of the Three Approaches

Method	Size[*]	Characters	Server Hits	Images	Tables	Font Tags
All HTML	100%	8,994	6–23	22 (18 repeat)	7	20 0
HTML + CSS	75.4%	6,785	5	4	1	0
HTML + linked CSS	59.8%	5,375 + 1,435	5–6	4	1	0

^[*] Compared to all-HTML method; refers to size of HTML document only

Even with the style sheet left inside the document, there's a nearly 25% reduction in the size of the file. If the style sheet is moved into an external file, the benefits are even more striking, down to just under 60% of its original size. Either way, the page will download faster, making users happier and reducing the amount of bandwidth for which we have to pay.

The 59.8% figure deserves a short explanation. It only counts the HTML, not the external style sheet. This is because browsers usually cache external style sheets after they're loaded the first time. Thus, the server won't be asked for the external style sheet after the user loads their first page (that uses this style sheet) from the server. For that first load, the bandwidth savings will be closely in line with the HTML + CSS version, which is still a one-quarter reduction.

In addition to those savings, the positioned version of the layout is much, much easier to alter whenever we want. Adjusting the width of the sidebar, moving the subtitle around, or even reworking the basic layout becomes a quick and simple editing operation. All in all, it seems like a worthwhile effort to have undertaken.

A Caveat

There is one word of caution about this layout. If there is ever a case in which the review column is shorter than the sidebar, strange things can happen. In tables, the cells in a row are all the same height; thus, if we put the sidebar in one cell and the review in another, both cells would the height of the taller cell.

In positioning, there is no way to link two elements together like that. Once you've taken an element out of the document flow, its height is determined by its content and styles—period. It will not be influenced by other elements, nor will they be influenced by it. So, for a layout where the two columns have to be the same visual height or where some content needs to go after both columns and you don't know which column will be taller in the final layout, positioning may be a bad choice. This doesn't mean that positioning is useless. More and more high-profile sites, including Wired News, Sprint PCS, and Quark use CSS-P for layout. You just need to know where positioning excels and where it doesn't so that you can make the best decision regarding how to set up a given layout.