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

On 3/26/2015 6:54 AM, Tab Atkins Jr. wrote:
> 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
>

Personally I've always thought it was clear: "compound selector" is 
defined as a sequence of simple selectors, and the definition of "simple 
selector" excludes pseudo-elements -- therefore pseudo-elements are 
never part of compound selectors.

Clearly, the solution in this case is to make pseudo-elements simple 
selectors, but I jest.

... other than that, the only thing I can think of for the specific case 
of matches, is a ::matches() functional pseudo-element just for 
pseudo-elements. So something like ::matches(before, after), where each 
'tagname' represents a pseudo-element name.

Except there is potential confusion between single and double colons -- 
:matches(before, after) is not nearly the same thing as 
::matches(before, after) for example, even though the pseudo-class 
syntax is just as valid in its own right, only meaningless in HTML. And 
as I mentioned, this doesn't really solve the more generalized problem 
either.

Anyway, just throwing it out there.

-- 
Daniel Tan
NOVALISTIC
<http://NOVALISTIC.com>

Received on Thursday, 26 March 2015 17:31:18 UTC