Re: [selectors] Assistance requested in figuring out the data model of pseudo-elements

On Tue, Nov 25, 2014 at 1:37 PM, Benjamin Poulain <benjamin@webkit.org> wrote:
> My 2 cents, not sure if that helps:
>
> My own mental model for pseudo element is not one of a combinator that goes
> into some kind hidden element.
>
> The way I use pseudo-elements is as a "generator", to create fake styling
> elements where there is none. For example, if I use:
>     :matches(::first-line, ::before) { ... }
> I think of it as if the engine generates elements for the first-line and
> something before the current element.

It generates *and switches the currently-matched element* to the
pseudo-element.  That second part is the definition of a combinator -
it's identical to the child combinator, for example.  It just happens
to have the extra magic that it creates the elements for you, rather
than them pre-existing in the tree.

In other words, if you ignore pseudo-elements, then the set of matched
elements after processing a :matches() selector is ALWAYS a subset of
the matched elements before processing.  Pseudo-elements change this
behavior.

> In my mind, the way it works with :matches() is as if the rules were
> expanded and the pseudo-elements were moved to the end.
> For example:
>     :matches(a, b):matches(*, ::before, ::after)
>     ->*:matches(a, b), :matches(a, b)::before, :matches(a, b)::after
>     ->a, b, a::before, b::before, a::after, b::after.

This isn't great; it means you can't then continue after the pseudo-element.

For example, the spec currently allows `a::before:hover` which matches
when the <a>'s ::before pseudo-element is hovered.  (I don't think
this has been implemented yet by anyone.)  The way :matches() works,
it *should* be possible to wrap :matches() around any individual
simple selector and maintain exactly the same semantics, so
`a:matches(::before):hover` should work the exact same way as the
previous selector.

If you assume that pseudo-elements only ever exist at the end of a
selector, like the spec used to require, this isn't as much of a
problem.

~TJ

Received on Tuesday, 25 November 2014 22:13:57 UTC