Romain Menke

@fantasai It is only compatible with option 1 as currently discussed. All other options drop `@nest` blocks completely. https://github.com/w3c/csswg-drafts/issues/7834#issuecomment-1283020374

@fantasai This issues was specifically about adding relative selector syntax in `@nest` within proposal 1. This as a way to have all the benefits of relative selector syntax without all...

@tabatkins This issue was specifically about the now removed proposal 1. It was very specifically about : ```css .foo { @nest > .bar { /* & > .bar */ /*...

I think this proposal introduces several issues. A parsing switch mechanic also effects humans, code editors, ... A person needs to have seen the parsing switch to be able to...

_maybe we should split out concerns/feedback into separate issues?_ ----- @romainmenke said : > A person needs to have seen the parsing switch to be able to understand the code....

> This also means you could write the rules in a SASS compatible way. Also reading a lot of statements on Twitter that this change would allow you to copy/paste...

I think it is also important to challenge the opinions that sparked this. > selectors within nested context are incompatible with those outside of nested context, and with syntax within...

> Is this preferable? Is it more understandable? No this is, in my personal opinion, much worse. :) Which is also why I doing my best to avoid `@nest;` until...

> Nope, under this proposal [](https://drafts.csswg.org/selectors/#typedef-relative-selector), i.e. + .foo, > .foo or ~ .foo will be perfectly valid. I overlooked that, thank you for pointing that out. I wonder if...

Might be more interesting to leverage `@scope` as mentioned in the examples. https://drafts.csswg.org/css-cascade-6/#scoped-styles ```css @scope (.light-scheme) { a { color: darkmagenta; } } @scope (.dark-scheme) { a { color: plum;...