The case for CSS variables is interesting. I'm still trying to figure out the best way to integrate them with a CSS framework I created, called Bulma: https://bulma.io/
There's a few ways to combine Sass variables and CSS variables:
- make all Sass variables available as CSS variables as well, so $primary will also exist as --primary
- assign a CSS variable to a Sass one: $primary: var(--red)
- assign a Sass variable that was defined as a CSS one: $red: var(--red) and then $primary: $red
Color functions are one aspect that isn't well supported yet by CSS only.
There's also a more "philosophical" question: why offload the variable resolution to the client side when it can be done at compilation time? If you're not gonna update a variable's value at runtime, it doesn't really need to be available as a CSS variable.
It's like single page apps that always render the same content, and are better off rendered once on the server side and delivered as static HTML, instead of being rendered thousands of times by each client.
But to be fair, CSS variables have other benefits, like creating color variations very quickly:
Even with CSS variables, Sass still has a lot of benefits listed by other commenters here, like reusable mixins and nesting. And one of my favourites: @extend!
> why offload the variable resolution to the client side when it can be done at compilation time?
Imagine I have a property that I need to change depending on screen resolution in order to make a responsive layout.
In my CSS rule I specify it to have a fallback default and to take a CSS variable that over-rides it.
Elsewhere in my CSS I define the CSS variable with a media query.
The CSS rule is quite clear in that it shows that something changes or can change.
In the olden days I would be declaring the CSS rule twice. Once for the default and once inside the media query.
With the old fashioned approach it would not be clear looking at the CSS rule that it had an over-ride somewhere else in a media query.
By using the CSS variable with a fallback in just the one rule I know that something in the rule changes. I can easily find the CSS variable, regardless of how it has been scoped to see what makes it get set. Since I know the convention for most of the CSS in the stylesheet, e.g. mobile first, I can guess that the variable is for the desktop setting.
The advantage is that I have code that I can hand on to the next guy and feel happy that even if they are not yet up to speed on CSS variables they will be able to easily work out what is going on with individual rules.
There is no point in Sass variables now, they are defunct. All of the functionality is superseded and there is no point learning two ways to achieve the same task when you can just master one. This trumps any 'compilation' speed ups, resolving variables is something that does not slow page load times.
The only use case for not using CSS variables is if you have to support people using extremely old browser.
>why offload the variable resolution to the client side when it can be done at compilation time?
So I can use Stylus to override one CSS variable and change the appearance, instead of having to save the website's entire css file, find all rules set to the "variable value" (aka a particular font stack), and redefine every rule to use my personal font stack.
There's a few ways to combine Sass variables and CSS variables:
Color functions are one aspect that isn't well supported yet by CSS only.There's also a more "philosophical" question: why offload the variable resolution to the client side when it can be done at compilation time? If you're not gonna update a variable's value at runtime, it doesn't really need to be available as a CSS variable.
It's like single page apps that always render the same content, and are better off rendered once on the server side and delivered as static HTML, instead of being rendered thousands of times by each client.
But to be fair, CSS variables have other benefits, like creating color variations very quickly:
Even with CSS variables, Sass still has a lot of benefits listed by other commenters here, like reusable mixins and nesting. And one of my favourites: @extend!