-
-
Notifications
You must be signed in to change notification settings - Fork 32.6k
Closed
Labels
breaking changeIntroduces changes that are not backward compatible.Introduces changes that are not backward compatible.priority: importantThis change can make a difference.This change can make a difference.scope: systemSpecific to @mui/system.Specific to @mui/system.type: new featureExpand the scope of the product to solve a new problem.Expand the scope of the product to solve a new problem.
Description
Supporting CSS variables would:
- Support CSS variables as theme option #12827 (comment): open up avoiding flickering of dark mode websites implemented in frameworks like Next.js or Gatsby! (This seems to be the case on the https://material-ui.com/ website itself! Eg. if you set dark mode and refresh, the page will briefly show up in light mode, and then change to dark mode, causing a flicker)
Problem demonstrated: https://joshwcomeau.com/css/css-variables-for-react-devs/#dark-mode-flash-fix
Solution with CSS variables: https://joshwcomeau.com/gatsby/dark-mode/ - [styles] Memoize makeStyle result to avoid rerendering #25018: make the switch between dark and light feel more instant. Relying on CSS cascading will always be faster than React context cascading.
Benchmark
oliviertassinari, sanohin, a-x-, lassemon, Discartyptics and 48 moremustafaabobakr, Tiberriver256 and RobertArona-x-, goto-bus-stop, ianstormtaylor, felipenmoura, Lure5134 and 10 moremustafaabobakr, rescribet, Tiberriver256, jesusvallez and RobertAronmustafaabobakr, aderchox and pharmpy-dev-123
Metadata
Metadata
Assignees
Labels
breaking changeIntroduces changes that are not backward compatible.Introduces changes that are not backward compatible.priority: importantThis change can make a difference.This change can make a difference.scope: systemSpecific to @mui/system.Specific to @mui/system.type: new featureExpand the scope of the product to solve a new problem.Expand the scope of the product to solve a new problem.
Projects
Milestone
Relationships
Development
Select code repository
Activity
oliviertassinari commentedon Sep 10, 2018
@abhisheksarka Supporting this would probably mean we support theme colors as CSS variables use case. I have nothing against supporting it, quite the opposite! The limitation right now is that we are performing color manipulation in JavaScript. I'm not sure there is any quick away around this problem. cc @mbrookes.
[-]Support for gradient directly in theme configurations[/-][+]Support CSS variables as theme option[/+]rlacorne commentedon Mar 17, 2019
It is actually very easy to provide javascript dynamism to CSS variables. And in a way that stays sort of semantic.
Say you have a color value graded on an hsla rotation, and that the dynamic part is the H parameter.
The static css would be written as such :
color: hsla(var(--graded-value), 100, 100, 1);
Now of course javascript cannot go write that in CSS (It can, but it would remove the whole purpose of variables).
What you CAN do is use the inheritance hierarchy of the cascade.
So therefore, something like
<p style="--graded-value: 92">text</p>
will actually affect the value read by the CSS variable.And javascript, especially in react, has no problem changing the value of inline styles. It is still an external declaration, as the computed use of the variable value stays in the CSS, but declared by the component as a style configuration, not a declaration.
It is often seen as wrong to declare inline styles, but in this case I see it more as a data-attribute use. This can save huge amounts of CSS, and allow a single style declaration to produce multiple results.
I have been using this method for a while to produce content with graded, dynamic values, and it is buttery smooth, as the DOM has the final word on its visual configuration, CSS just reads and apply it.
There is a caveat with dynamically rendered components not respecting the CSS variables cascade, but there are workarounds around it.
mbrookes commentedon Mar 18, 2019
@rlacorne The original request was to somehow support this as a theme option. Inline styles are a different beast.
@oliviertassinari apologies I missed the original name-check. I have no idea how we could reconcile those two concerns.
rlacorne commentedon Mar 18, 2019
It can absolutely be used for themes in the same way.
CSS has the :root {} decalaration, it's only a matter of injecting global css variables on the app css :root.
$my-color: #bada55;
:root { --my-color: #bada55 }
, only the variable version is much more stronger in its use and tweakability for redefinitions.a-x- commentedon Jul 26, 2019
We have scripts, that passing all the mui theme consts to css variables on app init
and we use them like this:
it's great!
one problem with some theme-functions. but we have no cases for them for now
our current css variable provider looks like
a-x- commentedon Jul 26, 2019
But It's harder to pass the theme.typography and pallete rule-sets. Css variables connot solve this. So we're use jss with ThemeProvider for that cases
a-x- commentedon Jul 26, 2019
some css processors allow extending (css-modules we use doesn't support it good :( out of the box)
so some mui plugin can expose rule-sets for extending like:
might be it can be useful with some post-css plugin, that enables extending
a-x- commentedon Jul 26, 2019
ok, mui@4 as I see already does something like I propose with extendable rule-sets.
But we don't want to use global selectors by default and we're gonna disable this new behaviour,
so it'll be good, if even w/o global selector we can use extendable rule-sets
mh-alahdadian commentedon Nov 28, 2019
hey guys
I had always using css variables in all my codes and for material components I always need to override colors which component setted them from theme (that is because I didn't wants to set theme and styles in my js files and I wants to do taht in my css files)
now I had do something to use css variables in material-theme like this
palette: { primary: { main: "rgba(var(--primary-color-tuple))", }, secondary: { main: "rgba(var(--secondary-color-tuple))", }, }
and I can override these two css variable where ever I want
but it would be great that you wouldn't check my string up there and then I could use `main: "var(--primary-color)" instead of using rgba function and it would be more better becoause of performance and that in this mode I could use any css color type (such as named or hex) that I want in my css variable instead of having a tuple of numbers
so is there any plan to let us using css variables easily?
sorry for bad english
51 remaining items
siriwatknp commentedon Oct 26, 2022
Hey everyone, we have the experimental APIs to generate the theme tokens to CSS variables. Please have a look at https://mui.com/material-ui/experimental-api/css-theme-variables/overview/.
I'm closing this issue!
Falven commentedon Mar 26, 2023
@siriwatknp Any reason this functionality doesn't generate the spacing, transition, etc. variables?
siriwatknp commentedon Mar 27, 2023
That'd be the next improvements.
Falven commentedon Mar 27, 2023
@siriwatknp thanks. I found the shouldSkipGeneratingVar function and override it to get some more properties generated. One problem I found is that if you're trying to override the primary and secondary colors from the variables with your own colors the elements will flash with the default color before applying yours.
siriwatknp commentedon Mar 27, 2023
Please create a new issue and provide a CodeSandbox, I can take a look at it.
peterhirn commentedon Oct 11, 2023
Setting primary/secondary palette colors via
var(--xyz)
still doesn't work and there is no mention of overriding these colors in the official documentation.Using
getComputedStyle
to set the colors seems to work, but then requires more code to honor dark/light mode toggle.Anyone got a good solution for this? 🙏
ps. telling users that the html will be larger and therefore the FCP slower is moot when everyone is using brotli/gzip anyways and the size difference is very likely insignificant.
siriwatknp commentedon Oct 12, 2023
Can you create a new issue and give some more detail about it? thanks a lot.
peterhirn commentedon Oct 12, 2023
Following these instructions https://mui.com/material-ui/experimental-api/css-theme-variables/customization/#color-schemes
produces the following error
Wrapping the values in
rgb
orrgba
doesn't seem to work, whereas using a hex literal like#ff0000
works.DGaibor commentedon Feb 7, 2024
I have the same issue.
I have this:
and when I use I get an error
siriwatknp commentedon Aug 6, 2024
@DGaibor Referencing to other CSS variables is not yet supporting because the
primary.main
is used to generate other tokens, so it has to be the format in the error.unhaten commentedon Sep 17, 2024
if i can't use vars in my ThemeProvider config in order not to set the same var that i have in hexcode for my every button - what is the point of all this and does this problem has any workaround?
I mean a MUST use hex-code only that I have, and I can't just put my var into rgb(), it just does not make sense
oliviertassinari commentedon Sep 17, 2024
@unhaten it sounds like you are looking for a different issue #37901.
This one is about using CSS variables for components styles and not hard coded values over and over again.
cbn-falias commentedon Feb 17, 2025
Got it working quite well but there might be still hidden issues or things could break with future updates:
More details
We also use TailwindCSS in our project, so I got the main idea from here: Tailwind Docs - Using CSS variables
Unfortunately MUI has some very specific color conversions where this approach doesn't always work.

Although there are no errors or warnings there can be some "hidden issues" which can be identified when searching for
NaN
in the Styles of the DevTools.Workaround 1:
Channel
propertiesIn some cases it's possible to specifically set the
Channel
property.Workaround 2: Specific components
Some colors of MUI components are calculated in code, so they basically can't work with CSS variables if the aren't computed.
See createThemeWithVars.js.
My best solution right now is to directly set them in the theme: