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

On Mon, 05 Nov 2012 11:25:37 +0100, Kang-Hao (Kenny) Lu  
<kanghaol@oupeng.com> wrote:

> 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">
>
> 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. Interesting enough, IE9, Firefox16 and
> WebKit give the same answer if "max-height" were "max-width" and
> "height" were "width". You can play with the algorithm with my demo[2].

I don't see any difference between IE9, Firefox 16 and Opera 12 in that  
simple case. They all result in a width of 23px.

The demo just confused me at first glance, so I haven't really tried that.  
But it looks like Opera has the same issue for canvas that you noted for  
IE, so maybe that could explain your observations. At a guess, Firefox  
lets the width and height attributes of the canvas element determine the  
intrinsic width/height (as specified in the current HTML5 draft), whereas  
IE9 and Opera might be treating them as presentational hints (similarly to  
width/height for <img>).

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

Presumably you mean "10.6.2 Inline replaced elements, block-level replaced  
elements in normal flow, 'inline-block' replaced elements in normal flow  
and floating replaced elements" here instead of 10.6.1.

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

I don't see how this would help for your initial simple case (the data:  
URI), since specified height is non-auto there. Do you have an example of  
undesirable behavior when width=height=auto?

For the max-height case, I think the core of the problem is that 10.3 and  
10.6 keep talking about rules to determine the "used value", and then  
10.4/10.7 come along and say that oh, actually, those were only  
*tentative* used values, you need to apply these additional rules and  
possibly run through the steps again, and only then will you have the used  
values for real.

Specifically, the "used value of 'width'" in this data: case is "(used  
height) * (intrinsic ratio)".

So the question is whether the "used height" in that formula is supposed  
to be the tentative "used height" or the final used height. WebKit seems  
to do the former, the others the latter.

Probably the 10.3/10.6 sections shouldn't say that they specify how to get  
"used values", only "tentative used values". But the formulas like "(used  
width) / (intrinsic ratio)" should still be left as-is. And then 10.4/10.7  
should convert from "tentative used" to "used" also for the case where  
min/max is not violated after the initial iteration.

-- 
Øyvind Stenhaug
Core Norway, Opera Software ASA

Received on Monday, 5 November 2012 15:44:00 UTC