[csswg-drafts] [css-nesting] Conflicts in proposal with Sass/Less

matthew-dean has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-nesting] Conflicts in proposal with Sass/Less ==
_Note: I originally posted this on another thread, and [was asked](https://github.com/w3c/csswg-drafts/issues/2701#issuecomment-405327686) to re-post as a new issue._

---

I worry that the use of & in the CSS nesting 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 (native CSS nesting) 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:

```less
.component {
  &--header { }
  &--body {}
  &--button {
    &:hover {} //etc
  }
}
```
This keeps things organized and provides single class matching for the browser. But this isn't the way the nesting proposal works. 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.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2937 using your GitHub account

Received on Wednesday, 18 July 2018 14:40:30 UTC