Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Will nested CSS support mixing properties and nested rules in any order, or do all the nested rules have to grouped together at the end? Right now, I frequently write SCSS rules like this:

  .some-class {
      background: blue;
      &:hover {background: red}
      border: 1px solid;
      &:active {border: 1px dashed}
      padding: 16px;

      display: flex;
      gap: 8px;
      
      & > * {
          color: red;
      }
  }
And it would be a pity if that wasn't allowed.

The reason I ask is because I seem to remember an early proposal not allowing this, but I can't find where I read it.



As I understand it, you can mix it but the parser will hoist all the immediate some-class styles to the top


Why would it not support it?


I don't know, that's why I'm asking.


lol just curious what the thought process is. Sass and postcss support that and every other css flavor with nesting I've used supports it and it seems like it'd be a pretty big deal and something that would be explicitly called out in the article if it didn't support it. So I'm just curious if you've run into an issue with that or if there's some in-the-weeds technical reason why that might not be supported


My memory was correct. I found the section in the original proposal[1] that did not allow mixing nested rules and declarations:

> When a style rule contains both declarations and nested style rules or nested conditional group rules, the declarations must come first, followed by the nested rules. Declarations occuring[sic] after a nested rule are invalid and ignored.

[1] https://www.w3.org/TR/2021/WD-css-nesting-1-20210831/#mixing

Fortunately, this has been changed in the most recent proposal[2]:

> When a style rule contains both declarations and nested style rules or nested conditional group rules, all three can be arbitrarily mixed. However, the relative order of declarations vs other rules is not preserved in any way.

[2] https://www.w3.org/TR/css-nesting-1/#mixing


Very interesting and exactly what I was curious about! Thanks for the links

Really curious about the reasoning behind that initial quirk


Depending on the exact parsing strategy it might be genuinely required (such as if the parser switches from "property mode" to "rule mode" at some point), but in this case it was just because it's kinda confusing to do so.

We removed the restriction, but still warn against it due to readability issues.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: