This is an example of an old glitch which many of the older browsers have (including early IE versions and all the Netscape 4s). It is that in some circumstances "spanning" cells will force other cells out of measure. It is especially problematic for specifying TD heights.
I think one thing contributing to the problem is that at least one TD height was miscalculated in your layout. The third cell in the first row should have been specified as height="160" rather than height ="120"
There are a number of workable solutions to make sure that all the browsers follow the same rules, but the one most used is to make sure that the first entire row of cells horizontally and and first column vertically don't have any spans specified, and explicitly size these cells as well.
You can see an example of this solution for your layout at:
Many programs, such as Fireworks, use the technique of creating a 1 pixel wide spacer row and column on the top and left of a complex layout to make sure the rest of the cells calculate with the correct heights and widths.
Another solution, as mentioned below, is to use nested tables.
Also, some older browsers ignore height statements altogether. If you care about those, you can use sized spacer gifs ( img src= pixel.gif height="120" width="1", for example) to make sure those browsers respect your specified heights.
In general, on a complex layout, the calculation time involved in figuring out all the widths and heights of the table cells can take older, slower machines a significant amount of time. Plus, the browser can't calculate the layout till the very end of the table has loaded, and any unsized images are also loaded. To speed up downloads on larger, more complex pages (not like this one), it is a good idea to use relatively simple stacking tables for the different parts of your layout, rather than one big complex one.
I will be happy to dump tables for layouts as soon as the vast majority of my viewers use browsers that respect CSS layouts correctly.
At 10:18 AM -0400 8/6/01, Tom Chadwin wrote:
>> At 04:36 AM 8/6/01, Roy Preston wrote:
>> >I've been fiddling with this for three or four days, and the
>> only way I can
>> >get it to display correctly without the border is to give
>> the whole table a
>> >'width' of 561 instead of 560, but **why** when all the
>> measurement add up?
>> >(562 also works!)
>Fiver gets you ten the problem will disappear if you redo it with nested
>tables (don't cringe, Maden), and not row/colspans. I seem to remember never
>being able to get cell spanning to work in Netscape. Again, not an
>explanation, but a possible solution.