W3C home > Mailing lists > Public > public-css-archive@w3.org > July 2018

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

From: Matthew Dean via GitHub <sysbot+gh@w3.org>
Date: Mon, 16 Jul 2018 14:07:19 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-405259217-1531750028-sysbot+gh@w3.org>
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 https://github.com/w3c/csswg-drafts/issues/2701#issuecomment-405259217 using your GitHub account
Received on Monday, 16 July 2018 14:07:25 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:33 UTC