- From: Romain Menke via GitHub <sysbot+gh@w3.org>
- Date: Fri, 13 Jan 2023 21:15:20 +0000
- To: public-css-archive@w3.org
_I am a bit surprised to see this come up here :)_ I've reached out on the Sass repo to bring up exactly this difference : https://github.com/sass/sass/issues/3030#issuecomment-1073121885 I've also brought this up each time someone advertised Options 3 as a syntax option that is like Sass and would be simple to migrate. ------- > I am curious how the css-nesting polyfills in other processors have handled this. Were those polyfills designed with the current spec behavior, and has that resulted in surprising selectors for people? In `postcss-preset-env` we follow the specification with [`postcss-nesting`](https://www.npmjs.com/package/postcss-nesting). We have heuristics to match what `:is()` would match without actually using `:is()` for some common and simple patterns. For all others we use `:is()`. We've learned that people do not (yet) have a good mental model for `:is()` when complex selectors are involved. Nesting ultimately follows similar rules as `:is()`. We've had multiple bug reports because we follow the specification. Especially people coming form Sass have greater difficulty switching to "native nesting". We've spend quite a bit of time educating people about the nesting specification, `:is()` and how it differs from Sass. Those without a prior mental model seem to intuitively figure out what works and how to use nesting. -- GitHub Notification of comment by romainmenke Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8310#issuecomment-1382398449 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 13 January 2023 21:15:22 UTC