Re: CSS Hierarchies / Selector Nesting Proposal

On 6/3/11 6:52 PM, Tab Atkins Jr. wrote:
>> So what _is_ the proposal, exactly?  At this point I feel like I can't even
>> evaluate it, because I have no idea what exactly is being proposed.
>
> I'm confused as to how you're confused.

Your proposal does not describe your processing model.  I assumed one, 
but apparently assumed an incorrect one.  Instead of assuming another 
one and hoping, I'm asking you to actually defined your processing model.

> The "type selectors must
> be at the beginning of a selector" thing is a practical restriction,
> not a technical one.

I'm not talking about just type selectors.  I'd like to understand 
exactly what syntax your proposal allows and what the syntax means.

> This isn't absolutely necessary - we could use a simple text-replace
> model - but it would be slightly unfortunate to miss out on that
> use-case.

That's fine, but then you need to define your model. Seriously.

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

   ::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).

> We additionally impose a restriction that it must be at the start of any selector
> sequence, so we can reliably disambiguate it from a property/value
> pair, but that's unrelated to the meaning of the selector.

OK.  That's nice.  I'd like to once again request a definition of the 
processing model.  And I don't mean the definition-by-example exercise 
you just did.

-Boris

Received on Monday, 6 June 2011 00:22:59 UTC