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

On Tue, Aug 5, 2014 at 5:19 PM, Benjamin Poulain <> wrote:
> On Aug 5, 2014, at 8:13 AM, Brian Kardell <> wrote:
> On Aug 5, 2014 11:04 AM, "Benjamin Poulain" <> 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,, .baz)
> This seems equivalent to the (forbidden) selector:
>     div:not(:matches(.foo,, .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