Nested tables messed up in FireFox (you heard me)

[Jim]

I'm working on a new layout for my site and everything shows up
perfectly as expected in IE but FF doesn't behave as expected. FF
adds a lot of extra space when I resize the spacer images on the sides
of the page. If you select the radio buttons you'll see what I mean.
Event the initial size seems to be off a bit as you can see the gaps
in the images when the page first loads.

http://www.stadiumgrille.com/index.aspx

The older layout uses a similar html layout so I know it works but for
some reason it's not working now.

http://www.stadiumgrille.com/index.asp

Anyone see something I don't?

 

[Ben C]

I'm working on a new layout for my site and everything shows up
perfectly as expected in IE but FF doesn't behave as expected. FF
adds a lot of extra space when I resize the spacer images on the sides
of the page. If you select the radio buttons you'll see what I mean.
Event the initial size seems to be off a bit as you can see the gaps
in the images when the page first loads.

If you'd like to explain exactly why you expect your riot of rowspanning
and colspanning cells to look any particular way I would be interested
to hear it.

In a table each cell gets a height from the whole row and the height of
the row is a function of the contents of each cell. This is exactly the
behaviour you _don't_ want for this page.

When you click one of the radio buttons, a different list of burgers
appears below, changing the height of the main content area a bit. This
shouldn't affect the sidebars at all (or certainly not the spacing
between items on the sidebars), so just don't make the sidebars part of
the same table in the first place.

In fact there's no reason to use tables at all on that page.

Rowspan and colspan make life even more complicated because the browser
has to decide how to distribute the contribution of a cell's content
dimensions and any styled or percentage dimensions on it across the rows
or columns it spans.

Only a very small amount of this is specified in any detail, so you
cannot expect identical results between any two browsers.

 

[Bergamot]

I'm working on a new layout for my site and everything shows up
perfectly as expected in IE but FF doesn't behave as expected. FF
adds a lot of extra space when I resize the spacer images on the sides
of the page.

Ack, this talk of nested tables and spacer images makes my head spin.
That stuff is sooooooooooo last century.

http://www.stadiumgrille.com/index.aspx

Slice-and-splice designs are ugly in more ways than one, and so
unnecessary. Try using background colors and border properties instead
of all those solid color images. It will simplify the design, plus make
it a lot faster loading. There should be no need for spacer images at all.

The only graphics you need on that page are the logo, the navigation
buttons and the shadowing. Everything else can go. You don't need all
those rowspans and colspans, either. Simplify!

 

[Jim]

The popularity of the style of my design or it's "beauty" was not my
question. I understand that many feel the css is the only way to go
but the fact remains that, and I know that this is hard to swallow,
table designs do work and the only browser that seems to choke on them
is FireFox. IE, Opera and Safari seem to handle it fine.

If you'd like to explain exactly why you expect your riot of rowspanning
and colspanning cells to look any particular way I would be interested
to hear it. ....
Rowspan and colspan make life even more complicated because the browser
has to decide how to distribute the contribution of a cell's content
dimensions and any styled or percentage dimensions on it across the rows
or columns it spans.

From what I can gather from here:

http://www.htmlcodetutorial.com/help/sutra8136.html
I should be abble to have fixed height and dynamic cells in FireFox
but that doesn't seem to work either.

 

[Ben C]

The popularity of the style of my design or it's "beauty" was not my
question. I understand that many feel the css is the only way to go
but the fact remains that, and I know that this is hard to swallow,
table designs do work and the only browser that seems to choke on them
is FireFox. IE, Opera and Safari seem to handle it fine.

No I was asking a real question. What _specifically_ is it that you
think Firefox is doing wrong with your page, in other words, what
behaviour do you expect, and why? If it turns out there are actually
bugs in Firefox with this you can report them. Equally likely in this
case though, as I was trying to explain, is that you are looking at
legitimately different interpretations of how to compute row and column
dimensions when rowspan and colspan are involved, since this is not
precisely described in any W3C standard or specification.

In the case of your page the suggestion is not just general "tables bad
CSS good". You have produced unnecessarily complex input that relies on
unspecified behaviour. Speaking purely practically, this table design of
yours does not work. OK it looks the way you want it to on IE, but do
you know why? How did you arrive at this design in the first place?

