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

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
<https://dvcs.w3.org/hg/csswg/annotate/f1265e5e2557/selectors4/Overview.src.html#l567>
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.

Fixed.

~TJ

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