W3C home > Mailing lists > Public > www-style@w3.org > November 2012

Re: [css21][css3-box] when only one dimension is specified, replaced element sizing rules are ambiguous and non-interoperable

From: Gérard Talbot <www-style@gtalbot.org>
Date: Mon, 5 Nov 2012 14:13:39 -0500
Message-ID: <d5b45a5d93ce3d9e173fe942a75e0c7b.squirrel@ed-sh-cp3.entirelydigital.com>
To: "Kang-Hao (Kenny) Lu" <kanghaol@oupeng.com>
Cc: "WWW Style mailing list" <www-style@w3.org>

Le Lun 5 novembre 2012 5:25, Kang-Hao (Kenny) Lu a écrit :
> While investigating under what conditions would a 'min-height' induces a
> 'min-width' for replaced elements[1], I was shocked by a simple but yet
> non-interoperable case:
>
>   data:text/html,<!DOCTYPE html><img style="max-height: 2em; height:
> 5em;" src="http://www.w3.org/2012/10/TPAC/img/tpac-logo2012.png">
>

tpac-logo2012.png has an intrinsic width of 105px, an intrinsic height of
146px and an intrinsic ratio of 1.39:1


> While IE9 and Firefox16 give a rescaled image to 'height: 2em', WebKit
> and preserves the width of the image when it's 'height: 5em'. Opera
> preserves the intrinsic width.

Just like Øyvind wrote you, I do not get your result. Opera 12.02 displays
an 23px tall image.

32px (== 2em) divided by 1.39 (intrinsic ratio) == 23.021px

which is what we were expected to get.


> Interesting enough, IE9, Firefox16 and
> WebKit give the same answer if "max-height" were "max-width" and
> "height" were "width".

To be sure we all follow and understand what you're saying, it would be
best to provide complete tests supporting your statement.


> You can play with the algorithm with my demo[2].
>
> Looking into CSS 2.1, I think the root of the problem is that the spec
> doesn't clearly says what's the correct execution order of the following
>
>   10.3.2 Inline, replaced elements (width)
>   10.4 Minimum and maximum widths: 'min-width' and 'max-width'
>   10.6.1 Inline, non-replaced elements (height)
>   10.7 Minimum and maximum heights: 'min-height' and 'max-height'
>
> for a replaced element. So, while WebKit always follows the above order,
> which is also the requried order for the calculation of a non-replaced
> element. IE9 and Firefox 16 sometimes do
>
>   10.6.1 Inline, non-replaced elements (height)
>   10.7 Minimum and maximum heights: 'min-height' and 'max-height'
>   10.3.2 Inline, replaced elements (width)
>   10.4 Minimum and maximum widths: 'min-width' and 'max-width'
>
> , like the example above.

The sequence of execution order to follow with regards to 'min-height',
'min-width', 'max-width' and 'max-height' is a bit complex. The decisive
word to understand is 'tentative'. If english is not your mother tongue,
then this maybe difficult to understand: at least, this was my case as I
originally did not understand what tentative really meant.

>
> I'd claim that IE9 and Firefox's behavior is more desirable because
>
> 1. Preserving aspect ratio in more cases is usulaly a good thing.
> 2. WebKit's behavior is writing mode-dependent (set the root to
> '-webkit-writing-mode: vertical-rl' and you'll see) and I am not sure if
> css-writing-modes-1 actually asks for this behavior. It's a bit weird
> anyway because the image doesn't get rotated when the writing mode
> changes and the layout of a replaced element really shouldn't depend on
> the writing mode.
>
> I'd suggest we change this part of CSS 2.1:
>
>   # However, for replaced elements with an intrinsic ratio and both
>   # 'width' and 'height' specified as 'auto', the algorithm is as
>   # follows:
>   #
>   # Select from the table the resolved height and width values for the
>   # appropriate constraint violation. Take the max-width and max-height
>   # as max(min, max) so that min ≤ max holds true...
>
> to
>
>   | However, for replaced elements with an intrinsic ratio and both
>   | 'width' and 'height' specified as 'auto', the algorithm is as
>   | follows. For replaced elements with an intrinsic ratio, a specified
>   | 'width' induces a 'min-width' with the following formula:
>   |
>   |    induced 'min-width' = min ( effective 'max-width', max (
>   |                    specified 'width', specified 'min-width' ) )
>   |
>   | where
>   |
>   |    effective 'max-width' = max ( specified 'min-width',
>   |                                  specified 'max-width' )
>   |
>   | and similarly 'width' induces a 'max-width' and 'height' induces a
>   | 'min-height' and 'max-height'. Then the max-width, max-height,
>   | min-width and min-height below as the induced ones and apply the
>   | following algorithm.


I do not like the recourse to the verb "induce"; it should be "constrain".


> This wording is certainly not optimal and perhaps there would be a
> better explanation of IE9 and Firefox's behavior that doesn't reply on a
> notion of "induced" constraints. But I do think the table, which more of
> less means "preverse aspect ratio as possible", is the core of the
> algorithm and I suggest css3-box fold these fragmented sections into a
> single one around this table so that there isn't this ambiguos order
> problem.
>
>
> [1] http://lists.w3.org/Archives/Public/www-style/2012Nov/0010
> [2]
> http://lists.w3.org/Archives/Public/www-archive/2012Nov/att-0010/replaced-element-dimension-calulation
> , but if you are using IE9 you need
> http://lists.w3.org/Archives/Public/www-archive/2012Nov/att-0011/replaced-element-dimension-calulation-img-version
> because IE9 layout <canvas> differently from a <img> (why?). Have fun
> with the demo!


There is definitely a need for CSS2.1 and all CSS3 modules to be worded as
clearly as possible. This does

Your post helped me notice that we need more tests on 'min-height',
'min-width', 'max-width' and 'max-height' on inline replaced elements with
intrinsic ratio in the CSS 2.1 test suite.

The only tests I found so far are

http://test.csswg.org/suites/css2.1/nightly-unstable/html4/max-width-109.htm

http://test.csswg.org/suites/css2.1/nightly-unstable/html4/replaced-min-max-001.htm

and these seem insufficient in terms of coverage.

Gérard
-- 
CSS 2.1 Test suite RC6, March 23rd 2011
http://test.csswg.org/suites/css2.1/20110323/html4/toc.html

Contributions to CSS 2.1 test suite
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/

Web authors' contributions to CSS 2.1 test suite
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/web-authors-contributions-css21-testsuite.html
Received on Monday, 5 November 2012 19:14:14 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:02 GMT