- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 2 Sep 2013 12:36:06 -0700
- To: Brad Kemper <brad.kemper@gmail.com>
- Cc: www-style list <www-style@w3.org>
Forking to a new thread, trimming the cc list accordingly. On Mon, Sep 2, 2013 at 8:15 AM, Brad Kemper <brad.kemper@gmail.com> wrote: > Slightly off topic: > Hierarchies has not received a lot of review yet, but my view so far is that writing "&" so many times makes it more likely that it will be accidentally left off. I can see why you'd want it when modifying the outer selector with a class, pseudo-class, attribute selector, etc., but why is it needed for embedded rules that could have continued the outer rule with a space character? Because the grammar is ambiguous without it - you can't tell apart some types of selectors from properties without arbitrary lookahead. That said, I'm not actually happy with what Hiearchies currently specifies, which is part of why I haven't been pushing on it lately. I think we either need to bite the bullet and do an @nest rule inside of the style rule which then contains plain selectors (with & optionally used to indicate the parent selector), or figure out a "good enough" parsing compromise that lets us tell selectors and properties apart within a small, bounded number of tokens at the parser level, at the cost of sometimes misinterpreting previously-valid CSS. Example of the problem: If you see "foo:bar baz qux ...", that could either be a property named "foo" with a value of "bar baz qux ...", or a selector starting with a type selector of "foo" and a pseudoclass of ":bar", plus more selectors following. You can't tell either way for sure until you hit a ";" or "}" character (it was a property) or a "{" character (it was a selector). ~TJ
Received on Monday, 2 September 2013 19:36:54 UTC