User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; WOW64; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.2) Build Identifier: All mozilla versions including the one used by Minefield Let's have a look at the following example in strict mode: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html> <body> <table style="border: 1px solid blue" border="1px"> <tr> <td> 1 </td> <td> <div style="width: 40px;"> 2 </div> </td> </tr> <tr> <td> <div style="height: 40px;"> 3 </div> </td> <td style="height: 20px; width: 20px"> <div style="height:100%; width: 100%; border:1px solid red;"> 4 </div> </td> </tr> </table> </body> </html> So there is table with four cells. Cell "4" which defines a width and a height of "20px". Table cell "2" expands the defined width of cell 4 by its pushing content. Table cell "3" expands the height of cell 4 by its pushing content. Table cell "4" contains a DIV HTML tag (red border) which has 100% height and width set. As we can see all common browsers behave differently. WebKit adjust the DIV's dimensions to the actual painted borders of the table cell. IE seems to adjust the DIV's dimensions to an internal calculated box with 20px in a square. Mozilla behaves like WebKit in the width dimension and behaves like IE in the height dimension. The question is if the correct behavior is in the W3C specification specified and if "yes" which is the right behavior? Is it a) the internal calculated box related to the given height and width property or b) the actual rendered/painted dimensions of the table cell? In the W3C specification is specified that "The percentage is calculated with respect to the width of the generated box's containing block...". ... "The containing block of other boxes is the rectangle formed by the content edge of their nearest ancestor box that is block-level." ... "The content edge surrounds the rectangle given by the width and height of the box, which often depend on the element's rendered content. The four content edges define the box's content box." http://www.w3.org/TR/css3-box/#introduction and http://www.w3.org/TR/CSS2/box.html#box-dimensions shows the meaning of the content edge. In the box/edge graphic we see that the content edge is adjusted to the padding edge which is again adjusted to the border edge. The border edge of a table cell "4" in the given example above is clearly drawn. As a conclusion we see that 1) The behavior is specified and can be derived from the W3C specification 2) WebKit has implemented the W3C specification correctly (width and height) 3) IE did not implemented the W3C specification correctly (width and height) (we already opened a bug report) 4) Mozilla only implemented the width aspect according to the W3C specification. The height algorithm is implemented incorrectly. Reproducible: Always Steps to Reproduce: 1.Load the given HTML (see Details) 2.The problem can be seen immediatelly Actual Results: The height of the embedded DIV is not adjusted to the table cells boundaries Expected Results: The height of the embedded DIV should be adjusted to the table cells boundaries
Some important quotes from the spec that you missed, which I believe make your analysis incorrect: http://www.w3.org/TR/CSS21/visudet.html#the-height-property says: <percentage> Specifies a percentage height. The percentage is calculated with respect to the height of the generated box's containing block. If the height of the containing block is not specified explicitly (i.e., it depends on content height), and this element is not absolutely positioned, the value computes to 'auto'. http://www.w3.org/TR/CSS21/tables.html#height-layout says (in addition to partially defining a different algorithm for tables): CSS 2.1 does not define how the height of table cells and table rows is calculated when their height is specified using percentage values. CSS 2.1 does not define the meaning of 'height' on row groups. So I think the correct behavior here is clearly undefined by the spec. That said, I agree our table height computation code could use improvement, though there are a bunch of cases where *all* browsers share the same bug and therefore it's hard to improve without breaking compatibility. I'd actually like to make our table height calculation code more like IE6's.
I'll mark this as depending on bug 359481 so that if we do redesign our percentage height code, I'll see this testcase.
Depends on: 359481
(In reply to comment #3) > Some important quotes from the spec that you missed, which I believe make your > analysis incorrect: > http://www.w3.org/TR/CSS21/visudet.html#the-height-property says: > <percentage> > Specifies a percentage height. The percentage is calculated with respect to > the height of the generated box's containing block. If the height of the > containing block is not specified explicitly (i.e., it depends on content > height), and this element is not absolutely positioned, the value computes to > 'auto'. > http://www.w3.org/TR/CSS21/tables.html#height-layout says (in addition to > partially defining a different algorithm for tables): > CSS 2.1 does not define how the height of table cells and table rows is > calculated when their height is specified using percentage values. CSS 2.1 does > not define the meaning of 'height' on row groups. > So I think the correct behavior here is clearly undefined by the spec. That > said, I agree our table height computation code could use improvement, though > there are a bunch of cases where *all* browsers share the same bug and > therefore it's hard to improve without breaking compatibility. I'd actually > like to make our table height calculation code more like IE6's. I know these statements in the specification. Another browser vendor cite the same sentences already. The common sentence in "visudet" you cited is meant for block elements with NO height dimension settings so that the content defines the rendered height of the block element. But in the example a none percentage height is defined (="20px") but influenced by its sibling, not its content. The table is special from this point of view compared to a block element which dimensions cannot be influenced by its content when the dimensions are specified, right? The cited sentence can also be found a bit modified in the percentage section of the width property. http://www.w3.org/TR/CSS21/visudet.html#the-width-property "If the containing block's width depends on this element's width, then the resulting layout is undefined in CSS 2.1." So from this argumentation also the percentage width in a containing block of a table cell is also not defined. Right? So if Mozilla wants to be compatible to e.g. IE in Strict mode also the width behavior needs to be adapted to IE. IE has the same strange behavior in the width dimension (see attached PDF). Mozilla has not. WebKit behaves as expected ... in each dimension. As far as I can see from the context the sentence you cited from the W3C "tables.html#height-layout" document is meant for the distribution of available space to rows/cells which specify a percentage height. So I still think that the spec clearly defines the behavior. In summery of all the discussions I had with the different browser vendors regarding this issue I have got the impression that every involved person knows how the W3C specification has to be interpreted and what the correct behavior should be. But there is the "performance" aspect which has to be considered as well. Especially when every rendering engine is ranked in arbitrary performance benchmark publications which do not reflect the "quality" of rendering. On the other hand it is quite hard to create web applications which making sense with such a table cell behavior. I cannot see in which scenario the current behavior would make sense. Unfortunately for us this even would mean that HTML applications which currently run in Quirks mode cannot be migrated to Strict mode. In Mozilla at least we sometimes have the possibility to use a workaround (see attached workaround HTML). From the algorithm side I can imagine what suddenly happens ... but from web developer perspective it is really strange. I'm looking forward to the new height algorithm you are going to implement and hope that "performance" or "compatibility to *all* other browsers" is not TOO much taken into consideration :-) Many thanks for answering that fast.
The "Bug description" PDF attachment shows the behavior of IE7, Gecko (20100914) and WebKit. I checked some additional browsers and browser versions (see attached GIF "Behavior of the different browsers") Microsoft changed the behavior from IE7 to IE8. IE8, Gecko and Opera currently behave the same. So now I understand the "compatibility" statement of David much more. Anyway I hope the WebKit behavior becomes "standard".
You need to log in before you can comment on or make changes to this bug.