Advanced HTML Tables

If you've been using HTML tables for a while then you'll know they don't always work out as intended. Your finely-crafted cell widths and layouts can easily turn into cubist artwork when rendered by a browser.

In this article we'll investigate some of the bugs that can trip you up when creating HTML tables, and also advanced uses, including nested tables, colored borders and free-standing panels with text wrapped around.

The tips here apply to Microsoft Explorer 5 and 6 and Netscape 4.5 and 4.7, since they're the most popular browsers. Most of them should also work in Netscape 6 and Opera. If you're not familiar with HTML code for tables, you might like to start with the WDVL tutorial.

Table Widths

Look at the HTML code of top professional sites and you'll notice something very curious - table widths are often not specified. Why is that?

The answer is that it removes a possible conflict when browsers render the table onscreen. This is an issue when cell widths within the table are specified in pixels, not percentages. If for some reason the pixel sum of the elements of your table and the specified table width don't match, the browser will get confused and adapt the table as it sees fit. You can avoid this conflict by simply missing out the table width. It then becomes more likely that the contents of the table will be rendered exactly as you intended.

One issue that often trips up designers is that any specified table widths must include cell spacing and cell padding, not simply the sum of the cell (<TD>) widths. So if you have a table with two 10 pixel cells and cell spacing set to 2 pixels, cell padding at 3 pixels, the total table width, if you insist on specifying it, should be 2 x 10 pixels for the cells, plus 2 pixels for the central spacing, and 4 x 3 pixels for the four vertical strips of padding, making 20 + 2 + 12 = 34 pixels, not 20 pixels.

If you don't specify cell padding and cell spacing in your table tag, most browsers will default to 1 pixel for spacing and 2 pixels for padding, but it's good practice to always specify them, since that removes any risk of misinterpretation by a browser.

An easy way to visualise cell spacing and cell padding, if they seem a little abstract, is to imagine a bookcase made of uniform pieces of wood and including vertical dividers - again made from the same wood. To protect the valuable books, the bookcase has thick felt padding lining each of its separate cells. In this allegory, cell padding is the thickness of the felt, and cell spacing is the thickness of the wood.

Specifying table width is less of an issue if the cells within your table have percentage widths, rather than pixel widths.

Table Cell Widths

Again, here we'll concentrate on cell widths specified in pixels, because if you specify widths in percentages, you're saying to the browser that you don't really care and it's free to adapt as it likes. Even if that's not quite what you want to say, it's certainly what the browser hears.

Tables containing cells specified in percentage widths are relatively uncommon in professional design. It's too difficult to control the way they're rendered. If you specify a 50%/50% split you'll rarely get what you want. More likely, a browser will show you something around 55%/45% onscreen, despite your clear instructions.

The same can apply - usually to a lesser extent - to widths specified in pixels. They too can be misinterpreted by browsers. Don't worry about this. Lots of designers experience the same problem. In most cases you simply make a minor adjustment to keep the browsers happy, and at least it's normally less of an issue than if you specify percentages.

Yet even when cell widths are properly specified in pixels, browsers can still mess them up. This is a classic problem when one particular cell contains a lot of content. That becomes the cell that wrecks the table layout.

Usually you can get over this problem by specifying the cell width for that particular cell. It's normal practice to specify widths for just one row of cells, rather than repeating them for every row and taking up space and time with useless information. It may be the first row that's specified, or if there's a row that's trickier than the rest, it may (should) be that one. It can even be the final row. Specifying widths for just one row saves on code and is helpful at the design stage if you need to make experimental layout changes. But it can lead to a maverick cell with lots of content distorting the grid.

Instead of specifying all the cell widths in one row, you may need to specify some in one row and some in another, depending on which row has the most cell content for a particular column. You may even need to specify the width more than once for cells in a single column, if there are two or more cells there with lots of content.

Incidentally, this habit browsers have of adapting table layouts isn't always a bad thing. If you work on a dynamic site and you're not sure how much content each cell will contain, it can work to your benefit, adjusting the widths that you specified in single row, probably your column headings row, and giving you the best-possible looking table.

Cells Too Narrow - Page 2