Closed Bug 409736 Opened 17 years ago Closed 16 years ago

[regression] The overflow of automatic layout table cells can't be clipped

Categories

(Core :: Layout: Tables, defect)

Product:
Core
Component:
Layout: Tables
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: stevee, Unassigned)

References

(
URL
)

Details

(Keywords: regression, testcase)

Attachments

(3 files, 1 obsolete file)

minimal test case
1.74 KB, text/html
Details
Testcase 3: tables with fixed width; content with overflow:scroll, hidden and auto
3.54 KB, text/html
Details
simple sample and how it respects overflow hidden on HEIGHT as in the site
2.27 KB, text/html
Details 
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b3pre) Gecko/2007122201 Minefield/3.0b3pre ID:2007122201

1. New profile, start firefox
2. Visit http://support.mozilla.com/tiki-view_forum_thread.php?comments_parentId=1682&topics_offset=4&topics_sort_mode=lastPost_desc&forumId=1

Expected:
- Page is rendered at a sensible width, no horizontal scrollbar is required.

Actual:
- Page is rendered far too wide, and an unnecessary horizontal scrollbar is required.

Works: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b2pre) Gecko/2007120411 Minefield/3.0b2pre
Broken: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b2pre) Gecko/2007120414 Minefield/3.0b2pre

Checkins to module PhoenixTinderbox between 2007-12-04 10:00 and 2007-12-04 15:00 : 
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-12-04+10&maxdate=2007-12-04+15&cvsroot=%2Fcvsroot

Maybe due to bug 402567, but I wouldn't like to bet on it since I'm usually wrong with such guesses ;-)
Flags: blocking1.9?
Hmm, WebKit displays that one page the same as Gecko nightlies.
The <body> of the page is set to display:table; and one of the posts contains a <pre> block (overflow:auto).
OS: Windows 2000 → All
Hardware: PC → All
Attached file minimal test case — 

    
  
Blocks: 402567
Flags: blocking1.9? → blocking1.9-

    
    

    
  


  
As you can read in above dup bug and in this testcase, the problem is a the overflow css property of descendant of a table element is not handled by Firefox 3. I think it's a blocking 1.9 bug.

    
    

    
  
I don't think we're going to change this.

    
    

    
  
Can I ask you why? This bug is not present in Firefox 2, and doesn't show up in Fx3 with any ancestor other than a table element.

CSS specs of W3C are very clear:

> 11.1 Overflow and clipping
> 
> Generally, the content of a block box is confined to the content edges of the 
> box. In certain cases, a box may overflow, meaning its content lies partly or 
> entirely outside of the box, e.g.:
> 
> * A line cannot be broken, causing the line box to be wider than the block 
> box. [...]
> 
> Applies to:  	non-replaced block-level elements, **table cells**, and 
> inline-block elements

http://www.w3.org/TR/2007/CR-CSS21-20070719/visufx.html#overflow-clipping

    
    

    
  
This bug has nothing to do with whether overflow applies; it's about table width calculation (and whether overflow affects table width calculation).

    
    

    
  


  
No, overflow property it's not rendered at all if a table element is the ancestor. 
If you see the new attached testcase, now the width of the tables is fixed and all overflow cases are included.


