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

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

From: Benjamin Poulain <bpoulain@apple.com>
Date: Tue, 05 Aug 2014 17:19:50 -0700
Message-id: <E1658B30-17AA-4050-9BE9-35CD8EEF9F63@apple.com>
To: Brian Kardell <bkardell@gmail.com>, www-style@w3.org
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.

Received on Wednesday, 6 August 2014 00:25:16 UTC

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