Re: [csswg-drafts] [css-nesting-1] Syntax Invites Errors (#7834)

@vrugtehagel thanks for your reply.

---

> For 1, neither does e.g. @layer, or JavaScript's await keyword. Some feature exist just to improve developer experience and language ergonomics, and this is one of those features.

Agreed. I'm not arguing against quality-of-life features.

> 3, 4 and 6 - yes, but nesting is a new construct and so this is unavoidable. The amount of complexity added is something we can try to minimize, but it's not something we can completely take away.

Also agreed. Nonetheless this seems like a change in the _spirit_ of CSS. Up to this point all CSS specs have treated `CSSRule`s as leafs because the mark a switch in syntax/context. I think there is merit in keeping that property.

> 5 - yes, but this is irrelevant. IDEs and other tools adapt to the language, not the other way around.

I wouldn't call something that requires a community-wide effort to accomplish irrelevant. This will require a large amount of updating and reviewing of tooling to prevent a myriad of subtle bugs. And it will require educating the entire community on how to update their tooling so they don't have subtly broken setups.

> 2 seems pretty clear to me - it has been shown time and time again that nesting is useful for maintainability of stylesheets. It is one of the main features of a CSS preprocessor. Nesting makes CSS easier to write, read, and understand. The benefit of introducing it to CSS is, of course, not needing preprocessors to do this work. An additional benefit is that stylesheets get smaller (because the selectors are shorter than if they were all written out). All together, there is no doubt about whether or not developers want nesting and what problems it would be solving.

See below

 ---

To be clear, the way I understand your reply:

* What are we trying to solve here?
  1. _Nesting allows us to show, with syntax, that these rules belong together and form a meaningful group_
  2. _Additionally, it removes the need to repeat ourselves; [...]_
  3. _The benefit of introducing it to CSS is, of course, not needing preprocessors to do this work._
  4. _An additional benefit is that stylesheets get smaller (because the selectors are shorter than if they were all written out)._

My main takeaways from this are:

1. _less repetition in selectors:_ This is largely addressed by `:is` and `:where`. `@custom-selector` or similar could also help with compound selectors. These  solutions, i would argue, introduce way less complexity.
2. _grouping of code which share a selector:_ This is a nice but complicated thing to have. eg. not all rules fit neatly in one _or_ another other group. So just as a _code grouping_ tool nesting is not much better than using separate files.
3. _no preprocessors:_  I think it is safe to say that in the coming decade or more everyone will still be using preprocessors. Be it to minimize their code or polyfill a recent feature. Though a world without preprocessors would be nice, CSS is just not in a place where that is possible. I also believe it is fine for some QoL features to be preprocessor-only. This is why SCSS and variants are useful and popular.
4. _smaller size of stylesheets:_ The impact on the total amount of transferred bytes would be marginal. CSS selectors are highly compressible. Also remember nesting introduces many bytes of indentation, so I doubt that would even be true for uncompressed stylesheets.


-- 
GitHub Notification of comment by fd
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7834#issuecomment-1284066503 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 19 October 2022 14:00:42 UTC