Assigning SASS variables to CSS Variables (Custom Properties) no longer works

[bsmith-cycorp]

Given this input:

$my-var: red;

body {
  --color: $my-var;
}

node-sass 4.5.3, libsass 3.5.0.beta.2 outputs:

body {
  --color: red; }

and node-sass 4.8.3, libsass 3.5.2 outputs:

body {
  --color: $my-var; }

I know the version change in node-sass is much greater than the libsass one, but given that this seems like a compiling issue, it felt unlikely that it would be a problem with that package.

---

Update: it seems that

$my-var: red;

body {
  --color: #{$my-var};
}

works in both cases. Can someone confirm whether or not the first syntax was intended to be dropped? If so, it seems like it should have happened in a major release instead of a minor release. It also should probably trigger an error, instead of failing silently and outputting broken CSS.

[xzyfer]

This is intended.

[bsmith-cycorp]

At the very, very least this should be somehow mentioned in the documentation, which it doesn't seem to be. It unexpectedly broke our project on a minor-version upgrade (if a SASS variable can be assigned to a regular CSS property without #{ }, it's reasonable to assume that it could be assigned to a custom CSS property without it), and I'd bet we're not the only ones.

[xzyfer]

Please read the context before stating what is and isn't reasonable. sass/sass#1128

Additionally see why this wasn't explicitly mentioned in releases notes. https://medium.com/@xzyfer/why-node-sass-broke-your-code-and-semver-1b3e409c57b9

[bsmith-cycorp]

My dispute wasn't with the syntax itself (lord knows I'm not qualified to comment on that), but with the communication of it. It sounds, however, like the libsass team has their hands tied given the fact that Ruby sass is still considered the canonical reference, which I wasn't aware of.

I guess the real underlying issue is that CSS custom properties are mentioned nowhere in http://sass-lang.com/documentation at all, as far as I can tell - neither the supported nor the unsupported version of the syntax - even though support for them has been officially added to the compiler itself. This leads one to assume - in the absence of a special explanation - that the syntax is the same as for other CSS properties (again, I'm not arguing that requiring #{ } is unreasonable, only that it's reasonable to assume it isn't required, lacking documentation to the contrary).

I don't know how the relationship between the libsass and sass teams affects the ability to update documentation, but I think we can agree the documentation needs to reflect this API, otherwise

Relying on bugs is no different to relying on an undocumented API and violates your contract with us.

isn't a valid argument.

[xzyfer]

We can agree to disagree about the validity of the argument. It's frankly impossible for us to account for every invalid syntax or usage. As such it's impossible for us to know which of these may break as bugs are fixed. This is no different to relying on undocumented APIs. I'm sorry this has affected you adversely, but there is nothing we can do to prevent this type of breakage in the future. We will continue to do beta releases that will give you time to catch these types of breakages.

…

On Wed., 28 Mar. 2018, 10:28 am bsmith-cycorp, ***@***.***> wrote: My dispute wasn't with the syntax itself (lord knows I'm not qualified to comment on that), but with the communication of it. It sounds, however, like the libsass team has their hands tied given the fact that Ruby sass is still considered the canonical reference, which I wasn't aware of. I guess the real underlying issue is that CSS custom properties are mentioned nowhere in http://sass-lang.com/documentation at all, as far as I can tell - neither the supported nor the unsupported version of the syntax - even though support for them has been officially added to the compiler itself. This leads one to assume - in the absence of a special explanation - that the syntax is the same as for other CSS properties (again, I'm not arguing that requiring #{ } is unreasonable, only that it's reasonable to assume it isn't required, lacking documentation to the contrary). I don't know how the relationship between the libsass and sass teams affects the ability to update documentation, but I think we can agree the documentation needs to reflect this API, otherwise Relying on bugs is no different to relying on an undocumented API and violates your contract with us. isn't a valid argument. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#2621 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAjZWHobFdmc7H5MBeGgJPqG3Fq6Ls78ks5tissJgaJpZM4S9w7_> .

