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

(12/11/05 23:43), Øyvind Stenhaug wrote:
> On Mon, 05 Nov 2012 11:25:37 +0100, Kang-Hao (Kenny) Lu
> <kanghaol@oupeng.com> wrote:
>>
>>   data:text/html,<!DOCTYPE html><img style="max-height: 2em; height:
>> 5em;" src="http://www.w3.org/2012/10/TPAC/img/tpac-logo2012.png">
>>
> 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.

You are totally right! I was told that IE doesn't make stretchy images
in this case so I figured the <canvas> problem, but I didn't think of
the possibility that Opera might have the same problem and so I didn't
try the version of my demo (<img> + remote image) that works on IE9.
What a shame.

I also updated a new version[1] based on <img> + data:image/svg+xml .
Hopefully this is more interoperable while not relying on network.

As for what this demo is, I figured that the calculation of the size of
a replaced element under min/max constraint would be easier to explain
with a graph instead of a table. In essence, the size of a replaced
element with neither 'width' or 'height' specified can be described by
the result of the following process:

  You draw a rectangle representing (called constraint rect) all
  possible values under min/max constraint. You draw a ray from the
  origin towards the point (called the intrinsic point, say)
  representing the intrinsic size of the image. Then the resulting size
  of the image the closest point to the intrinsic point among all the
  points the intrinsic ray and the constraint rect (filled) intersect.

This is, I believe, easier than that CSS 2.1 table with 12 rows. (By the
way, all the circles in the demo are draggable)

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

Oops, you are right again.

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

My proposed change was to insert "For replaced elements with an
intrinsic ratio, a specified 'width' induces a 'min-width' with the
following formula..." after the first paragraph. But yes, I guess it is
confusing and the first paragraph can just be replaced.

The idea is to reused the table in the bottom of that section as much as
possible with the notion of "induced min/max constraints".

> Do you have an example of undesirable behavior when width=height=auto?

No. width=height=auto is totally interoperable as far as I can tell.

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

I'd note that even we think that the latter is "more correct", it it
still somewhat incorrect because we know the equation

  (used width) = (used height) * (intrinsic ratio)

is sometimes unsatisfiable under certain min/max constraints.

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

We can do that. But for the reason above, I believe the correct approach
is to remove 10.3/10.6 all together and move everything under 10.4.

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

Without explicit wording, I can't assess what sort of resulting prose
this would give.

My approach would instead be, as mentioned above, to remove
10.3/10.6/10.7 and make 10.4 into three steps:

1. Find the aspect ratio.
2. Drive "induced min/max height/width" from "min/max-height",
"min/max-width", "height" and "width". In particular, if 'height: x' is
satisfiable (meaning that 'min-height' < x < 'max-height'), it induces
'min-height: x' and 'max-height: x'. Otherwise, it induces 'min-height:
specified max-height' or 'max-height: specified min-height'.
3. Apply the table.

The good thing about this is that scaling only happens once at Step 3 so
it doesn't require the notion of "iterations". I think this works for
all replaced elements with an intrinsic ratio but I have to think more
about other cases.

Having said that, I don't know how browsers handle this case so this is
really just a conceptual device.

But in any case, I suppose this would only happen at css-box-3.

[1]
http://lists.w3.org/Archives/Public/www-archive/2012Nov/att-0014/replaced-element-dimension-calulation-img-version


Cheers,
Kenny
-- 
Web Specialist, Oupeng Browser, Beijing
Try Oupeng: http://www.oupeng.com/

Received on Monday, 5 November 2012 19:07:07 UTC