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

Re: [selectors] Why the special cases in the definition of :not()?

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 8 Aug 2014 16:52:02 -0700
Message-ID: <CAAWBYDAJw6BYjAfsQr-6KvgfF2Ovu=HBB6QmKbqYOuL8T3L_og@mail.gmail.com>
To: Benjamin Poulain <bpoulain@apple.com>
Cc: Brian Kardell <bkardell@gmail.com>, www-style list <www-style@w3.org>
On Tue, Aug 5, 2014 at 5:19 PM, Benjamin Poulain <bpoulain@apple.com> wrote:
> On Aug 5, 2014, at 8:13 AM, Brian Kardell <bkardell@gmail.com> wrote:
> On Aug 5, 2014 11:04 AM, "Benjamin Poulain" <bpoulain@apple.com> wrote:
>> I am starting to look into Selectors Level 4 and I would like to
>> understand the rationale behind some design choices of :not():
>> -Why is there limitations on the nesting of :not() with other functional
>> pseudo classes? The combinations ":matches(:not(...))", :not(:matches(...))
>> or :not(not()) seem useful for authors and easy to implement.
>> -Why take a selector list as the argument? This seems to be equivalent to
>> :not(:matches(...)) while providing a more complicated syntax.
> Can you explain the last bullet with examples? I'm thinking I must be
> misunderstanding what you are saying
> Let's say we have:
>     div:not(.foo, ..bar, .baz)
> This seems equivalent to the (forbidden) selector:
>     div:not(:matches(.foo, ..bar, .baz))
> For the first one, the list could be misinterpreted as a “not” over a
> disjunction or a conjunction. The second one is unambiguously a regular
> logical “not" over a disjunction.

It's definitely equivalent.

I did some VCS diving, and found
as the commit that changed :not() from taking a simple selector to a
compound selector list.  It looks like we just didn't think this
through properly, and maintained the earlier restriction that you
can't nest :not().  That restriction made sense when :not() only took
a simple selector, as multiple :not()s were equivalent to 0 or 1
:not()s, but now it's a useless restriction.


Received on Friday, 8 August 2014 23:52:49 UTC

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