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

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