W3C home > Mailing lists > Public > www-style@w3.org > September 2010

Re: [CSS 2.1] [Section 10.3.x] Testcases where percentage intrinsic width cannot be resolved

From: Anton Prowse <prowse@moonhenge.net>
Date: Sat, 25 Sep 2010 10:19:57 +0200
Message-ID: <4C9DB0AD.8070901@moonhenge.net>
To: "www-style@w3.org list" <www-style@w3.org>
CC: Boris Zbarsky <bzbarsky@MIT.EDU>
On 25/09/2010 07:06, Boris Zbarsky wrote:
> On 9/24/10 2:38 PM, Anton Prowse wrote:
>> I think Gérard's point was precisely that the blue square /is/ half its
>> intrinsic width (48px instead of 96px) in several browsers.
> Yep. And it's 24px wide in the remaining ones.

Indeed. (Which happens to be 1/4 of its intrinsic width.)
>> Whilst the width of the square is undefined in full generality, CSS21
>> 10.2 (in
>> agreement with HTML4) makes it clear that the /intent/ is that the width
>> not depend on the intrinsic width
> Er... how so?

Because in the cases where the layout is defined, that's what's required:

HTML4: "Note that lengths expressed as percentages are based on the 
horizontal or vertical space currently available, not on the natural 
size of the image, object, or applet."

CSS21: "The percentage is calculated with respect to the width of the 
generated box's containing block."  (No mention of intrinsic width.)

>> it's not unreasonable to expect UAs
>> to avoid to shrinking the blue square to half its intrinsic width in
>> these fairly simple test cases which don't involve unsolvable
>> constraints.
> Every single UA (quite reasonably) makes the blue square half the width
> of the shrink-wrapping container.

Of course.

> The only question is whether the width
> of the shrink-wrapping container is 96px or 48px. The browsers that make
> it 96px use the intrinsic width of the image to make that determination.

The intrinsic width of the image is 96px, so there's a pretty good 
argument for keeping the image at its intrinsic width of 96px and then 
making the container 192px wide.  (Of course, this behaviour is 
undefined for good reason, and it's not always possible to make such 
simplistic judgements.)

UAs which make the image 48px wide and the container 96px wide seem to 
be applying the 50% in two different ways simultaneously: once for the 
width of the image and then again for the width of the container.

> The remaining ones apparently treat the image as having a width of 0 for
> shrink-wrapping purposes, so end up making the container the width of
> the orange div.

Yep, which is where the 24px-wide image comes from.  There's logic 
behind this approach too.  It's the rendering in the other UAs that I 
find a little harder to justify.  (Still, I'm not arguing in favour 
anything here; the behaviour is intentionally undefined and doesn't need 

Anton Prowse
Received on Saturday, 25 September 2010 08:20:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:49:48 UTC