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 09:58:26 +0200
Message-ID: <516FA7A2.1010805@exyr.org>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: www-style list <www-style@w3.org>
Le 18/04/2013 09:13, Tab Atkins Jr. a écrit :
> On Wed, Apr 17, 2013 at 11:50 PM, Simon Sapin <simon.sapin@exyr.org> wrote:
>> Actually, can we combine the two? What’s the specificity of this one?
>>      :not(#foo > :matches(h1, #bar))
> It's the most specific branch, which means you find the most specific
> :matches() branch and use that.  So the specificity is (2,0,0).
>> 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.
> Unroll the :matches() and just write the selectors out manually.  Your
> example becomes:
> :not(#foo > h1, #foo > #bar)
> The answer is now obvious.

In other words, the "most specific" rule recursively descends into 
nested :not() and :matches() pseudos. Is that correct?

Simon Sapin
Received on Thursday, 18 April 2013 07:58:49 UTC

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