Nested tables messed up in FireFox (you heard me)

Discussion in 'HTML' started by Jim, Jul 26, 2007.

  1. Jim

    Jim Guest

    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?
     
    Jim, Jul 26, 2007
    #1
    1. Advertising

  2. Jim

    Ben C Guest

    On 2007-07-26, Jim <> wrote:
    > 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.
     
    Ben C, Jul 26, 2007
    #2
    1. Advertising

  3. Jim

    Bergamot Guest

    Jim wrote:
    > 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!

    --
    Berg
     
    Bergamot, Jul 26, 2007
    #3
  4. Jim

    Jim Guest

    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.
     
    Jim, Jul 27, 2007
    #4
  5. Jim

    Ben C Guest

    On 2007-07-27, Jim <> wrote:
    > 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.

    >>s 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.
     
    Ben C, Jul 27, 2007
    #5
  6. Jim

    Jim Guest

    > 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.
     
    Jim, Jul 27, 2007
    #6
  7. Jim

    Ben C Guest

    On 2007-07-27, Jim <> wrote:
    >> 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.


    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.

    >> 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.


    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>
     
    Ben C, Jul 28, 2007
    #7
  8. Jim

    Jim Guest

    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.
     
    Jim, Jul 29, 2007
    #8
  9. Jim

    Ben C Guest

    On 2007-07-29, Jim <> wrote:
    > 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.
     
    Ben C, Jul 29, 2007
    #9
  10. Jim

    Jim Guest

    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
     
    Jim, Jul 30, 2007
    #10
  11. Jim

    rf Guest

    rf, Jul 30, 2007
    #11
  12. Jim

    Ben C Guest

    On 2007-07-30, Jim <> wrote:
    > 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.

    [...]
    > CSS version
    > http://www.stadiumgrille.com/test.aspx
    >
    > Table Version
    > http://www.stadiumgrille.com/index.aspx
     
    Ben C, Jul 30, 2007
    #12
  13. Jim wrote:

    > 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.

    --
    -bts
    -Motorcycles defy gravity; cars just suck
     
    Beauregard T. Shagnasty, Jul 30, 2007
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    0
    Views:
    383
  2. mybigsuccess

    Have you heard, TIENES EL CONTROL

    mybigsuccess, May 1, 2006, in forum: Java
    Replies:
    0
    Views:
    398
    mybigsuccess
    May 1, 2006
  3. mybigsuccess

    Have you heard, TIENES EL CONTROL

    mybigsuccess, May 1, 2006, in forum: Java
    Replies:
    0
    Views:
    358
    mybigsuccess
    May 1, 2006
  4. ennio
    Replies:
    2
    Views:
    869
    Peter Van Weert
    Sep 7, 2006
  5. mybigsuccess

    Have you heard, TIENES EL CONTROL

    mybigsuccess, May 1, 2006, in forum: C Programming
    Replies:
    0
    Views:
    307
    mybigsuccess
    May 1, 2006
Loading...

Share This Page