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

Le Jeu 9 août 2012 14:15, Robert Hogan a écrit :
> 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
> -

Well, having everything appropriately declared, perfectly calculated and
coded is important.



> the point is the boxes are not a radically different size from each
> other.

Okay.

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


Yes, they are both 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."
>

Correct.

> 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

Yes.

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

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

Yes. Correct.


>
> 4.

http://roberthogan.net/css/height-percentage-replaced-004.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'."

Yes.


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

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

Yes. So, any size would be acceptable: 20px, 53px, 86px, any width.

>
> 6.

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

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

Both squares should be 20px by 20px.

>
> 7.

 http://roberthogan.net/css/max-height-percentage-replaced-003.htm


>
> Only WebKit fails this one

Yes.

> - 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')."

Correct.

Both squares should be 96px by 96px.

> 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


> Unlike the others this is just a simple test of max-height inside a div.
> Passes on all 4.

Both squares should be 96px by 96px.

>
> 9.

 http://roberthogan.net/css/max-height-percentage-replaced-005.htm

The black square should be 2000px by 2000px.

> 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


html, body, table, tbody, td {
                width: 100%;
                height: 100%;
                padding: 0;
                margin: 0;
                vertical-align: top;
            }


table-row-groups can not be set a height; that's given by the spec or

http://wiki.csswg.org/spec/css2.1#issue-133

and table-row-groups can not be set to a width

10.2 Content width: the 'width' property

'width'
    Applies to:  	all elements but non-replaced inline elements, table
rows, and row groups

http://www.w3.org/TR/CSS21/visudet.html#the-width-property

So, we have again a situation where any size is possible, permissible.

>
> Only WebKit fails this one.

There is no unique possible rendered layout for this test. This test
would be rejected if it was submitted for CSS 2.1

> 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


Important default values (for making tests and reducing number of
declarations)
------------------------

border-spacing is by default 2px 2px in all browsers, that is when
'border-collapse: separate' is declared or is being applied or when
'border-collapse: collapse' is not declared on a <table> element.

Default <td> padding in all browsers is 1px (each 4 sides); <td> has 0px
default border (or no border) and margin does not apply to it.

<body> has a default 8px margin (4 sides) in all browsers (except
Konqueror 4+ which uses a 10px margin) ; <body> has no padding (a
default zero padding) (except Opera 6); <body> has no border.

<html> element has a zero default margin (or no margin if you wish), no
border (except IE6 and IIRC IE7), no padding.

<table> element has a 0px default margin (or no margin if you wish), 0px
 default border (or no border if you wish), 0px default padding (or no
padding if you wish); it uses by default border-collapse: separate and
border-spacing is 2px 2px by default.

Most browsers now display the CSS rules of their user agent stylesheet
in their webpage debugging tools: Chrome's web inspector, Opera's
DragonFly, Firefox's DOM inspector do that, display those default
values.

Gérard

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


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

Received on Thursday, 9 August 2012 22:15:57 UTC