Above this line, you will see a new table as inserted in DW (I added the background color!) The table is 1 row and 5 columns and it is 500 pixels wide. I have set cell padding, spacing and borders to zero. Other than adding the background color, I have done nothing to the table after inserting it. Notice how the cells all line up nicely on the 100 pixel marks. Without other information to guide them, all browsers will uniformly distribute the table's width across each column.

Above this line you can see what happens when I click in the middle cell and type the single "a" character! It's shocking. The table is still 500 pixels wide, but the distribution of those pixels across the columns has changed so that the middle cell is now about 170 pixels wide. It changed for the following reasons.

Browsers don't like to render empty cells - and Internet Explorer does it differently than Netscape. To avoid the confusion that this can create for the person building the page, the wizards at Macromedia decided to pre-load each cell in a newly inserted table with a non-breaking space - see for yourself - here is the code right after I inserted the table on the top of the page (but before I added the background colors)-

<table width="500" border="0" cellspacing="0" 
cellpadding="0">

    <tr>

      <td>&nbsp;</td>

      <td>&nbsp;</td>

      <td>&nbsp;</td>

      <td>&nbsp;</td>

      <td>&nbsp;</td>

    </tr>

</table>

See all those " " things? They are non-breaking spaces and they were automatically put there by Dreamweaver when I inserted the table. They are there to 'prop' the cells open so that the entire table doesn't collapse when you view it in the browser. The   character gives each cell dimensionality in both the horizontal and the vertical.

Now, look at the code for the second table (after I added the single "a"
character) -

<table width="500" border="0" cellspacing="0" cellpadding="0">

    <tr>

      <td>&nbsp;</td>

      <td>&nbsp;</td>

      <td>a</td>

      <td>&nbsp;</td>

      <td>&nbsp;</td>

    </tr>

</table>

Notice that the middle cell has lost its " " and gained a single, lonely "a". The reason that the cell changes size is that the browser looks at the default font and the default character size within that font and it compares the size of the "a" character to the " " character (that's a space) and it concludes that the "a" character is wider than the " " character by about 1.7 fold. Having done this, the browser now calculates it must approximately double the width of the cell now containing the "a" character, because of this size difference. and so the cell goes from exactly 100 pixels to ~170 pixels. Thus, if the middle cell is 170 pixels, this leaves 330 pixels for the other 4 cells, or ~82 pixels per cell. Check it out on the ruler above!

Now look at what happens if I just change the "a" character to a monospace font by using the Font Field in the property inspector - the width of the cell drops from ~170 pixels to nearly 150 pixels. But the table is still 500 pixels wide!

So - what can we conclude from this? Well, it seems clear that the distribution of the widths of cells across a fixed width table is entirely dependent on the contents of those cells. It also seems clear that it is very DANGEROUS to assume that a cell will stay at a given size if it only contains text (unless there is some other cell in the same row or column that has a fixed width or height element in it). What are we to do? I have it! Let's specify a fixed width for that cell!

Look what happens if I try to fix the width of the middle cell at 75 pixels and begin to add more text (these are 1 row tables stacked on top of each other. rather than a single table!) (be ready for a big shock if you are using Netscape!) -

AARGH!

First of all, if you are looking with Netscape 4x, you will see that by fixing the width of the middle cell *only* -

     <td bgcolor="#CCFFCC">&nbsp;</td>
     <td bgcolor="#FFCCCC">&nbsp;</td>
     <td bgcolor="#CCFFCC" width="75" class="mono">a</td>
     <td bgcolor="#FFCCCC">&nbsp;</td>
     <td bgcolor="#CCFFCC">&nbsp;</td>

I have made the table go completely out of shape. And what's worse is that Netscape 4x has completely ignored my directive to make the middle cell 75 pixels wide.

This means that I can't constrain a cell to any given width just by setting its "W" field in the property inspector - and that's the truth!

Now look what happened in the next-to-last row - I simply put a space in the midst of the string of letters so that the characters would wrap in the cell. Guess what that did? It made the cell double the height, and hence the rest of the row! But not in Netscape, where you see about the same rendering as you see in the Dreamweaver edit window, except for me, in Netscape, the middle column is so wide that the space doesn't even break the line - even with the 75 character width specification - Netscape just doesn't obey this as anything other than a suggested MINIMUM width!

This illustration also points out an interesting difference between Netscape and Internet Explorer's method of dealing with tables. Intenet Explorer tries to follow the 75 pixel width specification until it can no longer do so because of the cell's content at which point it expands the cell. Netscape, on the other hand, works as expected until I enter that 75 pixel cell width, at which point it looks at each of the other cells, resizes them based on their content (remember the " ") and gives the remainder of the space to the middle cell - in spite of the 75 pixel specification!

Now look at the last row. See what happens to the table when I put a single "a" character in the second cell? It's deja vu all over again!

Friends, this is why people hate tables and why they get frustrated trying to drag cell borders and set cell widths and heights. The bottom line is - just say no to all of these attempts to control your tables. If you need a cell to be a certain width, shim it with a transparent GIF. Watch what happens to the table above when I add a second row and put 100 pixel wide and 1 pixel tall shims in each cell in this second row -

	a	abcdefghi jklmn

See how the columns are now evenly spaced again? Also, see how the second row containing the shims is barely visible (if at all)? That's because when I put in the shims, DW takes *out* the " " characters and so the cells collapse around the shims (to make this second row easily visible, I have made the table's border setting "1") to make that second row only 1 pixel high. And this time, it looks the same in both Netscape and Internet Explorer.

By the way, while you are reading this, try resizing your browser window and note that the tables are unaffected by this - that's what a fixed width table does.

OK - the message is to shim your tables! Don't depend on Cell Heights or Widths or text content to hold your Cells at the right size. If you do, you'll be frustrated by an uncooperative page and wonky tables!

A final note - download this page and look at it in Dreamweaver. You will be able to see how I did the tables and the fonts, and more importantly, you'll see that there is no trickery here....

Keep dreamin'!