RE: [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?

This doesn't look like an easy one, indeed. Here are my current thoughts on the issue:

The semantic of ":matches" does not seem compatible with pseudo-elements matching. I'm under the impression it feels wrong to support pseudo-elements in :matches(...). Like you said, it's a filter not a combinator like a pseudo-element is.

That being said, you can't put combinators in :matches, too; the only thing is that we have a "match-all" selector for elements we can combine with :matches. We can't provide a "match-all" for pseudo-elements because they're not author-controlled. But, instead, we could possibly add a new ::matches definition as a parameterized pseudo-element selector segment. What do you think of ::matches(after,before)?

Just my two cents.
François

Received on Tuesday, 25 November 2014 22:28:42 UTC