I don't believe you need all these rowspans and colspans and nested
tables, your layout is fairly simple and could be realized with a very
small amount of CSS that was easy to understand both by humans and by
browsers. I think this will be much easier to do that trying to sort out
what you've got.

 

[Jim]

No I was asking a real question. What _specifically_ is it that you

think Firefox is doing wrong with your page, in other words, what
behaviour do you expect, and why? If it turns out there are actually
bugs in Firefox with this you can report them. Equally likely in this
case though, as I was trying to explain, is that you are looking at
legitimately different interpretations of how to compute row and column
dimensions when rowspan and colspan are involved, since this is not
precisely described in any W3C standard or specification.

I apologize for mistaking your question for malace.

The shadows on the side of the text is made up of 3 images (top
corner, middle, bottom corner). When the radio button is selected the
size is increased 400 pixels to accomidate the size. Also there are
two spacers in the bottom corners which also increase in size the same
amount to strech the table. What is happening (which is what I want
to not happen) is that the other cells in the table increase in size
even though the images are not changed. In the other broswers, the
other cells stay their original sizes (before selecting a radio
button) and thus no gaps between the image borders and the cell
borders.

In the case of your page the suggestion is not just general "tables bad
CSS good". You have produced unnecessarily complex input that relies on
unspecified behaviour. Speaking purely practically, this table design of
yours does not work. OK it looks the way you want it to on IE, but do
you know why? How did you arrive at this design in the first place?

I don't believe you need all these rowspans and colspans and nested
tables, your layout is fairly simple and could be realized with a very
small amount of CSS that was easy to understand both by humans and by
browsers. I think this will be much easier to do that trying to sort out
what you've got.

The table was created by exporting images slices to html from
FireWorks. I'm using FireWorks MX and after some searching I see that
starting with MX 2004 you can export to CSS layout instead of html. I
have the disk at home but never installed it since the version I had
work. I've never been one to upgrade an application for the sake of
newest and not patches or bug fixes.

 

[Ben C]

I apologize for mistaking your question for malace.

The shadows on the side of the text is made up of 3 images (top
corner, middle, bottom corner). When the radio button is selected the
size is increased 400 pixels to accomidate the size. Also there are
two spacers in the bottom corners which also increase in size the same
amount to strech the table. What is happening (which is what I want
to not happen) is that the other cells in the table increase in size
even though the images are not changed. In the other broswers, the
other cells stay their original sizes (before selecting a radio
button) and thus no gaps between the image borders and the cell
borders.

It sounds like this is a problem with how to distribute a rowspanning
row's height across the rows it spans. At the end of this message I've
put an example. Although the three non-spanning cells are each set to
height: 40px, Firefox makes them all about the same height (about a
third of 400px). Konqueror and Opera make the first two 40px and the
last one whatever's left. I don't have IE.

Which is right? Both. It's not specified and either behaviour is
reasonable. The HTML below asks for the first cell to be 400px high and
to be the same height as three other cells which are each 40px high. But
3 x 40 does not equal 400. So what is the browser supposed to do? Make
as many cells the asked-for height as it can, or make as many cells as
close as it can to the asked-for height?

In your case there may not even have been styled heights, just images
inside the cells that established their content heights, I can't
remember it in that much detail.

Coincidentally dorayme described a very similar problem recently. But in
that case it happened to be the behaviour of Firefox, which evenly
distributed the height of a spanning row between the rows it spanned,
that was desirable.

The table was created by exporting images slices to html from
FireWorks. I'm using FireWorks MX and after some searching I see that
starting with MX 2004 you can export to CSS layout instead of html. I
have the disk at home but never installed it since the version I had
work. I've never been one to upgrade an application for the sake of
newest and not patches or bug fixes.

Don't bother to upgrade it. Instead read some of the introductions to
CSS recommended in these groups and do it by hand. A tool may claim to
make things easy but the truth is things are only easy when you
understand them.

