Notes On Using Tables


Tables do have their little problems—well, some browsers have little problems with tables. Still, none of them are as bad as the many div float problems of IE’s broken float model. Let’s take a look at some common ones, with easy solutions.

First, we need to remember the difference between a table and a div, as containers. Without a width setting,

  • Divs expand to fill their parent container (they have an internal “pressure”).
  • Tables and cells collapse around their contents (they have an external “pressure”).

Since tables and cells collapse, and since the CSS directive { min-width:something; } is still not supported by all browsers, when we set a cell some width we must fill it with something that is guaranteed to push it out to that width. The old way of doing this is with that irritating <img src='spacer.gif' width='something'> gizmo. Fortunately, with a CSS-controlled cell, that isn’t necessary, because we can set a pixel width on anything we will always put in the cell—it does not have to be an invisible image—it can be a text heading, for example.

In the CSS on the example above, I deliberately set #lft h1 width to a pixel value, which effectively establishes the min-width for the cell and keeps the fluid right column from squashing it. Fortunately, it’s a simple width setting in the CSS file (once), not deprecated markup in the HTML (many times). And it doesn’t add clutter or bloat to the code.

For a fluid-width cell, do not set the width at all. Just let the cell’s contents fluff it out to fill the remaining space. Fluid-width content cells typically contain wrapped paragraphs of text. Wrapped text is “springy,” and causes it’s containing cell to push against an adjacent cell, which is why we need to nail a fixed minimum for the adjacent cell.

  • Divs must be floated to create columns (and the float was never designed for that purpose).
  • Tables always create an x-y grid structure (and they don’t care what they contain—page layout or little-league scores).

Floated divs may indeed create visual columns, but the columns are of different lengths, and those lengths change as textural content flows to the user’s particular browser. This becomes a problem when doing things like placing a visible left or right border in a div, as the border will simply stop where the div ends. On the other hand, a visible vertical border in a table cell will always run the full height of the row, which is the height of the tallest cell. The exception is where we want to use the full page width for content after the bottom of the shorter column. In that case, make a single cell for content, and then nest a floated table or div therein for the short column. I do that sometimes for a “Page Contents” floater—i.e., links to same-page sections that I don’t want in the main menu. You will note that the text of this article wraps the right sidebar menu. Yep, it’s a floated div, and that’s why I used it herein, instead of table cells.

  • Both divs and table cells are containers and as such enjoy margin (outside) and padding (inside), backgrounds, borders, and text formatting.

Every table element may be CSS-controlled just like divs, with the added benefits of (a) no floating needed, and (b) it automatically renders a grid structure. That’s just what it is, and a table should be used for layout anytime a real grid structure is needed. Regardless of any prejudice against using tables for layout, the table is the only structure available in HTML that renders a grid structure.

  • Browsers have ugly defaults with regard to tables, which must be overridden, unless you actually want a table to look like antique HTML from 1995.

Table overrides should always be specified in the CSS file prior to effectively using tables, and particularly for layout tables. One of these is border-collapse:collapse. Browsers default to the border:separate model, which puts spacing between cell borders, complicating the use of margin and padding, usually looks bad, and is totally unnecessary. Browsers also impose poor defaults for margins, borders, and padding, text-align, and vertical-align.

For example, the table defaults for a fluid layout table should be: border-collapse:collapse; width:100%; margin:0; border:0;, and then set the cells’ defaults as needed, usually adding some css padding to make the text stand off the edges some pleasing amount. Fifteen to thirty pixels looks nice in a full-screen fluid layout table. It is not necessary to insert empty rows or columns to make margins!


Tables have some funny behaviors that drive one crazy until one learns CSS tableology. For example,

  • You can set a table’s default text-alignment, font-size, etc in the table tag’s CSS class, but you can’t set the default padding, unlike the old cellpadding=px. Padding must be set in a class or ID and applied to each TD. It does take a while, and some frustration, to remember which attributes are set at the table level and which ones at the cell level.
  • Setting (or nulling) a table’s border with CSS only applies to the outer perimeter of the table, and does not set any border for cells, which must be set in the CSS for the TH and TD tags.
  • Setting a table’s background may or may not have any effect unless the TH and TD backgrounds are set to transparent—and doing it that way messes some browsers. Sometimes a transparent cell background will blow right on through the table’s background and show the background of the table’s parent container.
  • IE doesn’t really set a cell border:0 to zero width, it sets it to 1 and makes it transparent. To get around that, set the table background and the cell background the same.
  • Likewise, layout tables that are width:100% and margin:0 and have any border will sometimes bump on the vertical scroll bar, which bumps on the horizontal scroll bar, which stays on no matter what the browser’s width. This is another frustrating problem with IE. Either zero the border, or set fluid layout table width to 98 or 99 percent.
  • To make sure that stacked tables visually join, set table margins to 0, and make sure there is nothing between tables, not even a space.

Well, I hope this has been helpful. Someday, perhaps we’ll see a template description that reads, “Uses CSS and stacked tables, not floated divs.” Probably not.

In the next series of articles, we’ll look at some easy CSS tricks and tips.

Leave a Reply

Your email address will not be published. Required fields are marked *