- From: Benjamin Poulain <benjamin@webkit.org>
- Date: Tue, 25 Nov 2014 13:44:36 -0800
- To: www-style@w3.org
On 11/24/14, 4:47 PM, Tab Atkins Jr. wrote: > On Mon, Nov 24, 2014 at 4:33 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: >> On Mon, Nov 24, 2014 at 4:29 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: >>> 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. >> In a just world, I could write `foo :: *:matches(before, after)`, >> because ::before and ::after would be normal elements in the >> pseudo-tree, with tagnames and everything, and then all of this would >> Just Workâ˘. Yet more evidence that this is not the best of all >> possible worlds. >> >> (Some of you might recall that I tried to make this happen a few years >> ago, but the exceptions needed to make existing code like `::before >> {...}` work were too much.) > Actually, let's revisit that. Here are the four basic syntax forms > that pseudo-elements can exist in: > > 1. `a::b` > 2. `::b` > 3. `a>b::c` > 4. `a>::c` > > In each of the even cases, we can transform it into an odd case by adding a *: > > 2. `*::b` > 4. `a>*::b` > > If we pretend that :: is a combinator, then this implies two simple rules: > > A selector that start with a :: combinator (in a context that doesn't > expect a relative selector) is treated as starting with a *. A > selector with a non-:: combinator followed immediately by a :: > combinator (possibly with intervening whitespace) is treated as having > a * between the two combinators. > > We could generalize these rules to all combinators, or special-case > them to just the :: combinator. > > If we do this, then my example of the just world would work, and I > wouldn't have to explain why one kinda-combinator is allowed in > :matches() but no other, and why the order of selectors matters if > :matches() contains a pseudo-element. I am confused with this last paragraph. Aren't all combinators already allowed in :matches()? The definition says the argument is simply a selector list. WebKit allows any combinator in :matches(). Using combinators in :matches() is super useful, we already use that a lot. Benjamin
Received on Tuesday, 25 November 2014 22:07:30 UTC