Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Comments in --var not removed #75

Closed
eugenesvk opened this issue Apr 25, 2023 · 4 comments
Closed

Comments in --var not removed #75

eugenesvk opened this issue Apr 25, 2023 · 4 comments

Comments

@eugenesvk
Copy link

eugenesvk commented Apr 25, 2023

upd: I see that it's a common sass misfeature sass/sass#2770
so unlikely to expect grass to deviate

I'm using grass via zola SSG and I've noticed that comments in --var are not stripped from the output, thus breaking my ability to add comments with explanations for colors

// file.sass
:root.light
  --var:  	oklch(.87 0   90)	// comment not removed in the output

I see that CSS variables should include everything, notably comments https://github.com/connorskees/grass/pull/67 on #19, which is maybe related and implies this is intentional, but I don't understand the reason behind that, the comments like these aren't meant to be included
Although that example has foo: //; a semicolon, while the one I'm using is the cleaner sass version, so maybe this explains it?

(although some online dart sass tools strip the comments properly fro this format)

@connorskees
Copy link
Owner

Yes, this isn't super intuitive behavior, but grass may not deviate from other implementations here.

Being a superset of CSS, Sass must allow (almost) any value -- including what look like Sass comments -- to be part of custom properties. Although this is potentially surprising behavior, there are some users that rely on accessing such variables from JavaScript, and so Sass must parse custom properties specially.

It seems that libsass has a bug in which silent comments are stripped from custom properties, only for the indented syntax, which is why the online tools would not have this behavior. Ruby Sass and dart-sass have never had this bug.

You should be able to work around this by using loud comments, /* ... */, which will still be emitted but will be ignored by CSS.

@eugenesvk
Copy link
Author

Thanks for the detailed explanation, yeah, found it out and am using the /**/ now (though this article I read says that Ruby sass also had this feature https://sass-lang.com/documentation/breaking-changes/css-vars)

By the way, what do you think about having a flag/option to enable the more convenient parsing?

@connorskees
Copy link
Owner

I've thought about a flag like "libsass quirks mode" that makes parsing more similar to libsass, but I wouldn't want to deal with the added maintenance burden of this. I would be hesitant to add a general flag for grass-specific parsing changes for similar reasons, in addition to compatibility concerns with other Sass implementations.

@eugenesvk
Copy link
Author

Found a trick to use proper comments in the output, #{interpolation} in the property name disables this quirk and uses regular Sass parsing behavior

sass/sass#2586 (comment)

:root.light
  #{--var}:	oklch(.87 0   90)	// comment are removed in the output!!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants