- From: Gérard Talbot <www-style@gtalbot.org>
- Date: Mon, 5 Nov 2012 14:13:39 -0500
- 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 UTC