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

On 3/26/15 1:41 PM, Tab Atkins Jr. wrote:
> On Thu, Mar 26, 2015 at 10:30 AM, Daniel Tan <lists@novalistic.com> wrote:
>> ... 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.
>
> Yeah, I'd prefer not to have a pseudo-class and a pseudo-element that
> do the same thing with the same name. ^_^
>
> WebKit currently just allows pseudo-elements in :matches().  You can
> totally do `.foo:matches(::before, ::after)` to get the equivalent of
> `.foo::before, .foo::after`; in other words, it just treats the
> pseudo-element as a simple selector for this purpose.
>
> Maybe that's all I need to do?  Specify that pseudo-elements *can* be
> simple selectors, when a context defines them as such, but they
> normally aren't; when they aren't, their use in a selector
> automatically makes it a complex selector.  I suppose I'm okay with
> that.

We tried to avoid a special definition for :matches().

The way we try to handle :matches() is as if it was producing all the 
combination as a flat comma-separated selector.

Say you have:
     foo:matches(.a, .b) >> bar:matches(::before, ::after)

It should be equivalent to:
     foo.a >> bar::before, foo.a >> bar::after, foo.b >> bar::before, 
foo.b >> bar::after

Both in matching and for the specificity.


If you find anything that does not behave like that, please tell me 
about it, it is a bug.

Benjamin

Received on Thursday, 26 March 2015 20:57:01 UTC