- From: Anton Prowse <prowse@moonhenge.net>
- Date: Sat, 25 Sep 2010 10:58:55 +0200
- 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. Cheers, Anton Prowse http://dev.moonhenge.net
Received on Saturday, 25 September 2010 09:00:15 UTC