- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 9 Jun 2011 10:56:39 -0700
- 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 UTC