Re: [selectors4] Not clear where pseudo-elements fit in

On Mon, Mar 23, 2015 at 3:40 PM, L. David Baron <dbaron@dbaron.org> wrote:
> I was trying to read selectors4 to determine whether a
> pseudo-element inside of :host-context() [1] made the selector
> invalid (or just never matched... I think).
>
> I reached http://dev.w3.org/csswg/selectors-4/#structure , and found
> that compound selectors do not include pseudo-elements, which I
> believe answers my question to my satisfaction (and matches Gecko's
> current implementation of :-moz-any()).
>
> However, I then noticed that nothing in that section mentions
> pseudo-elements at all, so it's not clear that my interpretation is
> correct.
>
> http://dev.w3.org/csswg/selectors-3/#selector-syntax , on the other
> hand, does say that pseudo-elements fit in at the "complex selector"
> level (level 3's "selector"), which makes it more clear that they're
> intentionally not included as part of a "compound selector".
>
> I think it would probably be good to have similar wording, and maybe
> even something clearer, in Level 4, so that it's clear that
> pseudo-elements are not part of a "compound selector" and thus their
> presence in a <compound-selector> [2] is a parse error.
>
> (Unless, of course, the opposite is intended, in which case that
> should be clear.)

The opposite *is* sometimes intended; there are some contexts where
something only wants to allow compound selectors, but also wants to
allow pseudo-elements.  One example is the "simple" form of
:matches(), which only allows compound selectors.  We *really* want to
allow pseudo-elements in this, though - if you can write "div >
:matches(a, b)" you should be able to write "foo:matches(::before,
::after)" or something like that - ::before/::after are basically
children of the element, and should be selectable just as easily as
actual children.

This is the part I ran into trouble.  Selectors 3 does define
pseudo-elements in the "complex selector" category, and that's
honestly the best place for them in general.  Compound selectors are a
set of filters that a single element must satisfy; complex selectors
involve some movement around the tree, and invoke filters on multiple
elements.  A selector with pseudo-elements in it, almost by
definition, has "movement around the tree" intrinsically.

The issue here is that the pseudo-element effectively has a combinator
built into its syntax.  This is why, a few years ago, I tried to
explore rationalizing this as :: being a combinator into the "pseudo
tree" of an element (which would contain elements with a tagname of
"before" and "after", etc).  This built-in combination makes things
hard to define, and gives us weird corners, like the
:matches(::before, ::after) case.

I don't know what to do about this.  Suggestions?

~TJ

Received on Wednesday, 25 March 2015 22:54:56 UTC