(Anyway, I don't know why a descendant of a table element should be treated differently from a descendant of a div one.)

        Attachment #319167 -
        Attachment is obsolete: true

    
    

    
  
(In reply to comment #8)
> This bug has nothing to do with whether overflow applies; it's about table
> width calculation (and whether overflow affects table width calculation).
> 
(In reply to comment #9)
> No, overflow property it's not rendered at all if a table element is the
> ancestor. 

Lucas: What dbaron was saying is that tables expand to fit their contents' min-width.  And bug 402567 made us match IE / WebKit by propagating min-width up through "overflow" frames.

So, overflow property is being handled correctly here.  The only question is whether the table should be ignoring it's child's min-width in this case.

    
    

    
  
FWIW:
WebKit agrees with the FF3 behavior on:
 - This bug's URL
 - all three testcases on this bug

IE7 agrees with the FF3 behavior on:
 - testcase 2
 - testcase 3
(though it matches FF2 on the first "minimal testcase" and the URL.)


    
    

    
  
(In reply to comment #12)
 
> IE7 agrees with the FF3 behavior on:
>  - testcase 2
>  - testcase 3
> (though it matches FF2 on the first "minimal testcase" and the URL.)

But IE 7 doesn't support 'display:table;'. That behaviour on the first test case is expected.



    
    

    
  
(In reply to comment #11)
> Lucas: What dbaron was saying is that tables expand to fit their contents'
> min-width.  

I disagree. On W3C site, it's stated that the width of a table with automatic layout, and not the min-width, must be equal to the width of their _columns_. I can argue than the width of a column must be rendered after a cell has computed is overflow property. Furthermore it's stated the rendering of an automatic layout is mainly left to browser's choice:
http://www.w3.org/TR/CSS21/tables.html#auto-table-layout

For the fixed layout, it's clearly stated "the horizontal layout of the table does not depend on the contents of the cells; it only depends on the table's width, the width of the columns, and borders or cell spacing", and "Any cell that has content that overflows uses the 'overflow' property to determine whether to clip the overflow content"


Currently, setting the overflow property for a table cell is useless. I don't think this is what a web developers expects. I understand it will cause a regression to bug 402567, but IMO current behaviour is not W3C compliant and is not desired :-)

    
    

    
  
(In reply to comment #14)
> On W3C site, it's stated that the width of a table with automatic
> layout, and not the min-width, must be equal to the width of their _columns_. 

Well, yes, but the columns get their min-width from their _cells_.  See section 17.5.2.2 Automatic table layout, steps 1 and 2.

> I
> can argue than the width of a column must be rendered after a cell has computed
> is overflow property.

I agree 100%.  That's not the issue.  We most definitely do "compute the overflow property" way before we compute widths.

The thing is this:  when the table (or the table-column, as you point out) computes its cells' min-widths, it asks the overflow:XXX frame for its *minimum width* per the section I referenced above.  In response, the overflow column passes through the minimum width of *its* contents.

> Furthermore it's stated the rendering of an automatic
> layout is mainly left to browser's choice:
> http://www.w3.org/TR/CSS21/tables.html#auto-table-layout

Sure, and in this case, we made a choice to behave as I've stated above, for reasons described on bug 402567. :)

> For the fixed layout, it's clearly stated "the horizontal layout of the table
> does not depend on the contents of the cells; it only depends on the table's
> width, the width of the columns, and borders or cell spacing", and "Any cell
> that has content that overflows uses the 'overflow' property to determine
> whether to clip the overflow content"

Right, and we handle that as specified.  None of the testcases on this bug request fixed table layout, but when I modify testcase 3 to use fixed layout, I get a 100px-wide table with scrollbars on the scrollframes (and with clipped content on the overflow: hidden frame)  So, I'm not sure why you brought that up.

> Currently, setting the overflow property for a table cell is useless. 

That may be true for auto-layout tables...  It's not true for fixed-layout tables, at least, as I said in the previous paragraph. :)

> I don't think this is what a web developers expects.

Agreed, in some situations.  And I think we're interested in allowing web developers to choose the old behavior, with some -moz-XXX tag.  (But FWIW, we're now compatible with IE / WebKit behavior, which is also important)

> IMO current behaviour is not W3C compliant 

Sure it is -- if you still think it's not compliant, given my comments above, please detail how.

    
    

    
  
(In reply to comment #15)
> Well, yes, but the columns get their min-width from their _cells_.  See 
> section 17.5.2.2 Automatic table layout, steps 1 and 2.

This is in the non-normative section. And doesn't contemplate the overflow property presence.

IMO if overflow properties in cells of an automatic layout table are specified, the browser should apply them to reduce the width of the table to prevent the page overflow, or to prevent an enlarging of an already overflowed page, as much as possible. And if a width or a max-width is specified, they should be taken into account. This can be done without breaking W3C specs.

> we made a choice to behave as I've stated above, for reasons described on bug 
> 402567. :)

Can you link me the comment of the bug where the reason is explained? That bug report is a bit long... thank you in advance :-)

> Right, and we handle that as specified.  None of the testcases on this bug
> request fixed table layout, but when I modify testcase 3 to use fixed layout, 
> I get a 100px-wide table with scrollbars on the scrollframes (and with clipped
> content on the overflow: hidden frame)  So, I'm not sure why you brought that
> up.

I was wrong. I thought table-layout has 'fixed' and not 'auto' as default value, if width is specified

> > Currently, setting the overflow property for a table cell is useless. 
> 
> That may be true for auto-layout tables...  It's not true for fixed-layout
> tables, at least, as I said in the previous paragraph. :)

Automatic layout tables are the default behaviour as I wrote before. And normally it's better to use them to have a liquid but easy output. So it will complicate the web designer work.

> I think we're interested in allowing web developers to choose the old 
> behaviour, with some -moz-XXX tag

It's a solution, but I not agree because IMO there's no reason you must specify another property to enable 'overflow' property in tables. The fact you specify this property means you want the content doesn't overflow the specified width or doesn't overflow the page.

    
    

    
  
(In reply to comment #16)
> (In reply to comment #15)
> > Well, yes, but the columns get their min-width from their _cells_.  See 
> > section 17.5.2.2 Automatic table layout, steps 1 and 2.
> 
> This is in the non-normative section. And doesn't contemplate the overflow
> property presence.

Right -- I was just pointing out that we do in fact match the spec (even on this non-normative point), rather than going against it as you were suggesting.
 
> IMO if overflow properties in cells of an automatic layout table are specified,
> the browser should apply them to reduce the width of the table to prevent the
> page overflow, or to prevent an enlarging of an already overflowed page, as
> much as possible. And if a width or a max-width is specified, they should be
> taken into account. This can be done without breaking W3C specs.

That sounds nice, but it's hard to nail down what under what situations that logic should apply.  What sort of elements should tables with overflow:XXX content stick be allowed to stick out of, and what elements should clip their width?  None of this is standardized, so we could just pick something sensible, but it'd only work in Firefox and nowhere else, so that wouldn't be much use for the broader web.  (hence the idea of using a using a "-moz-XXX" experimental tag to flesh out possible alternate behaviors, without messing up rendering on other browsers)

> > we made a choice to behave as I've stated above, for reasons described on bug 
> > 402567. :)
> 
> Can you link me the comment of the bug where the reason is explained? That bug
> report is a bit long... thank you in advance :-)

See bug 402567 comment 23 and bug 402567 comment 28 in particular.  Aside from fixing the original Zimbra regression, the main justification for the change was for web compatibility, i.e. to match the behavior already exhibited by the two other most popular rendering engines (IE and WebKit).

> > > Currently, setting the overflow property for a table cell is useless. 
> > That may be true for auto-layout tables...
> Automatic layout tables are the default behaviour as I wrote before. And
> normally it's better to use them to have a liquid but easy output. So it will
> complicate the web designer work.

No, it won't really add any additional complications -- if the Web designer wants their website to look OK in IE7 and Safari/WebKit, they're *already* going to have to deal with these exact issues to make their site work in those browsers.  Whatever solution they use there should work in Firefox 3.  So, I'd argue that the new behavior in fact makes it LESS complicated for web developers, because the three most popular rendering engines now agree on this particular point, so they need fewer browser-specific hacks.  (This is the general "web compatibility" argument mentioned earlier)

> The fact you specify this property [overflow]
> means you want the content doesn't overflow the specified width
> or doesn't overflow the page.

Not necessarily, when tables come into play.  Maybe that's what *you're* wanting when you set that property :), but that's not what the standard says you should expect, and that's not what any browsers really implement right now.

    
    

    
  
(In reply to comment #17)
> That sounds nice, but [...] what sort of elements should tables with 
> overflow:XXX content stick be allowed to stick out of, and what elements 
> should clip their width?

Simple: all of them.
This is the case: you have three cells with overflow:hidden. First is large 100 px, the second 200, the third 300; their total width is 600. Without hidden content the table will overflow of 200px. Well, simply in the first cell 200/600*100 = 33.3p -> 33 pixels will be hidden, in the second one 200/600*200 = 66.6p -> 67 pixels, in the third 200 - 33 - 67 = 100 pixels.
First of that, if some cells with overflow property has a width or max-width property lower than the cell content size, the overflow method is applied to those cells so their width will be equal to specified width/max-width value.

> None of this is standardized, so we could just pick something sensible,
> but it'd only work in Firefox and nowhere else, so that wouldn't be much use
> for the broader web.  (hence the idea of using a using a "-moz-XXX"
> experimental tag to flesh out possible alternate behaviors, without messing up
> rendering on other browsers)

It's reasonable. I still don't know why someone should use the overflow property in a table if it will not work... :-P but anyway it could be a good "prevention principle".

    
    

    
  
I can change the title of this bug, or it's better to make a new bug for a new -moz property proposal?

    
    

    
  
new bug is better -- I just filed bug 435293 for this.
Depends on: 435293

    
    

    
  
I reported this on my bug https://bugzilla.mozilla.org/show_bug.cgi?id=441014

This is not expected nor acceptable because dinamic contents on a table will render the div overflow:hidden useless on pages that change the DIV dinamically, which is an undeniable trend with DHTML and Ajax sites popping up everywhere on liquid layouts, which is also getting rates up since it's a better option for the wide range of display proportions out there (widescreens, 4:3, 5:4, small, bigs).

This site renders perfectly fine with FF2 and IE7, but not with FF3: www.daisuki.com.br ... the cause is the neat slider with ajax keeps moving divs inside the table cell, the divs are thus larger than the table cell and solved by overflow:hidden. Problem is, FF3 expands the DIV with overflow hidden, expanding it all the same as if it were an old non compliant browser. Only IE6 displays this bug at that site (solved by javascript forcing fixed width on the DIV with a setTimeout to check if the user redimensioned the window)

DO you seriously believe making designers looking for DHTML/Ajax (tendency) on liquid layouts (tendency) to have to come with the lame solution of a timeout to recalculate the DIV if the window changes width while, if you could just make contents in a DIV respect overflow:hidden, as a developer would expect, all problems would be solved?

I pledge this bug to be solved with quite urgency, as I for one make sites with liquid layouts filled with DHTML, and this bug WILL render my sites NOT COMPATIBLE with "the best browser ever", and when people ask me why, I will be forced to say it's Firefox 3 fault, not mine, as stated on this very bug, where you mention you "choose" this to be the case.

We start choosing the easier way out, we loose everything Mozilla/Firefox always fought for: the BEST compliance with standards with the BEST end result. No gain to keep this bug.
Component: Layout → Layout: Tables
Keywords: css2, 
          
            testcase
QA Contact: layout → layout.tables
Summary: [regression] This SUMO Page renders wider than it used to → [regression] Cells' overflow of automatic layout tables can't be clipped
Summary: [regression] Cells' overflow of automatic layout tables can't be clipped → [regression] The overflow of automatic layout table cells can't be clipped

    
    

    
  
(In reply to comment #20)
> new bug is better -- I just filed bug 435293 for this.

(oops, I pasted in the wrong bug number -- the correct bug for adding a -moz-XXX property is bug 433621.)

    
    

    
  
(In reply to comment #21)
> This site renders perfectly fine with FF2 and IE7, but not with FF3:
> www.daisuki.com.br ... the cause is the neat slider with ajax keeps moving divs
> inside the table cell

That site looks fine to me in FF3.  The slider seems to work correctly -- I click the arrows and the contents slide over nicely.

The slider areas do get a bit messed up when I resize the window, but it's fixed when it reloads -- I take it that's what you're talking about?

> expanding it all the same as if it were an old non compliant browser.
> ...
> We start choosing the easier way out, we loose everything Mozilla/Firefox
> always fought for: the BEST compliance with standards with the BEST end result.

As has been said many times above -- despite your comments here and on your news & forums at the 'daisuki' webpage, this bug is NOT an issue of standards compliance.  The FF3 behavior here is perfectly compliant.  See comment 17 (and others) where this has already been discussed.  If you disagree, please quote specifically what part of the spec you think we're non-compliant with, rather than just throwing out accusations.

(also -- I'm removing the "css2" keyword, which Lucas added this morning without any explanation. Lucas, I thought we'd agreed above that this doesn't violate css2 -- if you think it does, please give some justification.)

> DO you seriously believe making designers looking for DHTML/Ajax (tendency) on
> liquid layouts (tendency) to have to come with the lame solution of a timeout
> to recalculate the DIV if the window changes width while, if you could just
> make contents in a DIV respect overflow:hidden, as a developer would expect,
> all problems would be solved?

You don't seem to understand the issue here.  FF3 *does* make divs respect 'overflow:hidden' -- the issue is that, if you don't specify a width on the div, then it expands to accomodate its contents, even if it's inside of a table, because tables are naturally accomodating like that. (See comment 11 and 15 for more on this)
Keywords: css2

    
    

    
  
(In reply to comment #24)
> I'm removing the "css2" keyword, which Lucas added this morning without any 
> explanation. Lucas, I thought we'd agreed above that this doesn't violate css2

Yes, sorry, I added it only because the problem is related to css, but the keyword indicate really a bug.

    
    

    
  
(In reply to comment #24)
> (In reply to comment #21)
> > This site renders perfectly fine with FF2 and IE7, but not with FF3:
> > www.daisuki.com.br ... the cause is the neat slider with ajax keeps moving divs
> > inside the table cell
> 
> That site looks fine to me in FF3.  The slider seems to work correctly -- I
> click the arrows and the contents slide over nicely.
> 
> The slider areas do get a bit messed up when I resize the window, but it's
> fixed when it reloads -- I take it that's what you're talking about?

Actually, I see pretty much the exact same behavior (page messes up when I resize it horizontally) in both IE7 and in Safari.  So, I don't know what aspect you're talking about that "renders perfectly fine with FF2 and IE7" but is broken in FF3.

    
    

    
  
>Actually, I see pretty much the exact same behavior (page messes up when I
>resize it horizontally) in both IE7 and in Safari.  So, I don't know what
>aspect you're talking about that "renders perfectly fine with FF2 and IE7" but
>is broken in FF3.

The page renders perfectly on my IE7, it only messes the layout when you resize, indeed that's even more weird since IE7 "partially" respects the overflow:hidden as it does not "explode" the layout as in FF3, IE6 and Safari, not expanding the cell and clipping the contents, but after that it behaves as if the DIV had fixed width. I never noticed that actually.

Either way, I don't care, seams designers that aim for liquid design are on for more trouble in the future. 

P.S. The script on the site was changed so it works on all browsers, the **only** browser the script does not have to adjust the width is FF2, I liked that, since that's my knowledge of overflow:hidden - you say it's a table problem, ok ... semantics. I made some test runs and the site can look the same w/o tables and than w/o the script, but sometimes you need a table =/


    
    

    
  
Yes, the page is messed if you allow javascript. If you block javascript on Fx3 the page is displayed well, so take a look to your scripts.

    
    

    
  
I don't like your tone, let's keep things civil. It's already settled it IS an issue of table and overflow, not "my script".

FYI the page is not messed w/o javascript because the thumbnails are just thrown inside the div WITHOUT WIDTH, so it grows in HEIGHT (which IS SET so the overflow works on HEIGHT). If you take your little time to take a peak at the source, you will figure there are way more thumbnails than the ones being shown (if javascript is off), but the height overflow works and does not show they are being thrown down (not right).

The javascript "messes" the layout because to create the slider effect, it forces the inner DIV a new WIDTH and HEIGHT (to fit the thumbnail count HORIZONTALY), and thus increases the width of the inner div forcing all thumbnails to get in line, exploding the cell. Just like my testcase on bug 441014. and than it puts another DIV the same size (already bigger) to the right of the first DIV to load new thumbnails dinamically with AJAX as the slider goes on as the slider moves. The code works PERFECTLY on ALL (let me tell this again, ALL) known browsers, and it even fixes said overflow issues on FF3, IE and Safari (Opera behaves as FF2) with the setTimeout to put the width back to the correct width it you redimensions the client window. No, there is nothing wrong with the javascript. Stop nagging about it and read the 27 posts above and realize that YES, FF3 (and other browsers, which I don't care) have problems with overflow in a table.

The whole point is not if the bug exists or not, but if one should let it remain because it's not explicit in the standards for css and FF2 behaved one way while FF3 in other way.

FF2: obeys overflow hidden, redimensions it as the client changes (expected)
FF3: does not obey overflow hidden at load time nor dinamically
IE6: never oveys overflow hidden as FF3
IE7: oveys overflow hidden at loat time, but does not redimensions as client changes (better, but not expected)
Safari: same as FF3/IE6
Opera: same as FF2

Again, IMHO overflow HIDDEN means OVERFLOW HIDDEN, couldn't care less if it's inside a cell. This is a BUG regardless if it's explicit or not on the standards. Choosing to IGNORE a css property just because it's not mandatory on the standards does not sound right to me. Props up to Opera.


    
    

    
  
(In reply to comment #29)
> FF3: does not obey overflow hidden at load time nor dinamically
> ...
> IE7: oveys overflow hidden at loat time

I'm not aware of this difference between FF3 and IE7.

If you believe this to be the case, could you provide a simple testcase that demonstrates the difference?

    
    

    
  


  
2 samples of the same bug.

The first is the usual. The script increases a child DIV inside a parent DIV with overflow:hidden, all inside a table. When you run the script to increase the child DIV, the table/parent ignores overflow:hidden

The second is a sample on why www.daisuki.com.br with javascript off does not mess the layout. Initially it has a overflow:hidden WITH HEIGHT DEFINED so all the content that is extra is thrown downwards, hidden. When the script runs to fix the size of the child DIV to force them in a line, the parent DIV/Table ignore the overflow:hidden and explodes the layout

    
    

    
  
>I'm not aware of this difference between FF3 and IE7.

I was wrong, sorry. I forgot the "hack" script for IE7 on while testing and it seamed to work, my mistake. This FF3 and IE7 are currently on the same issue.

    
    

    
  
(In reply to comment #32)
> >I'm not aware of this difference between FF3 and IE7.
> 
> I was wrong, sorry. I forgot the "hack" script for IE7 on while testing and it
> seamed to work, my mistake. This FF3 and IE7 are currently on the same issue.

WebKit (Safari) also behaves the same as Gecko. 



    
    

    
  
(In reply to comment #29)
> [cut...]

... I invite you to read the entire report, because I posted before, I created some testcases and I also suggested a compromise with old and new Firefox behaviour. 

What I'm suggesting to you is to create a temporary workaround, and to see in your scripts, because if you disable javascript and load your site, you can see that Firefox 3 displays it well.

    
    

    
  
WONTFIX-ing this, per comment 3, comment 6, and comment 17.

At this point any "fix" for this issue would come as a workaround by giving web authors a way to choose which behavior they want, which is bug 433621. (already mentioned above in comment 23)
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
Depends on: 426629

    
    

    
  
Why is this bug in the "won't fix" status?  The latest version of Chrome properly handles a div child within a td taking 100% height with overflow set to auto working as expected.  In Firefox, the div and the td just grow without ever presenting a vertical scroll bar.  

See the fiddle here in both browsers to see the difference:  

https://jsfiddle.net/euzjvz1g/2/

After 7 years, this is still a major problem in Firefox!

    
    

    
  
Here's a better example which shows why this needs to be fixed:

https://jsfiddle.net/euzjvz1g/4/

The height overflow of the div shouldn't be affecting the height of the entire HTML document.

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: