@nest looks extremely cool too. An easy way to keep rules affecting one selector logically grouped with it, even if the selector relies on a small thing about its parent elements.
.foo {
color: blue;
.bar {
color: red;
}
}
>Nesting style rules naively inside of other style rules is, unfortunately, ambiguous—the syntax of a selector overlaps with the syntax of a declaration, so an implementation requires unbounded lookahead to tell whether a given bit of text is a declaration or the start of a style rule.
>For example, if a parser starts by seeing color:hover ..., it can’t tell whether that’s the color property (being set to an invalid value...) or a selector for a <color> element. It can’t even rely on looking for valid properties to tell the difference; this would cause parsing to depend on which properties the implementation supported, and could change over time.
>Requiring directly-nested style rules to use nest-prefixed selectors works around this problem—an & can never be part of a declaration, so the parser can immediately tell it’s going to be parsing a selector, and thus a nested style rule.
>Some non-browser implementations of nested rules do not impose this requirement. It is, in most cases, eventually possible to tell properties and selectors apart, but doing so requires unbounded lookahead in the parser; that is, the parser might have to hold onto an unknown amount of content before it can tell which way it’s supposed to be interpreting it. CSS to date requires only a small, known amount of lookahead in its parsing, which allows for more efficient parsing algorithms, so unbounded lookahead is generally considered unacceptable among browser implementations of CSS.
I don't care how fast it runs if it doesn't do what I want.
EDIT: yeah, you probably are right ... I know too little about parsers. Maybe there exists a formal proof that you can't make a fast parser for that syntax without unbounded lookahead.
Maybe they should even create CSS from the start as two part system. Convenient syntax for humans, once written compiled to StyleAssembly comfortable for the browser.
Avoiding unbounded lookahead is not "premature" optimisation - if introduced, it would never be possible to remove due to the algorithmic complexity involved.
It is worth noting that in SASS you can already refer to parent elements as they have shown with the `@nest` rule (apologies if I misunderstood what you said and you already know this). I do prefer the more verbose `@nest` syntax though, as the intention is clearer.
SASS takes the opposite approach-- there's an implicit `&` at the beginning if you don't specify it elsewhere, and it can appear anywhere (i.e. the example `:not(&)` does not have to have anything like the `@nest` syntax in SASS).