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



and these seem insufficient in terms of coverage.

CSS 2.1 Test suite RC6, March 23rd 2011

Contributions to CSS 2.1 test suite

Web authors' contributions to CSS 2.1 test suite
Received on Monday, 5 November 2012 19:14:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:23 UTC