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:58:55 +0200
Message-ID: <4C9DB9CF.4010609@moonhenge.net>
To: "www-style@w3.org list" <www-style@w3.org>
CC: Boris Zbarsky <bzbarsky@MIT.EDU>
On 25/09/2010 10:44, Boris Zbarsky wrote:
> On 9/25/10 4:19 AM, Anton Prowse wrote:
>>> 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.
> That's not workable once the container has more than one %-width child,
> though. Though this is similar to what Gecko does for blocks with
> percentage margins and fixed widths that have shrink-to-fit parents....
>> 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.
> Uh... no. They're simply ignoring the percentage width style completely
> when determining the intrinsic width of the container, then applying it
> when determining the width of the kid. That's what Gecko does, at least.

(as I acknowledged in my follow-up).  The two things are equivalent, but 
my original formulation is better interpreted as a consequence of the 
approach rather than the motivation for it.

> For what it's worth, I'm finding it hard to believe that both behaviors
> are equally web-compatible... but maybe websites don't use markup like
> this.

I agree.  The latter approach of ignoring percentage widths to begin 
with is rather more robust, as you described.

Anton Prowse
Received on Saturday, 25 September 2010 09:00:15 UTC

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