Re: [csswg-drafts] [css-nesting] request to pick up the css-nesting proposal

I worry that the use of `&` in the proposal is going to lead to a lot of confusion, since it doesn't work like Sass's / Less's `&`. So half your code may need to be flattened, and half can maybe preserve `&`. When writing in Sass or Less, how do you target which is which? The preprocessing languages don't lose all usefulness, so both of these ecosystems, if this were adopted, would have to re-invent their entire `&` syntax / usage if people want to target nested selectors as output. Which is a shame, because that would slow adoption and probably lead more to reject using this feature.

I don't have a better syntax suggestion, but I also don't see this as necessary. But, obviously as a Less contributor, I'm biased.

Most "best-practice" style-writing I've seen suggests not really nesting at all, but to use single class identifiers in a BEM-way, like:
.component {
  &--header { }
  &--body {}
  &--button {
    &:hover {} //etc
This keeps things organized and provides single class matching for the browser. I do get why adopting that form (partial class appending) would be rejected by a CSS spec, because CSS is looking to define complete selector matching, but that just points to a preprocessor still being relevant, which points to a potential conflict around `&` usage and output. I think a different syntax is needed.

GitHub Notification of comment by matthew-dean
Please view or discuss this issue at using your GitHub account

Received on Monday, 16 July 2018 14:07:25 UTC