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

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

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.

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.

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!


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

Received on Monday, 5 November 2012 10:26:16 UTC