Practical Web Design - Introduction to Tables, Part 1

Using Tables to Make a Basic Page Layout

Tables constrain themselves to fit the content they contain, unless you tell them differently. You can do this simply enough with the HEIGHT and WIDTH attributes for the <TABLE> tag. There are two flavors of HEIGHT and WIDTH: absolute and relative. The first creates a table that is an absolute width as measured in pixels, like so:

<TABLE width="744" height="410">

This is optimized for the average 800x600 screen display. It will fit nicely within the display both horizontally and vertically, with just a bit of "cheater" space left over for slightly off-sized displays. Unfortunately, it is just what it says -- an absolute value. Therefore, those folks using other displays won't see a nice table that fills their screen. The folks with a 1024x768 display will see a table in their screen, but will have plenty of unused real estate surrounding it; those few still laboring with a 640x480 display won't see the entire table, and will have to scroll both horizontally and vertically to see all the content. Not good.

A better option for the average table designer is using relative table heights and widths. These use percentages instead of pixel values, to wit:

<TABLE width="95%" height="95%">

This fills up 95% of the available display space both horizontally and vertically. Leave one out (typically the HEIGHT attribute), and the table sizes itself to take up 95% of the screen horizontally, but automatically adjusts itself to fit the content vertically. This last option, using a WIDTH percentage but letting the HEIGHT take care of itself, is usually a good choice to go with.

Here's the basic table layout of my own site. I didn't do anything fancy or groundbreaking -- in fact, when I originally designed the page, I had only the fuzziest notion of how to use tables to lay pages out. So I opted for something simple that I could get my mind around, was user-friendly and familiar. So here's what I did (aping who knows how many other Web pages):

Here's the code, minus the content. Notice that I've centered the entire interior, or nested, table:

<TABLE width="600">    
<DIV ALIGN="center">    
<TABLE>    
   <TR>    
     <TD width="20%"></TD>    
   <TD width="5%"></TD>    
     <TD width="70%"></TD>    
 </TR>    
</TABLE>    
</DIV>    
</TABLE>

Notice that the <TD> widths add up to 95%. That gives me 5% of my display width to "cheat" with, providing a slender whitespace margin on the left and right sides of the display.

There are some issues with this page layout. I originally chose to use a "framing" table with a 600-pixel width because at the time I designed it (around 2001), many of my users let me know they were still using 640x480 displays, and I wanted my page to fit in their displays without the annoying horizontal scroll bar. I've asked my newsletter subscribers what they used, and enough of them still use the smaller displays for me to rationalize keeping the width at 600. If I were designing the page today, I'd set the pixel width around 740 or so.

Also, the entire contents of the page is contained within the framing table, forcing the users' browsers to download all of the content, graphics, text, JavaScript, and all, before displaying anything. That's a classic problem, which leads to some users with slower connections being forced to sit and stare for a little while before the page "pops" into view.

And let me reiterate, there's nothing outstandingly wonderful or different about the page layout I've used. I used it as an example simply because it's a scheme with which I'm familiar. The usability gurus such as Andy King and Jakob Nielsen would have a field day picking my page apart. However, it serves as a starting point. You can set yourself an exercise: improve on it!

I've decided that, rather than redesigning the page with a different table layout, to wait until I've mastered CSS enough to redesign the page using the more modern style-sheet driven, tableless design methodology. Since I haven't mastered CSS well enough to do that yet, and since a large percentage of my audience continues to use older PCs and browsers that choke on modern CSS, my page stays rooted in pre-millennium table design for now. But hey, it works, and for the moment, that's good enough for lazy old me.

Part II of this article will focus on less-used TABLE attributes, many of them introduced in HTML 4.0, and some other fun things to do with tables. See you next time!