Most Web developers use HTML tables for their page layouts, and probably will continue to do so for a long time. Cascading Style Sheets may eventually give us a better alternative, but the promised day of cross-browser support for sophisticated CSS positioning and widespread abandonment of those old browsers still seems pretty far off. In the meantime, let's look at a few techniques you can use to get the most out of those layout tables.

One Table or Many?

A typical Web page layout might look something like this:

Figure 1

It is easy enough, of course, to create this as one table. But that's not the best way to do it, because of the way that browsers process HTML code: the contents of elements are not rendered until the entire tag has been read. This means that if you open a single layout table that contains the entire contents of the page, the user will be looking at a blank browser window until the browser finds the closing tag for the table at the end of the body. In some cases that will be longer than users are willing to wait. Instead you should construct the page above as a series of tables, like this:

Figure 2

Each table will contain one row, and browser will then display each row as it is processed. (Microsoft has recognized this problem, and IE 5.0 will contain a new HTML processor that renders tables row by row, but that won't make any difference to all the other browsers that users will no doubt have for at least the next couple of years.)

You will have to take some steps to make sure these successive tables line up correctly, but we'll come to that when look at the table attributes below. First we'll address the question of the width of the tables.

How Wide Should It Be?

A year or two ago, page designers usually took advantage of all the too-little screen real estate available by setting layout table widths to 90-100% (of the browser window width, minus the built-in page margins). This meant that all the available space would be used, whether users had their display resolutions set to 640x480 or 800x600 pixels, which were the only options that most video cards and monitors supported.

This strategy worked well in most cases, because the difference between those two resolutions isn't that much. Users at the lower resolution had to scroll down a little, or users at the higher resolution saw some white space at the bottom of some pages, but so what?

With the increasing prevalence of larger monitors and better graphics cards, everything has changed. Users working at 1200x1024 resolutions have almost twice the window width available as those low resolution users, and quite a few people tell me -- much to my envy -- that their hardware allows them to use a 1600x1600 resolution. For these users, a page that looks good at 640x480 is likely to look like a bunch of one-line paragraphs. Even if you make the paragraphs longer, it doesn't help, because a 1200 pixel line at any reasonable font size is too long for easy reading; the reader's eyes have to travel too far from the beginning of the line and back again for the next one.

For the wide range of user resolutions developers have to anticipate these days, then, the only solution is fixed widths for layout tables. But how wide?

The answer is driven by two concerns. First, we know that the sure fatal flaw of page design is forcing users to scroll horizontally, which poses even greater obstacles to reading than the 1200 pixel lines. Secondly, the optimum length of lines of text for readability -- 10-12 words -- generally requires a page width of under 600 pixels. That's about the cutoff for a 640x480 resolution anyway, allowing for pixels lost to the browser window frame, the page margins, and a task- or toolbar aligned along the side of the user's screen.

So set those table widths to around 590-600 pixels, and remember that the width attribute for tables only specifies a minimum recommended width to the browser. If your content demands more width, the browser will cheerfully provide it. Images are the usual suspects, but look for "nowrap" TD attributes and long URLs also when tables refuse to stay inbound. This is especially important when you use multiple tables, since just one bulging out to 620 looks pretty silly -- and this is one of those things you want to make sure you check on several different browsers....

And what about all that horizontal white space that high resolution users are going to see? Well, if you've spent much time on the Web lately with a "high-rez" display, you'll see that a number of sites have already adopted this strategy, and that the result doesn't look bad at all if the page is well-designed in other respects. Also, remember that the white space doesn't have to be; since you can set the background color on the table itself, there's nothing wrong with using some interesting page background colors to fill the blank space, or even one of those cool images you pulled last year because no one was doing background images anymore.

If you do set the table against a different page background, you want to be especially careful to make sure that your multiple tables end up looking like Figure 1 above and not Figure 2. Problems in this area are often caused by attempts to align the tables to the center or right.

Of the various alignment methods available, I don't recommend using the table tag's own align attribute. Only with 4.0 browsers does setting it to "center" finally have the effect that makes sense, and I've seen the "right" value produce some odd results in some cases. Don't use the CENTER tag either -- it has been officially deprecated. Browsers, of course, will continue to support the CENTER tag, but you want to look forward, not backward. Besides, there is no corresponding RIGHT tag to keep your coding consistent.

That leaves two choices: wrap the tables in either a DIV or P with an align="center" attribute. W3C prefers DIV for a good reason. DIV just does what you want to do -- centers the content and nothing else. P also centers content, but inserts a blank line first. If you wrap the whole set of tables in a single paragraph, the effect will be barely noticeable. If you put each table in its own paragraph, which many developers would prefer for the sake of making the code easier to understand, the effect will what you see in Figure 2 above. Bottom line: use the DIV tag; that's what it's for, and it does the job.

So much for how to create the alignment of the tables, but what should the alignment be? To my knowledge there are no usability studies that demonstrate enhanced processing of information by users that results from a particular alignment of information in the browser window. I did hear a secondhand report that one development group carried out such a study and concluded that right alignment was better. Since I didn't see the actual study, I don't know exactly what they meant by "better." I did see the site that resulted, and it's a nice one, but I can't say that the right-alignment jumped off the screen to me as a revelation I wanted to imitate. Personally I prefer center alignment, because I like symmetry in the space around the page contents, but I don't claim any more for that than personal preference. Follow your own, but do be consistent, unless you want to constantly surprise your users.

Aside from matching the widths of the multiple tables, there are times when you need to match the widths of columns in various tables also. (Don't automatically assume that you have to this -- in some cases uneven columns will be more interesting.) There are two ways to fix a column width: using the width attribute of TD cells; or using the clear.gif trick that many developers have employed.

The width attribute is the cleaner solution, but unfortunately I see a number of cases where the results aren't right, even in the latest browsers. Of course, the width attribute for TDs, like that for the TABLE tag, only specifies a minimum width that the browser may override for contents that require it. Even allowing for that, however, I see problems in the sizing of columns that seem attributable only to browser bugs.

The only sure way to ensure a width, then, is still the clunky but effective clear.gif. The trick is simple: create a 1x1 transparent GIF file. (You want to make it as small as possible to minimize the weight that it adds to the page.) Insert it at the beginning of contents of the TD cell you want to size, setting the height to "1" and the width to whatever you want it to be. If you don't have a clear.gif file handy, feel free to steal mine. It's right here--> <--

Don't assume that browsers will handle table attributes in exactly the same way, and that the default values for attributes are the same across different browsers. Look at the following code sample and the rendering in IE 4.01 and Netscape 3.04 below:

<table width="200" bgcolor="#CCCCCC">
<tr>
<td bgcolor="#CCF5F5" align="center">Left Cell</td>
<td bgcolor="#CCF5F5" align="center">Right Cell</td>
</tr>
</table>
<br>
<br>
<table width="200" bgcolor="#CCCCCC">
<tr>
<td align="center">Left Cell</td>
<td align="center">Right Cell</td>
</tr>
</table>
<br>
<br>
<table width="200" bgcolor="#CCCCCC" cellpadding="5" cellspacing="2" border="2">
<tr>
<td bgcolor="#CCF5F5" align="center">Left Cell</td>
<td bgcolor="#CCF5F5" align="center">Right Cell</td>
</tr>
</table>
<br>
<br>
<table width="200" bgcolor="#CCCCCC" cellpadding="5" cellspacing="0" border="0">
<tr>
<td bgcolor="#CCF5F5" align="center">Left Cell</td>
<td bgcolor="#CCF5F5" align="center">Right Cell</td>
</tr>
</table>

If you study the renderings closely, you'll see a number of fine differences in the default values and handling of color attributes. The moral of the story is: don't trust the browser defaults. Make sure you specify the values you want for the BORDER, CELLSPACING, and CELLPADDING attributes. For layout tables, you will generally want to set border and cellspacing to "0," and handle the spacing of contents through the cellpadding value.

You've got the makings of a good layout table now. Just a couple of more points about using other table tags. You may be tempted to sprinkle the table with TH tags as a shortcut when you want to center and bold the cell contents. I urge you not to, because it makes the code more confusing to someone who has to update the page later, or to an information sniffer for a search engine. Save the TH tags for real table headers.

And what about the new THEAD, TFOOT, and TBODY elements defined in HTML 4.0? If you're following my advice here and creating the page layout as a series of one-row tables, these tags don't really serve any purpose for layout. If you are using multi-row tables, there's no harm in using the THEAD and TBODY tags: they won't be widely supported for awhile yet, but older browsers will simply ignore them and render the rows they contain. The TFOOT tag is another matter. Because the HTML 4.0 specification requires it to be placed between the THEAD and TBODY, it can't be used except in intranet situations where you can depend on client configurations supporting HTML 4.0; older browsers will display the table footer row(s) immediately after the header rows.

-Robert

Robert Crooks is an Allaire Certified Instructor at Allaire Corp. Please direct comments on this column to talkback@allaire.com.