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:32:42 +0200
Message-ID: <4C9DB3AA.8080009@moonhenge.net>
To: "www-style@w3.org list" <www-style@w3.org>
CC: Boris Zbarsky <bzbarsky@MIT.EDU>
On 25/09/2010 10:19, Anton Prowse wrote:
> On 25/09/2010 07:06, Boris Zbarsky wrote:
>> On 9/24/10 2:38 PM, Anton Prowse wrote:

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

> It's [this] rendering [...] that I find a little harder to justify.

Actually, this rendering has its own logic: assume that percentage 
widths are 100% in order to determine the width of the containing block, 
and then apply the specified percentage widths for real.

This approach, which fixes the container width and varies the child 
width as child percentage width varies, is the "opposite" of the other 
possible approach I described which fixes the child width (at its 
intrinsic width) and varies the container width as child percentage 
width varies.

Anton Prowse
Received on Saturday, 25 September 2010 08:34:05 UTC

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