[culi]

I don't really get how tbh. Isn't Option 3 the exact same thing as Sass except the "&" is required in a few more places than it is in Sass? It's also optional in Sass so I already write that way (always using the "&") personally

[notpushkin]

Most of the time, yeah, but there's a corner case (example C from the article):

    a:hover {
      color: hotpink;
      :is(aside) & {
        color: red;
      }
    }

Here, you can't just use `aside &` as this starts with a letter and will confuse the parser. Hence, wrapping with `:is()` is requires.

[culi]

Tbh, if this sort of "nesting" is possible in Sass, I don't think I've ever used it...

Is it really necessary to support? I'd be cool with just simple nesting logic

[notpushkin]

It is definitely possible, just with a more complicated (and slow) parser than what browsers use now – there's been some discussion in this thread.

As for whether it's necessary – eh, it's neat and might be useful sometimes but it's not a big deal I think. Personally, I remember a couple instances when I needed to override a few properties depending on context and it would be helpful, but `&:hover` is so much more useful.

[culi]

Right and now that we have (or will, soon enough) `:has`, I really don't think it's worth mucking up the potentially very simple and sweet nesting syntax to support something that's probably usually a bad practice anyways (though obviously I'm speaking from a place of little experience using this)

[wnevets]

I never use & when I am only nesting. So when I am skimming code quickly and I see an & I immediately know there is something else happening besides a nesting, for example &:hover.

This is probably something I can unlearn but until then it is very jarring to see & everywhere.