W3C home > Mailing lists > Public > www-style@w3.org > June 2011

Re: CSS Hierarchies / Selector Nesting Proposal

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 9 Jun 2011 10:56:39 -0700
Message-ID: <BANLkTin-Z04fYUCM9R9C-W7GVQKdEe3aY+0_i1parvL2=Lz+WA@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: www-style@w3.org
On Sun, Jun 5, 2011 at 5:22 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 6/3/11 6:52 PM, Tab Atkins Jr. wrote:
>> If you're still somewhat confused, the&  is just a selector which
>> matches any element matched by the outer selector.
>
> So just to be clear:
>
>  ::after {
>    &::before { color: red; }
>  }
>
> Is that a parse error?  Something else?  What about:

It definitely wouldn't be a parse error.  It would produce a selector
equivalent to "::after::before", which is just an invalid selector.
However, see below.


>  ::after {
>    &body { content: "Will this show up?"; }
>  }
>
> In this case, the "& is just a selector which matches *::after" doesn't seem
> to make much sense....  (This would all be simpler if *::after had to be
> written as * > ::after, but that's not how it's done now).

Yeah, this is where the details really matter.  While it would be kind
of nice for this to "just work" (producing a selector equivalent to
"body::after"), the fact that pseudoelements are order-dependent
(somewhat now, and strongly so if we change Selectors to allow
chaining pseudoelems) makes this a lot more difficult.

I'm inclined to make it a parse error to nest within a pseudoelement
selector.  I'll mark this as an issue in the spec I write.

~TJ
Received on Thursday, 9 June 2011 17:57:36 GMT

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