W3C home > Mailing lists > Public > www-style@w3.org > September 2010

Re: Enhancing grouping of selectors

From: L. David Baron <dbaron@dbaron.org>
Date: Sun, 19 Sep 2010 18:32:16 -0700
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, Anne van Kesteren <annevk@opera.com>, www-style@w3.org
Message-ID: <20100920013216.GA3201@pickering.dbaron.org>
On Sunday 2010-09-19 13:06 -0700, Tab Atkins Jr. wrote:
> On Sun, Sep 19, 2010 at 11:06 AM, L. David Baron <dbaron@dbaron.org> wrote:
> > I think it's more likely that the confusion is over what
> > :not(a):not(.foo) means than over what :not(a.foo) means, though.
> > If that's the case, then that's an argument that we should allow
> > :not(a.foo).
> 
> :not(a):not(.foo) seems very clear, actually.  Without any special
> magic interaction, it means "tag name is not 'a' and class is not
> 'foo'".  Simple selectors always AND together by default.

I guess the source of confusion I'm thinking of is that it's
probably confusing to many people to convert from the form they
originally think of it in to some other form.  So if an author wants
to match "all elements that aren't a elements with class foo", it
might seem logical to them to write :not(a.foo) but they might have
trouble converting that to :not(a), :not(.foo) (which,
coincidentally, also has different specificity).

It seems worthwhile to allow at least the next level of complexity
inside :not().  (It does pose some backwards-compatibility issues
with default namespaces, though.)

-David

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/
Received on Monday, 20 September 2010 01:33:01 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:31 GMT