W3C home > Mailing lists > Public > www-style@w3.org > January 2008

Re: Section 10.3.8 really needs to be fixed

From: Ben Cotterell <ben.cotterell@antplc.com>
Date: Sun, 27 Jan 2008 16:00:22 +0000
To: CSS <www-style@w3.org>
Message-ID: <09fc2be1cb6a8b743b18ab0a085a964ac2d5851e@localhost>

On Sat, Jan 26, 2008 at 11:10:25PM -0800, fantasai wrote:
> David Hyatt wrote:
> >
> >This compliance change we made in WebKit to match section 10.3.8 of 
> >CSS2.1 continues to cause problems on the real-world Web.  We've gotten 
> >numerous bugs on this issue, and I've brought this up before.
> >
> >http://www.w3.org/TR/CSS21/visudet.html#abs-replaced-width
> >
> >http://bugs.webkit.org/show_bug.cgi?id=16975
> >
> >The spec is just plain wrong.  The results it gives don't match the 
> >common sense rendering that Web site authors would expect for:
> >
> ><iframe style="position:absolute;left:0;top:0;right:0;bottom:0"></iframe>
> >
> >If I specify a top, bottom, right and left of 0, then why on earth 
> >should the object's intrinsic width or height override?  It's completely 
> >counter-intuitive that you can't use this pattern to stretch an iframe 
> >or image in CSS2.1.

We also have a couple of bugs in our system against this kind of thing
found on real-world web pages. We currently do something similar to
Konqueror-- "intrinsic" width trumps right for iframes.

> >Note that Firefox 3 even interprets the spec very literally and doesn't 
> >stretch in the left/right case but does in the top/bottom case (this 
> >behavior is even crazier IMO).
> >
> >This section of the spec needs to be amended.
> 1. It would be useful if you could post the URL of a testcase.
> 2. We'll need test results for at least the latest releases of Safari, IE,
>    Mozilla, Opera.
> 3. I personally have no opinion on this, other than that whatever change we
>    make must not affect the current set of computations when 'auto' margins
>    are involved.

10.3.8 as it stands is quite good for replaced elements that really have
intrinsic dimensions, like images. But less good for ones that don't,
like iframes.

The problem is the spec tells you to go and do 10.3.2 first. After doing
10.3.2, you always have a width, even if you just had to conjure up
300px or similar out of nowhere.

That width is worth keeping (if they set both left and right) if it's a
real intrinsic width, but not if it's a contrived one.

Basically I think it would work if said something like "the
used value of width is determined as for inline replaced elements, but
if width is auto and the element doesn't have intrinsic dimensions, then
width stays auto."

Then you'd have something similar to 10.3.7 steps 4-6 explaining that if
width is auto and left and right aren't you solve for width.

Ben Cotterell
Senior Software Engineer, ANT Software Limited
Received on Sunday, 27 January 2008 16:00:42 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:33 UTC