Re: Percentage Height of a Replaced Element in a Table Cell

Hi Boris and Gerard,

Thanks for your feedback. Here are some tests which walk through each
behaviour discussed (plus some new items related to height and max-height
in cells). The margins are a bit off on some of these tests at the time of
writing so they may not be exactly the same size when you check the test -
the point is the boxes are not a radically different size from each other.

I think I understand the behaviour under (10) below but wouldn't mind any
comments you have on it.

1. http://roberthogan.net/css/height-percentage-replaced-001.htm

IE and Opera render the png here as 20x20, while FF and WebKit render it
with its intrinsic dimensions. Either are permissible because "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."

2. http://roberthogan.net/css/height-percentage-replaced-002.htm

FF,Opera,Chrome and IE render this one correctly. The image should be
rendered with its intrinsic dimensions because "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'." The vexed question of which block is the cell's containing
block doesn't arise here as none of the possible candidates have an
explicit height.

3. http://roberthogan.net/css/height-percentage-replaced-003.htm<http://roberthogan.net/css/height-percentage-replaced-002.htm>

This one is rendered the same by all 4 of FF,Opera,Chrome and IE - it just
tests that the image sizes to 100% of the cell height when the cell height
is specified.

4. http://roberthogan.net/css/height-percentage-replaced-004.htm<http://roberthogan.net/css/height-percentage-replaced-002.htm>

Only WebKit fails this one - it mistakenly percent-sizes the image even
though the containing block (i.e. the cell) does not have a specific
height. This violates the spec: "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'." I plan
to fix this in https://bugs.webkit.org/show_bug.cgi?id=43319

5. http://roberthogan.net/css/max-height-percentage-replaced-001.htm<http://roberthogan.net/css/height-percentage-replaced-002.htm>

The same as (1) above but for max-height.

6. http://roberthogan.net/css/max-height-percentage-replaced-002.htm<http://roberthogan.net/css/height-percentage-replaced-002.htm>

The same as (2) above but for max-height.

7. http://roberthogan.net/css/max-height-percentage-replaced-003.htm<http://roberthogan.net/css/height-percentage-replaced-002.htm>

Only WebKit fails this one - for the same reason that it fails (4) above: "
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 percentage value is treated as '0' (for 'min-height') or 'none' (for
'max-height')." Again, plan to fix this in
https://bugs.webkit.org/show_bug.cgi?id=43319

8. http://roberthogan.net/css/max-height-percentage-replaced-004.htm<http://roberthogan.net/css/height-percentage-replaced-002.htm>
Unlike the others this is just a simple test of max-height inside a div.
Passes on all 4.

9. http://roberthogan.net/css/max-height-percentage-replaced-005.htm<http://roberthogan.net/css/height-percentage-replaced-002.htm>

All 4 render this one correctly. In a way it's the same (6) above but it
involves overflowing the initial containing block.

10. http://roberthogan.net/css/max-height-percentage-replaced-006.htm<http://roberthogan.net/css/height-percentage-replaced-002.htm>

Only WebKit fails this one. As I understand it the rule applied here is
that "A percentage height on the root element is relative to the initial
containing block." - so giving a 100% height to the html element means that
the image with a max-height of 100% in the table cell ends up constrained
to it - i.e. it can't overflow out of the root element and the root element
is constrained to the viewport. Again I hope to fix this in WebKit bug
43319.

If you have any comments on the above tests apart from the size of the
boxes being slightly off by a few pixels in the first few tests (which I
intend to fix) please let me know!

Thanks,
Robert










On Tue, Aug 7, 2012 at 11:33 PM, "Gérard Talbot" <css21testsuite@gtalbot.org
> wrote:

>
> Le Mar 7 août 2012 17:57, Robert Hogan a écrit :
> > My snippets were incorrect. :(
> >
> > So let me try that again:
> >
> > Browsers disagree on how to render this snippet:
> >
> >         <table style="width:20px;height:20px">
> >             <tr>
> >
> > <td style="width:100%;height:100%"><img style="height:100%"
> > src="50x50.png"></td>
> >             </tr>
> >         </table>
>
> The same logic given, explained before will apply.
>
> "
> 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.
> "
> 17.5.3 Table height algorithms
> http://www.w3.org/TR/CSS21/tables.html#height-layout
>
> So, the used height fo the table-cell could be any value (20px or 50px
> or 123px); it is undefined.
>
>
> >
> > WebKit, FF: the image is rendered as 50x50
> > IE, Opera: the image is rendered as 20x20
> >
> > I believe IE and Opera are correct here: "The percentage is calculated
> > with
> > respect to the height of the generated box's containing block." Going up
> > the chain this is 20px.
> >
> > This is distinct from the following case, where rendering 50x50 would be
> > the right thing to do:
> >
> >         <table>
> >             <tr>
> >                 <td><img style="height:100%" src="50x50.png"></td>
> >             </tr>
> >         </table>
> >
> > "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'."
>
> Yes, this is the right thing to do: img's containing block is the
> table-cell which uses 'height: auto', so the img intrinsic height and
> width will be used.
>
> >
> > Am I right in thinking this?
> >
> > Thanks,
> > Robert
>
>
> (More on what I wrote in my previous email)
>
> Regarding 'overflow: visible' and table-cell element and table element:
>
> Overflow and table-cell (non-replaced inline element):
>
> [nightly-unstable]
>
> http://test.csswg.org/suites/css2.1/nightly-unstable/html4/fixed-table-layout-009.htm
>
>
> [RC6]
>
> http://test.csswg.org/suites/css2.1/20110323/html4/fixed-table-layout-009.htm
>
> Proposed improvement:
>
> http://www.gtalbot.org/BrowserBugsSection/css21testsuite/fixed-table-layout-009.html
>
> http://test.csswg.org/shepherd/testcase/fixed-table-layout-009/
>
> ----------
>
> [RC6]
>
> http://test.csswg.org/suites/css2.1/20110323/html4/overflow-applies-to-007.htm
>
> [RC6]
>
> http://test.csswg.org/suites/css2.1/20110323/html4/overflow-applies-to-013.htm
>
> http://test.csswg.org/shepherd/testcase/overflow-applies-to-013/
>
>
> Gérard
> --
> Contributions to the CSS 2.1 test suite:
> http://www.gtalbot.org/BrowserBugsSection/css21testsuite/
>
> CSS 2.1 Test suite RC6, March 23rd 2011:
> http://test.csswg.org/suites/css2.1/20110323/html4/toc.html
>
> CSS 2.1 test suite harness:
> http://test.csswg.org/harness/
>
> Contributing to to CSS 2.1 test suite:
>
> http://www.gtalbot.org/BrowserBugsSection/css21testsuite/web-authors-contributions-css21-testsuite.html
>
>