W3C home > Mailing lists > Public > www-style@w3.org > April 2013

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

From: Simon Sapin <simon.sapin@exyr.org>
Date: Thu, 18 Apr 2013 08:50:40 +0200
Message-ID: <516F97C0.7050607@exyr.org>
To: www-style@w3.org
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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:28 UTC