7 ms·

This looks awesome. I'm so glad they re-used the & syntax popular in many compile-to-CSS languages. Between this and CSS variables, I might not even need SASS i

This looks awesome. I'm so glad they re-used the & syntax popular in many compile-to-CSS languages. Between this and CSS variables, I might not even need SASS in my toolchain anymore, which would be amazing. @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.

honie 5y ago
Those were my reactions, too! The one thing that I want the most whenever I have to jump out of the CSS per-processor world and write regular CSS. 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.
- JonathonW 5y ago
  I'm sure there's a reason here that I'm not seeing, but it feels like it's being different for the sake of being different to me-- requiring `&` even in the simple case where you're combining them with the descendant combinator (plain space), but then also requiring `@nest` in any situation where `&` is not at the start of each selector. 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).
  - ihuman 5y ago
    There's an explanation in section 2, in the green box that says "Why can’t everything be directly nested?"
leemcd56 5y ago
I agree! I may use Sass if I were to write functions to generate grids, or element permutations based on a color palette, but at this point I don’t feel it’s all that needed.
Ciantic 5y ago
Was thinking about SCSS/LESS too, but notice that this is not valid: .foo { color: blue; .bar { color: red; } } The ampersand is required, unlike in LESS and SASS. I don't yet understand why, because requiring ampersand makes copy pasting things difficult, as you need to add or remove seemingly redundant ampersands to move in out of nesting.
- asddubs 5y ago
  it says it on the page, it's required because otherwise parsing will need unbounded lookahead, since any rule could also be a selector >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.
  - scotty79 5y ago
    Seems like a premature optimization at the cost of the user. 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.
deleted 5y ago
[deleted]
deleted 5y ago
[deleted]

honie 5y ago

Those were my reactions, too! The one thing that I want the most whenever I have to jump out of the CSS per-processor world and write regular CSS. 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.

JonathonW 5y ago
I'm sure there's a reason here that I'm not seeing, but it feels like it's being different for the sake of being different to me-- requiring `&` even in the simple case where you're combining them with the descendant combinator (plain space), but then also requiring `@nest` in any situation where `&` is not at the start of each selector. 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).
- ihuman 5y ago
  There's an explanation in section 2, in the green box that says "Why can’t everything be directly nested?"

leemcd56 5y ago

I agree! I may use Sass if I were to write functions to generate grids, or element permutations based on a color palette, but at this point I don’t feel it’s all that needed.

Ciantic 5y ago

Was thinking about SCSS/LESS too, but notice that this is not valid: .foo { color: blue; .bar { color: red; } } The ampersand is required, unlike in LESS and SASS. I don't yet understand why, because requiring ampersand makes copy pasting things difficult, as you need to add or remove seemingly redundant ampersands to move in out of nesting.

asddubs 5y ago
it says it on the page, it's required because otherwise parsing will need unbounded lookahead, since any rule could also be a selector >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.
- scotty79 5y ago
  Seems like a premature optimization at the cost of the user. 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.

deleted 5y ago

[deleted]

deleted 5y ago

[deleted]