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

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.

> 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.

> 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.

> "long content" gets "color" from "span::selection" and "p::selection",
> "background-color" from "div::selection"
> " and some" gets "color" from "p::selection", "background-color" from
> "div::selection"
> "more" gets "color" from "p::selection", "p#important::selection", but
> "p#important" wins over "p", so only from "p#important::selection".
> "background-color" is given by both "p#important::selection" and
> "div::selection"
> "that" gets "background-color" from "div::selection"

In http://lists.w3.org/Archives/Public/www-style/2008Oct/0268.html I
actually proposed three different ways that this (and step (4))
could be accomplished.

> 4) Declarations attached to pseudo-elements whose superior parent is
> deeper in the DOM win over the others.
> So:
> "long content" gets a Specified Value for "color" of "inherit", only
> from "span::selection" because "span" is deeper than "p";
> "background-color" comes only from an element, so no problems
> " and some" has no conflicting declarations
> "more" gets "background-color" from "p#important::selection" because
> "p" is deeper than "div", "color" is not a problem, it has already
> been found from step 3
> "that" has no conflicting declarations

So it sounds like what you're proposing is option (B) in
http://lists.w3.org/Archives/Public/www-style/2008Oct/0268.html .

> 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.


I'd also note that one other proposal that's been floating around
for quite a while is that inherited and non-inherited properties be
handled differently for some of these pseudo-elements.  (The
proposal was made while considering :first-line and :first-letter.
It actually suggested that whether the pseudo-elements go inside or
outside the real elements vary between the inherited and
non-inherited properties.)  I think Gecko actually implements a part
of this proposal for the 'inherit' keyword.

-David

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

Received on Tuesday, 14 April 2009 15:41:37 UTC