Here's that example:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/REC-html40/strict.dtd">
<html>
<head>
<title>Test Page</title>
<style type="text/css">
td
{
background-color: green;
width: 100px;
}
</style>
</head>
<body>
<table>
<tr>
<td style="height: 400px" rowspan=3></td>
<td style="height: 40px"></td>
</tr>
<tr>
<td style="height: 40px"></td>
</tr>
<tr>
<td style="height: 40px"></td>
</tr>
</table>
</body>
</html>

 

[Jim]

Looks like FireWorks doesn't actually export to css layouts even in
their newest version I'm curently working on an all css version of
the site. I do know css but it's not my standard layout style because
of the tools I use spit out table layouts. I'll post an update when
it's complete.

 

[Ben C]

Looks like FireWorks doesn't actually export to css layouts even in
their newest version I'm curently working on an all css version of
the site. I do know css but it's not my standard layout style because
of the tools I use spit out table layouts.

Good luck, that's definitely the right way to go.

 

[Jim]

OK the conversion is complete. It took about 2 hours but its done.
There are still some differences between FF and IE but I can live with
them. FF seems to leave a space between the div at the bottom and the
content in the middle. Seems neither browser agrees on how to
interperate pixel height and width. Thankfully this is done in .Net
so I can easily apply the layout to the other pages very easily.
Thanks for your help.


CSS version
http://www.stadiumgrille.com/test.aspx

Table Version
http://www.stadiumgrille.com/index.aspx

 

[rf]

http://www.stadiumgrille.com/test.aspx

http://barefile.com.au/jim.gif

--
Richard.

 

[Ben C]

OK the conversion is complete. It took about 2 hours but its done.
There are still some differences between FF and IE but I can live with
them. FF seems to leave a space between the div at the bottom and the
content in the middle. Seems neither browser agrees on how to
interperate pixel height and width.

I'm fairly sure they do agree on that. I think the problem may be
because you're using &nbsp; in a few places after inline images and this
is causing small gaps of the height of the font size.

I think it's a good effort for 2 hours work. I would suggest:

1. All that JavaScript seems a bit pointless.
2. No need to use 1x1 pixel images resized everywhere ("LeftSpacer"
etc.) and those &nbsp;s are quite suspicious. You can just set the
dimensions of the box these days.
3. You've got styles for .MainTable but no element with that class (but
you have got an id #MainTable)
4. All this exact pixel sizing and setting of small font sizes is a bit
unnecessarily inflexible, but I'm not really commenting on the design
here as others know more about such things.

I think most of these things are basically left-over Fireworks bogosity.

[...]

 

[Beauregard T. Shagnasty]

OK the conversion is complete. It took about 2 hours but its done.

....

While I applaude your effort to update...

CSS version
http://www.stadiumgrille.com/test.aspx

Table Version
http://www.stadiumgrille.com/index.aspx

....personally, I don't see much difference in the two pages - from a
"code" point of view. The test.aspx is a mess of div soup and huge
amounts of extraneous JavaScript, but still filled with nested tables.
The original page is a mess of nested tables sprinkled with old
fashioned spacer crap, but with the same load of JavaScript.

*One* link in the test page:

<div id="NavIndex"><a href="index.aspx" target="_top"
onclick="MM_nbGroup('down','group1','Home','images/home_normal.gif',1)"
onmouseover="MM_nbGroup('over','Home','images/home_hot.gif','images/home_hot.gif',1)"
onmouseout="MM_nbGroup('out')"><img src="images/home_normal.gif"
alt="Home" id="Home" /></a></div>

and the same link in the tabled page:

<td><a href="index.aspx" target="_top"
onclick="MM_nbGroup('down','group1','Home','images/home_normal.gif',1)"
onmouseover="MM_nbGroup('over','Home','images/home_hot.gif','images/home_hot.gif',1)"
onmouseout="MM_nbGroup('out')"><img src="images/home_normal.gif"
alt="Home" id="Home" /></a></td>

There seems to be no advantage of one over the other, especially since
JavaScript is so necessary for successful use of your pages.

At my last place of employment prior to retirement, the only people who
would see JavaScript was us dozen folks in the programming department.
The other 250 people in sales, customer support, data entry, etc. had
all JavaScript stripped by the company firewall.

Considering that people at local businesses may well be your prime
visitors, you should consider that many of them won't be able to use
your site.