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

Re: [CSS 2.1] cases that do not pass in any browser

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Mon, 23 Aug 2010 21:59:49 -0400
Message-ID: <4C732795.5050805@mit.edu>
To: fantasai <fantasai.lists@inkedblade.net>
CC: Peter Moulder <peter.moulder@monash.edu>, www-style list <www-style@w3.org>
On 8/23/10 9:40 PM, fantasai wrote:
> On 08/23/2010 04:53 PM, Boris Zbarsky wrote:
>> On 8/23/10 5:23 PM, fantasai wrote:
>>> On 08/22/2010 11:47 AM, Boris Zbarsky wrote:
>>>> In practice, I would expect that to a first approximation authors just
>>>> never use first-line on blocks with floats in them. Otherwise they
>>>> would
>>>> have been complaining about the inconsistent behavior.
>>> I'll note that
>>> ::first-letter { float: start; }
>>> is the recommended way to deal with drop caps. It would make sense here
>>> for the float to take the color of the ::first-line, wouldn't it?
>> This is not quite the same, unless there's a span around that first
>> letter. In particular, floats that are not inside an element on the
>> first line do NOT get first-line styling in Gecko and Presto. They do in
>> Webkit for the first-letter case, but not for a floated span (that is,
>> Webkit treats floating first-letter specially, which makes some sense,
>> because it's not really a float).
>> I don't have IE8+ on hand right this second to test.
> Why does having the <span> there matter?

Because with a float directly as the child of a block one can make the 
argument that the float is not on the first formatted line at all, and 
hence isn't affected by the first-line stuff and should continue to 
inherit directly from the block itself.  This seems to be what UAs 
interoperably implement (if we ignore first-letter for the moment).

The whole point of an inline parent for a float is that in that 
situation the float clearly inherits from that inline, and there is no 
argument about the inline being on the first formatted line and being 
affected by the first-line styles.

Or that's what you would think, at least.  In fact, even that much is 
not interoperable, as this simple testcase demonstrates:

   <!DOCTYPE html>
     div { color: red; }
     div:first-line { color: green; }
   <div><span style="border: 10px solid">Green text</span></div>

In Gecko and Presto, the text and border are both green, which is 
consistent with the computed color of the <span> being green as the spec 
calls for.  Given that, I can't explain why in Opera a floating child of 
the span doesn't have computed color green.

In Webkit, the text in the testcase above is green, but the border is 
not.  It's red.  As far as I can tell, Webkit's implementation of 
first-line simply has nothing to do with what the spec says; it .  Do we 
have anything in the test suite remotely pretending to test first-line? 
  If not, I'd be happy to contribute a few tests if they will still be 
accepted at this point.


P.S.  For extra fun, if the div color above is set to rgba(255,0,0,0.5) 
then in Webkit the corners of the border are not the same color as the 
sides.  That doesn't seem like the right behavior either, unless I'm 
missing something... but faster to paint than doing it right..  Probably 
not tested in the test suite either, right?
Received on Tuesday, 24 August 2010 02:00:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:49 UTC