Re: [selectors3 / 4] Cross element pseudo-elements

On Apr 14, 2009, at 8:40 AM, L. David Baron wrote:

> On Tuesday 2009-04-14 15:53 +0200, Giovanni Campagna wrote:
>> My proposal regards the processing model for "formatting
>> pseudo-elements" (all the above). I included some examples to make it
>> clearer, using ::selection because this is more likely to cross
>> elements, but any pseudo-element in principle can be used. I used
>
> I don't think we should necessarily assume that all pseudo-elements
> should be handled the same way.  It would be nice, but they may have
> conflicting requirements.

It is nice to have some sort of definitive guide like this to  
determine what is inside of what though, so perhaps all pseudo-element  
specifications should say where they fall in the pseudo-DOM ancestry  
chain.

>> 2) Secondly the UA must get the sequence of all content that matches
>> the pseudo-element (all content on the first line, all content
>> selected, all content that matches the regexp...), and split that
>> sequence at element boundaries
>> I selected "long content and some more that", splitting I get "long
>> content", " and some", "more", " that". Collapsed space goes in the
>> outer element, if in the DOM it goes in both (like
>> "content<space><space>and" in my example)
>
> For what it's worth, this contradicts what CSS 2.1 and
> css3-selectors say about :first-letter and :first-line; they say
> that the real elements are split and the pseudo-elements are in one
> piece.  (Early drafts of css3-selectors actually said the opposite,
> i.e., what you say, but CSS 2.1 wasn't updated soon enough, and
> implementations moved towards what CSS 2.1 said because that's what
> they were reading.)  I think we probably would have been better off
> with this "pseudo-elements innermost" approach, though.

Would you say its too late to change then? What are the implications  
of changing CSS4 to follow this, or is that even a something we can  
reasonably consider?

>> 3) The UA must then match the pseudo-elements selectors to every box
>> created by that splitting. A winning pseudo-element declaration is
>> found for every element in the ancestor chain.
>
> I'm not sure this works for all pseudo-elements; for example
> :first-letter and :first-line only apply to blocks.

Is this a matter of changing Giovanni's wording slightly (to, perhaps,  
"A winning pseudo-element declaration is
found for every _applicable_ element in the ancestor chain")? Or would  
it mean adding the first/last/nth-line/letter boxes to the "pseudo- 
DOM" as best as possible and then having the the rules ignored if the  
element is not a block?

[...]

>> 5) The Computed Values are found for the Specified Values as usual;
>> explicit inheritance (the inherit keyword) is from the superior- 
>> parent
>> of the pseudo-element that carried the winning declaration, not from
>> the enclosing box; for non specified properties (inherited or not),
>> values are found from the enclosing element or pseudo-element. The
>> order is
>> "::selection" => "::text" => "::first-letter" =>
>> "::nth-line()"/"::first-line"/"::last-line" => "::before / ::after /
>> ::marker / ::inside / ::outside / ::alternate / ::scrollbar-* /
>> ::footnote-* / DOM element"
>
> I don't think you should include the pseudo-elements that are
> tree-like (:before, :after, :inside, :outside, :marker, and probably
> some of the others that I'm not familiar with) in this special
> processing model.  They should work in CSS just like DOM elements;
> there's no need for the extra complications since they form a tree.
> I think current implementations of :before and :after are stable
> enough that we'd have trouble changing this, and I also don't see
> any good reason to make them more complicated and confusing.

It doesn't look to me like he is changing that, since he has them in  
the outermost box within the normal DOM element that it inherits from.

Received on Tuesday, 14 April 2009 16:13:51 UTC