- From: François REMY <francois.remy.dev@outlook.com>
- Date: Tue, 25 Nov 2014 23:28:10 +0100
- To: "'Tab Atkins Jr.'" <jackalmage@gmail.com>, "'www-style list'" <www-style@w3.org>
± 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