Sass Variables vs CSS Variables
Unanswered
Asian black bear posted this in #help-forum
Asian black bearOP
I'm having a hard time understanding the intent of this specific paragraph in the docs:
The wording sounds very definitive. Like we should not be using CSS variables. We currently have a number of them hooked up and they are working, but I want to make sure we aren't setting ourselves up for failure because of some SSR edge case we'll run into later or something.
The other way I'm reading it ( based on context from the previous 3 paragraphs) is that it's simply suggesting using Sass variables if you need compilation for IE11 support ([since CSS vars are not supported there](https://caniuse.com/css-variables)):
Could someone tell me the true intent of this line about CSS/Sass variables?
CSS variables are not compiled because it is not possible to safely do so. If you must use variables, consider using something like Sass variables which are compiled away by Sass.
https://nextjs.org/docs/pages/building-your-application/configuring/post-css#default-behavior
The wording sounds very definitive. Like we should not be using CSS variables. We currently have a number of them hooked up and they are working, but I want to make sure we aren't setting ourselves up for failure because of some SSR edge case we'll run into later or something.
The other way I'm reading it ( based on context from the previous 3 paragraphs) is that it's simply suggesting using Sass variables if you need compilation for IE11 support ([since CSS vars are not supported there](https://caniuse.com/css-variables)):
By default, CSS Grid and Custom Properties (CSS variables) are not compiled for IE11 support.
To compile CSS Grid Layout for IE11, you can place the following comment at the top of your CSS file:
/* autoprefixer grid: autoplace */
You can also enable IE11 support for CSS Grid Layout in your entire project by configuring autoprefixer with the configuration shown below (collapsed). See "Customizing Plugins" below for more information.
CSS variables are not compiled because it is not possible to safely do so. If you must use variables, consider using something like Sass variables which are compiled away by Sass.
https://nextjs.org/docs/pages/building-your-application/configuring/post-css#default-behavior
Could someone tell me the true intent of this line about CSS/Sass variables?
3 Replies
That has historic reasons.
Initially, CSS didn't have a native way to declare and use variables. This limitation led to the creation of CSS preprocessors like Sass. Sass introduced variables that could be used to store and reuse values throughout a stylesheet.
These variables were resolved at compile-time, meaning they were replaced with their actual values before the CSS was served to the browser.
Some years later the browser vendors realized that variables would be a great feature css so they cam up with CSS Custom Properties, also known as CSS variables.
Finally css had native variable functionality. But back then the browser support was very limited especially because Internet Explorer
To work around the missing browser support someone created a postcss plugin which compiled css variables similar how SASS did at build time.
Now that we don't have Internet Explorer anymore that step is no longer needed and NOT compiling CSS variables with post css has some great runtime advantages:
1. They can be changed dynamically using JavaScript.
2. They can be contextually changed using media queries or other CSS rules.
3. They can inherit and cascade like other CSS properties.
Next.js has still options to compile CSS variables with postcss but as it disables those advantages above and therefore it's better not to compile them
Hope that helps 🙂
Initially, CSS didn't have a native way to declare and use variables. This limitation led to the creation of CSS preprocessors like Sass. Sass introduced variables that could be used to store and reuse values throughout a stylesheet.
These variables were resolved at compile-time, meaning they were replaced with their actual values before the CSS was served to the browser.
Some years later the browser vendors realized that variables would be a great feature css so they cam up with CSS Custom Properties, also known as CSS variables.
Finally css had native variable functionality. But back then the browser support was very limited especially because Internet Explorer
To work around the missing browser support someone created a postcss plugin which compiled css variables similar how SASS did at build time.
Now that we don't have Internet Explorer anymore that step is no longer needed and NOT compiling CSS variables with post css has some great runtime advantages:
1. They can be changed dynamically using JavaScript.
2. They can be contextually changed using media queries or other CSS rules.
3. They can inherit and cascade like other CSS properties.
Next.js has still options to compile CSS variables with postcss but as it disables those advantages above and therefore it's better not to compile them
Hope that helps 🙂
Asian black bearOP
Great, thanks for the response!
So it sounds like my second interpretation of the line is the intent and NextJS has no problem with CSS variables as long as you don't need legacy browser support (i.e. IE11 support).
Not sure if this is the best place for feedback, but it may be worth making that more clear in the docs. That paragraph in particular mentions nothing about legacy support and has some strong wording about using Sass variables instead.
So it sounds like my second interpretation of the line is the intent and NextJS has no problem with CSS variables as long as you don't need legacy browser support (i.e. IE11 support).
Not sure if this is the best place for feedback, but it may be worth making that more clear in the docs. That paragraph in particular mentions nothing about legacy support and has some strong wording about using Sass variables instead.
Writing documentation and keeping it upto date is hard - maybe you could propose a better text there?
https://nextjs.org/docs/community/contribution-guide
https://nextjs.org/docs/community/contribution-guide