- From: Paul Duffin <pduffin@volantis.com>
- Date: Sun, 19 Sep 2010 02:19:52 -0600 (MDT)
- To: Patrick Garies <w3c.www-style@patrick.garies.name>
- Cc: "L. David Baron" <dbaron@dbaron.org>, "Tab Atkins Jr." <jackalmage@gmail.com>, Matthew Millar <mattmill30@hotmail.com>, www-style@w3.org
----- Original Message ----- > On 2010-09-19 1:34 AM, Paul Duffin wrote: > > It just seems very restrictive and I was wondering why that was the > > case. If you following the email trail it came to light in a > > discussion about :any(), or rather the :-moz-any() described here > > [1] > > which I know is not a standard but is a similar 'logical' pseudo > > class. The two are inconsistent and I just wanted to understand why > > that might be. > > I still don't see how you came to the conclusion that the CSS2.1 > definition of "simple selector" might have accidentally been used as a > reference in the CSS3 Selectors specification. > It wasn't a conclusion, I just thought that there may have been an outside chance that the restriction wasn't intentional. > That said, I don't know why the |not| pseudo-class is restricted to > use > with CSS3 Selectors simple selectors. A quick search of the list > archive > [1] indicates that this topic has been discussed here before [2] [3] > [4]. fantasai indicated that the restriction would be likely be > removed > in CSS4 Selectors, but didn't describe why the limitation was in > place. [4] > Thanks for those links. Apologies I should have searched the mailing list myself. I trawled through all the entries for :not and found [5]. I vaguely remember heading the first argument, i.e. :not(input[disabled]) being the same as :not(input),:not([disabled]) but not the second. [5] <http://lists.w3.org/Archives/Public/www-style/2006Aug/0152.html>
Received on Sunday, 19 September 2010 08:20:25 UTC