- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 3 Jun 2011 18:52:09 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: www-style@w3.org
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