Re: [selectors4] :not and :matches specificity (was :not(a, b) vs. :not(a):not(b)

Le 18/04/2013 00:10, Tab Atkins Jr. a écrit :
> On Wed, Apr 17, 2013 at 2:21 PM, Brian Kardell <bkardell@gmail.com> wrote:
>> It seems to me that it would be really nice if all of these, at least the
>> logical ones worked the same.
>>
>> It seems only (regardless of any impl constraints) treating with generic
>> "pseudo specificity" or saying that the rule itself is subject to N
>> specificities make sense in my mind.  I suppose max might have some
>> sensibility, but it seems to me at odds with what you are trying to express.
>
> The new :matches() behavior (use only the actual matched branches) is
> obviously the correct route - it gives you the exact same specificity
> as expanding the :matches() stuff out into a big list of selectors.
>
> We can't apply the same to :not(), because it's nonsensical.  *None*
> of the branches in a :not() are "taken", because if they are, the
> selector doesn't match. ^_^

Actually, can we combine the two? What’s the specificity of this one?

     :not(#foo > :matches(h1, #bar))

In other words:

In Selectors 3, Selectors are "functions" that map elements to booleans 
(matching or not), while the specificity is an intrinsic property of a 
selector, independent of the element being matched. Here it makes 
perfect sense for :not() to take the max specificity of its "arguments".

The new behavior for :matches() changes that: I like to think of 
Selectors now as "functions" that map elements to either "null" (not 
matching) or a specificity, which depends on which branch was taken in 
:matches() pseudos. But now I don’t see how :not() taking the max 
specificity can make sense.

-- 
Simon Sapin

Received on Thursday, 18 April 2013 06:51:28 UTC