[xzyfer]

As for the documentation I can commit speak towards that. It is owned by the official Sass project http://github.com/sass/sass. I agree this behaviour should be documented and more easily discoverable. Please raise an issue with them. As for now I believe these changes are documented in the official Sass release notes.

…

On Wed., 28 Mar. 2018, 10:42 am Michael Mifsud, ***@***.***> wrote: We can agree to disagree about the validity of the argument. It's frankly impossible for us to account for every invalid syntax or usage. As such it's impossible for us to know which of these may break as bugs are fixed. This is no different to relying on undocumented APIs. I'm sorry this has affected you adversely, but there is nothing we can do to prevent this type of breakage in the future. We will continue to do beta releases that will give you time to catch these types of breakages. On Wed., 28 Mar. 2018, 10:28 am bsmith-cycorp, ***@***.***> wrote: > My dispute wasn't with the syntax itself (lord knows I'm not qualified to > comment on that), but with the communication of it. It sounds, however, > like the libsass team has their hands tied given the fact that Ruby sass is > still considered the canonical reference, which I wasn't aware of. > > I guess the real underlying issue is that CSS custom properties are > mentioned nowhere in http://sass-lang.com/documentation at all, as far > as I can tell - neither the supported nor the unsupported version of the > syntax - even though support for them has been officially added to the > compiler itself. This leads one to assume - in the absence of a special > explanation - that the syntax is the same as for other CSS properties > (again, I'm not arguing that requiring #{ } is unreasonable, only that > it's reasonable to assume it isn't required, lacking documentation to the > contrary). > > I don't know how the relationship between the libsass and sass teams > affects the ability to update documentation, but I think we can agree the > documentation needs to reflect this API, otherwise > > Relying on bugs is no different to relying on an undocumented API and > violates your contract with us. > > isn't a valid argument. > > — > You are receiving this because you modified the open/close state. > Reply to this email directly, view it on GitHub > <#2621 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AAjZWHobFdmc7H5MBeGgJPqG3Fq6Ls78ks5tissJgaJpZM4S9w7_> > . >

[gpgpublickey]

How i can do the invert?
Assign css variable to sass variable?

[electerious]

@chriseppstein This is not possible. CSS variables are computed during runtime while SASS will run once you compile it. You can't assign a CSS variable to a SASS variable.

[JLarky]

How i can do the invert?
Assign css variable to sass variable?

just replace

  --color: $my-var;

with

  --color: #{$my-var};

[durgapatra]

How i can do this?
Sass variable change to css variable ?
// style.scss
$primary-color: #dc4545;
div{
background : $primary-color
}
try to do this
div{
background : var(--primary-color)
}
is that possible for any way?

[xzyfer]

:root {
  --primary-color: #{$primary-color};
}

[ajfarkas]

I'm impressed it took almost a year to get to this pretty simple answer.
Could we strive to be a little less dismissive of people who are asking for help?

[JLarky]

I'm impressed it took almost a year to get to this pretty simple answer.
Could we strive to be a little less dismissive of people who are asking for help?

@ajfarkas did that help #2621 (comment) ?

[onderbakirtas]

@JLarky First, thank you for that answer, it was really helpful and what I was looking. Second, I think what @ajfarkas meant is the timespan between his question and your answer. Although xzyfer seemed to not helping and just discussing things, he was trying to explain what happens on the line of the project. This discusson has helped me a lot. Thanks again.

[crobinson42]

I know this is sidetracking the OP's question but I landed here looking for a solution to dynamically change my sass variable's variable values on the fly in the browser and here's a simple demo for anyone also looking for this: https://codepen.io/coryrobinson42/pen/jOEKqXQ

[bsmith-cycorp]

change my sass variable's on the fly in the browser

It's important to point out that you're not changing your SASS variables, you're changing your native CSS variables (which were initialized using your SASS variables). By definition it is impossible to change SASS variables after build time. What is possible is to use native CSS variables instead.