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

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

From: Chris Eppstein via GitHub <sysbot+gh@w3.org>
Date: Thu, 07 Jun 2018 21:35:32 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-395572904-1528407328-sysbot+gh@w3.org>
> > Extending a single selector token, for example to create BEM-style modified classes

> Yeah, very intentionally not allowed.  It causes parsing issues...

This is one of the few features in Sass that I sincerely regret adding. It was a bad idea. We had a lot of reservations about it. But the request was so common we decided to give in to popular demand. Since then, I've seen many issues that showed me that we did fundamentally make a mistake by allowing appending to the current token(s) represented by `&`.

Tab says this is about parsing issues and as is argued above "The syntax should be nice for its users. I don't think I should have to care about whether the parser is nice or not". But I've seen sufficient issues at this point to say that those parsing issues are not independent of what authors experience as confusing. For instance: the `@extend` directive in Sass is applied after nesting is resolved. This means that extending the first token of an ident that has an appended token in a nested selector only ends up affecting outer ruleset's selector. But many authors expect it to also affect the child selectors. E.g. they expect `.foo { color: red; &__bar { color: blue }} .inherits { @extend .foo; }` to produce `.foo, .inherits` and `.foo__bar, .inherits__bar`, but `.inherits__bar` is not produced by that code. If we had adhered to the token boundary rule this would not be a problem authors.

> If there really was a big usability benefit from being able to omit the `&` I'd be more willing to consider the tradeoffs, but it's a single character to type, and it makes things less ambiguous anyway. I don't think any exceptions here are worth their weight.

I agree, @tabatkins.

> In Tab's proposal it would be cyan text on blue.

Tab got this right. Sass's behavior in this context was defined very early on and the output was not well considered and mostly just that way because the implementation was easier to write. The correct output for Sass should have been: 

body { 
  color: indigo;
* body { 
  color: cyan;
  background-color: red; 
body { 
  background-color: blue;  

instead of introducing a change to the author's document order.

If this spec gets traction, I will recommend that we change Sass: Deprecate the current capability by first disallowing any trailing declarations after nesting and then matching this spec's behavior in a future release.

> Allowing the & anywhere in the selector.

As stated, the parsing lookahead is bad for browsers. This is a place where preprocessors can still add value. There's no reason Sass can't output `@nest` for a selector that contains `&` that isn't the leading token, once Sass can reliably target browsers with this capability in its output (or via a browserlist query, etc). PostCSS can do this too.

GitHub Notification of comment by chriseppstein
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2701#issuecomment-395572904 using your GitHub account
Received on Thursday, 7 June 2018 21:35:39 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:26:50 UTC