W3C home > Mailing lists > Public > www-style@w3.org > November 2014

Re: [selectors] Specificity of :matches() inside :not()

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 26 Nov 2014 09:19:28 -0800
Message-ID: <CAAWBYDBnHzQErc_DB+wimM2dyUS_2mPF57SKQ4d4hXRNUJOVpA@mail.gmail.com>
To: Benjamin Poulain <bpoulain@apple.com>
Cc: www-style list <www-style@w3.org>
On Fri, Oct 31, 2014 at 12:30 PM, Benjamin Poulain <bpoulain@apple.com> wrote:
> I would like some clarification about the specificity of :matches() inside :not().
>
> The definition of :matches() says: "The specificity of a :matches() pseudo-class, however, is the specificity of the most specific complex selector that matched the given element.”.
> The definition of :not() says: "The specificity of a :not() pseudo-class is the specificity of the most specifc complex selector in its selector list.”
>
> When an element is matched, and :matches() is inside a :not(), we could conclude:
> -Since none of the nested selector inside :matches() matched the element, the specificity of the whole :matches() is null.
> -The specificity of the outside :not() would ignore the content of :matches().
>
> However, I think it would make more sense to take the most specific selector when :matches() is in :not(), that way the following two are strictly equivalent:
>         :not(foo, .bar, #baz)
>         :not(:matches(foo, .bar, #baz))
>
> In either case, a weird side effect is that:
>         :not(:not(:matches(foo, .bar, #baz)))
> does not behave like:
>         :matches(foo, .bar, #baz)
> Fixing that case would require giving :not() a specificity when failing to match, which does not seem too hard either.

The WG agreed in the telcon this morning that your proposal makes
sense.  I'll figure out how to wordsmith it and get it into the draft
shortly.

~TJ
Received on Wednesday, 26 November 2014 17:20:19 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:26 UTC