Re: CSS Hierarchies / Selector Nesting Proposal

On Fri, Jun 3, 2011 at 6:13 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 6/3/11 3:06 AM, Tab Atkins Jr. wrote:
>>
>> Yes, it's intended that things like "&input" be supported.  The
>> restriction for tagname selectors to be the first part of a complex
>> selector is solely because we can't distinguish the start of a tagname
>> selector from the end of another selector.
>
> Wait.  So I thought I understood the proposal, but now I see that I don't.
>
> I had assumed that the proposal was a string replace where the '&' is
> replaced by the text of the actual selector from the outer nesting level.
>  But clearly that's not it.
>
> 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.  ^_^  The "type selectors must
be at the beginning of a selector" thing is a practical restriction,
not a technical one.  If type selectors had a prefix like all the
other selectors, we could insert them in arbitrary places without it
being ambiguous.  (Potentially, we could put type selectors after
attribute selectors or pseudos with parens, but it would be confusing
to only allow it there.)  As it so happens, we can put a nesting
selector (the &) at the start of a selector and then put a type
selector after it without it being ambiguous.  This enables a useful
case, as Eduard pointed out.

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.

If you're still somewhat confused, the & is just a selector which
matches any element matched by the outer selector.  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.

~TJ

Received on Saturday, 4 June 2011 01:52:56 UTC