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

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:
> >
> > Hi,
> >
> > 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.

Benjamin