- 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
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 UTC