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

I'm trying to come up with the right text to express that
pseudo-elements can be used in :matches(), per the thread at
<http://lists.w3.org/Archives/Public/www-style/2014Aug/0402.html>, and
I'm having a hell of a time.

The basic problem is that our syntactic model for pseudo-elements is a
giant mess.  Ignoring pseudo-elements, selectors are composed of
simple selectors, which filter the current match set, and combinators,
which transform the current match set.  But pseudo-elements lie
in-between those two - they're syntactically similar to a simple
selector, but they act like a combinator, transforming the match set
into a different set of nodes.

Because of this confused identity, pseudo-elements don't work well
with our abstractions.  If you want both the <a> and <b> children of
an element, you can write `foo > *:matches(a,b)`.  But if you want the
::before and ::after pseudo-elements of an element, there's no real
equivalent - it's impossible to first transform the match set into one
that contains the pseudo-elements in question, and then write a
:matches() argument that'll match them.

Instead, I'm going to have to allow something like
`foo:matches(::before, ::after)`, which is broken, semantically - the
:matches() pseudo is *supposed* to just be another filter for the
compound selector, but this instead makes it *change* the node the
compound selector is pointing to.  This makes things even more
complicated, too, because suddenly the order of the simple selectors
in the compound selector matter - just like `foo::before:hover` is
different from `foo:hover::before`, `foo:matches(::before):hover` is
different than the other order.  (Again, this is because
pseudo-elements are actually combinators+selector pairs, not simple
selectors. ARGH.)

Does anyone know any way to express this sanely, or am I just going to
have to grin and bear it and deal with the inconsistency that
pseudo-elements are allowed in places that combinators aren't?

~TJ

Received on Tuesday, 25 November 2014 00:30:37 UTC