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

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

From: Peter Moulder <peter.moulder@monash.edu>
Date: Sat, 14 Aug 2010 11:55:57 +1000
To: www-style list <www-style@w3.org>
Message-id: <20100814015557.GA13958@bowman.infotech.monash.edu.au>
On Fri, Aug 13, 2010 at 06:02:54PM -0700, Tab Atkins Jr. wrote:
> On Fri, Aug 13, 2010 at 5:56 PM, Peter Moulder <peter.moulder@monash.edu> wrote:
> > On Fri, Aug 13, 2010 at 08:25:30AM -0400, Boris Zbarsky wrote:
> >> On 8/13/10 3:48 AM, Peter Moulder wrote:
> >> >If a user agent doesn't consider the float to be part of the first line,
> >> >then it's probably because of the following from section 5.12.1:
> >> >
> >> >   # The "first formatted line" of an element may occur inside a block-level
> >> >   # descendant in the same flow (i.e., a block-level descendant that is not
> >> >   # positioned and not a float)
> >> >
> >> >Presumably people are reading that as saying that the first formatted line of
> >> >an element can't occur inside a descendent that is a float;
> >> >which does seem like a reasonable guess as to the intent of that text.
> >>
> >> Peter, please reread what I wrote in the post that Tab was
> >> responding to, and which you conveniently quoted.  No one is
> >> claiming that the first formatted line is inside the float.  But the
> >> float inherits color from a span and that span is most certainly
> >> inside the first formatted line of the block.
> >
> > I agree that your reading is a reasonable one, and it's the behaviour that I
> > would expect, but I can't find any normative text that actually declares
> > the "red" interpretation to be non-conforming.  Maybe the user agent is deliberately
> > wrapping just "the first formatted line", and taking this to exclude the float,
> > which does not inherit from a formatted line.
> The relevant part of the spec is in 5.12.1:
> # A UA should act as if the fictional start tags of the
> # first-line pseudo-elements were nested just inside the
> # innermost enclosing block-level element.

That was the text that made me say "it's the behaviour that I would expect".
But I'm actually now leaning away from this, by the following analysis:

  The cascade does not yield a declaration for 'color' for the float (section
  6.1.1 rule 1), so we procede to rule 2 and "use the computed value of the
  parent element."

  Everyone agrees on the above, the question is what "the parent element" is,
  and whether the rewriting that 5.12.1 attempts to describe affects what "the
  parent element" is for purposes of calculating the float's computed value of

  And I would consider it entirely reasonable to take the "fictional" rewriting
  described in 5.12.1 that 5.12.1 doesn't actually say occurs but just says
  that a certain example “might be "rewritten" user agents”, and that this
  "helps to show how properties are inherited", as only helping to describe the
  inheritance for the first-line formatting, and that it doesn't affect the
  calculation of the float's computed values, which inherit from its "parent
  element", or "element in the document tree" as section 6.2 says.  And I think
  that all the qualifications (such as "fictional" and "might") used in 5.12.1
  might very reasonably be taken as not affecting the document tree as far as
  the rules concerning the calculation of the float's computed value.

But as I say, I don't think we should spend time discussing what the best
interpretation of the existing text is, I think we should take this opportunity
to decide what behaviour we want, and then change the spec to make that clear.

And I'm actually inclined to think that if we're choosing what the text should
specify, then red is actually the behaviour that we want to specify: from what
I've considered so far, I think it best if inheritance is based on the true
document tree, and that we make the 5.12.1 text restrict itself to describing
the formatting within the first line box.

Received on Saturday, 14 August 2010 01:56:29 UTC

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