Practical Web Design - Introduction to Tables, Part 1

Vertical Vs. Horizontal Orientation

I don't know about you, but I like vertical orientation. Phone books make innate sense to me because their structure suits me. If I'm looking at a cluster of tall buildings, I tend to look up the first, then over and down the next, and so forth.

When you're first building Web pages, the structure of your page is innately vertical -- you pile one thing on top of another, like a layer cake. But when you start thinking in terms of designing with tables, you have to break out of the vertical paradigm and start thinking in terms of rows, not columns. Across instead of down. You'll see what I mean shortly.

Tables 101

As I said before, there are bazillions of sites out there that will help you with your table structure. For a thumbnail reference, I used SitePoint's own Beginner's HTML, Part 3 article by James Ussher-Smith to keep me honest. If you want something really user-friendly, try Lissa Explains It All: Tables for a well-done explanation of table construction. Lissa's site looks like Ashley and Mary Kate designed it, but the information is valid and presented very well. I'd suggest you load one of those two pages and read them concurrently with this article. Lissa provides some very nice visual examples to accompany her tips.

Everything starts with the basic <TABLE></TABLE> tag. These simple tags enclose a table structure, and tell the Web browser to watch out, table content is coming up.

You should be aware right now that browsers have to untangle a table's entire structure before they display any of the table's contents, so an overly fancy or loaded-down table structure will take some time to download and display. That's why you click into a page and wait, and wait, and wait, while nothing seems to load, and suddenly bang! the entire page appears at once. It's because the browser had to wend its way through a table layout before it could show anything. Table structures like this can aggravate the average site visitor, who may well click out to go elsewhere before the table can finish loading. Don't force a single table to carry too much content, force it to be overly complex, or nest too many subsidiary tables inside one overarching, page-encompassing table. Better to use smaller tables and "stack" them one on top of the other.

Like so many other HTML tags, the <TABLE></TABLE> tags act as "bookends" for your table content. Simple enough.

The next tag is the <TR></TR> tag. This stands for "table rows." Rows, not columns. When I first started trying to make sense out of table structure, I kept running into a problem visualizing table structure because I wanted to think vertically, not horizontally. It took me more time than it should have to grasp the essential concept of table structure, because I didn't want to think in terms of rows. I wanted to design "up and down," not horizontally. From my experience with other burgeoning Web designers, I'm not the only person who has run into trouble because of this paradigm shift. Trust me on this: once you make the shift from thinking vertically to thinking horizontally, tables become much, much simpler. And for those of you who naturally think horizontally, you're entitled to a bit of a laugh at our expense.

Anyway, the <TR> tag indicates that a row is being created. The simplest form of table is the following (you might want to follow along by copying the code into Notepad, opening it in a separate browser window, and watching what happens as we move through this):

<TABLE>  
 <TR></TR>  
<TABLE>

Hey, what happened to the row I just constructed? Nothing shows up! Well, we haven't put anything in the row. A table needs cells, or compartments that store actual content. Think of a calendar. The typical calendar has four or five rows, with seven cells per row. You would think the code for a table cell would be <TC>, but you'd be wrong. The code is <TD>, for table data. Now let's try that table structure again:

<TABLE>  
 <TR>  
   <TD></TD>  
 </TR>  
<TABLE>

Arrggh! Still nothing! Well, not really. The structure is there, but since there's no content, the table won't display. Let's put some content in that cell:

<TABLE>  
 <TR>  
   <TD>Bleah!</TD>  
 </TR>  
<TABLE>

Now we've got something...a lot of code to display one nonsense word. Again, not really. You're laying the groundwork for something a bit more complex. Let's add some more cells:

<TABLE>  
 <TR>  
   <TD>Bleah!</TD>  
   <TD>Bleah!</TD>  
   <TD>Bleah!</TD>  
   <TD>Bleah!</TD>  
   <TD>Bleah!</TD>  
 </TR>  
<TABLE>

Besides being mildly childish, we've succeeded in making a word appear five times in succession. Well, no, we've done more. What you may not realize is that in HTML, the table structure itself is rendered invisible by default. In other words, you can't see the borders. As with certain self-consciously modernistic calendars, you can only see the data. Well, let's make the border show itself by adding an attribute to the <TABLE> tag. Set the border value at 1, like so:

<TABLE border="1">

Now we've got something. Not only do we see the data, we see the table structure that contains the data. Before you go any farther, have a little fun changing the value of the border. Try 2, 10, 20, whatever suits you, just to see how big you can make that border. After you've exhausted the fun in that little exercise, return the value to 1 and settle in for the next step.

Basic design note: it makes life much simpler when laying out tables to keep the borders visible while you construct the tables. Your last step, before popping the champagne, can be to turn the borders off.

Of course you want multiple rows. So let's do it. Wheee!

<TABLE border="1">  
 <TR>  
   <TD>Bleah!</TD>  
   <TD>Bleah!</TD>  
   <TD>Bleah!</TD>  
   <TD>Bleah!</TD>  
   <TD>Bleah!</TD>  
 </TR>  
 <TR>  
   <TD>Bleah!</TD>  
   <TD>Bleah!</TD>  
   <TD>Bleah!</TD>  
   <TD>Bleah!</TD>  
   <TD>Bleah!</TD>  
 </TR>  
 <TR>  
   <TD>Bleah!</TD>  
   <TD>Bleah!</TD>  
   <TD>Bleah!</TD>  
   <TD>Bleah!</TD>  
   <TD>Bleah!</TD>  
 </TR>  
<TABLE>

Fun, huh? Now we've got three evenly structured rows of "bleahs" marching along our page. Add a few more rows and a few more cells, and you've got a nice structure for a calendar. Not bad for five minutes' work.

Let's throw some monkey wrenches into our nice, neat (but limited) table structure. We'll start by noticing that the cell sizes conform to the content therein -- in other words, the cells adjust themselves to fit comfortably around the content, with no wasted space. And since the content is the same in all the cells, the table has a nice, even structure. Let's change that.

In the second row, third cell, change the content to read:

<TD>Abracadabra!</TD>

Notice what happens. That cell lengthens itself to accommodate the longer word, but so do the cells directly above and below that particular cell.

If you break the magic word into two parts, using a line break:

<TD>Abra<BR>Cadabra!</TD>

the cell becomes twice as high or as deep, depending on how you look at it. So do the cells in the entire row. Get used to how tables automatically adjust themselves, and you can save yourself a lot of time and trouble designing and redesigning the same table to appear how you want.