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). ~TJReceived on Monday, 2 September 2013 19:36:54 UTC
This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:31 UTC