W3C home > Mailing lists > Public > www-style@w3.org > November 2014

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 24 Nov 2014 16:47:43 -0800
Message-ID: <CAAWBYDAo0jWaE8O81dBkF8AOTA2Pf=qVmVJZqeg-ODH9jteP2g@mail.gmail.com>
To: www-style list <www-style@w3.org>
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.

Received on Tuesday, 25 November 2014 00:48:29 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:26 UTC