Repository navigation
CSS custom properties are not polyfilled #7185
Description
Is this a bug report?
Yes
I have CSS variables (custom properties) in my CSS, which are not supported by IE. The CRA docs state "Support for new CSS features like the all property, break properties, custom properties, and media query ranges are automatically polyfilled to add support for older browsers." However, they are not polyfilled when they are imported from another file.
Steps to reproduce
// A.css
:root {
--test: #fff;
}// B.css
@import 'A.css'
body {
color: var(--test)
}Expected Behavior
The built CSS file should have the CSS variables processed out and replace the var(--) calls with the proper values
Actual Behavior
The autoprefixer works as expected, adding vendor prefixes and such, and changing the browserslist settings do alter the outputted CSS in some way. However, no browserslist setting is making the custom properties be post-processed, and as such the CSS will not work on IE. It seems like the variable replacement is happening before the concatenation from imports, and so it doesn't find the property definition from other files.
Note that I also deleted node_modules and package-lock and the issue persists.
Activity
jeromeraffin commentedon Jun 19, 2019
Same problem, in the webpack config the
postcss-preset-envis used at stage 3:So I guess it should process and polyfill the custom properties (https://preset-env.cssdb.org/features#custom-properties)?
Or does the postcss custom properties plugin has to be added to the config in order to work? (https://github.com/postcss/postcss-custom-properties/blob/master/INSTALL.md#webpack).
hiramhibbard commentedon Jul 16, 2019
I’m seeing this same issue.
chce commentedon Jul 17, 2019
Also seeing this issue.
jeromeraffin commentedon Jul 17, 2019
I tried to use the PostCSS plugin with craco because I don't want to eject the config of CRA but it did not give anything good, still have the same issue, is anyone has a solution?
jakke-korpelainen commentedon Aug 6, 2019
Same issue here. Wouldn't want to eject or add deps by using 3rd party overrides.
mrmckeb commentedon Aug 7, 2019
Unfortunately, there's no bulletproof way to polyfill these... and adding this could introduce issues.
I personally feel that you shouldn't use this feature unless you're only targeting browsers that support it.
hiramhibbard commentedon Aug 7, 2019
@mrmckeb but isn't that what https://www.npmjs.com/package/postcss-css-variables is meant to do? The issue isn't whether or not a pollyfill can be bulletproof, but that CRA doesn't seem to be applying this package properly when building.
ivanmccarthy commentedon Aug 7, 2019
If this is the case, then I feel like it should be clearly stated in the documentation. The current docs read as if these polyfills are 100% supported.
mrmckeb commentedon Aug 8, 2019
@ifmcrthy, can you point me to that part of the docs?
@hiramhibbard - adding this would actually introduce issues IMO. The problem is that it does not and cannot support scope - which is a huge part of CSS variables (custom properties).
To be clear, this is not a polyfill, but a static transform that happens at build time. This feature cannot be polyfilled, and it's very sad to me as I think it's an amazing feature.
This is the section I'm referring to - https://www.npmjs.com/package/postcss-css-variables#caveats.
I've tried to use this myself in production and we ended up having to educate developers on the caveats of the polyfill, to the point where we were just using it as a dumbed-down Sass variable.
chce commentedon Aug 8, 2019
@mrmckeb https://facebook.github.io/create-react-app/docs/post-processing-css
"Support for new CSS features like the all property, break properties, custom properties, and media query ranges are automatically polyfilled to add support for older browsers."
As for the caveat, it only refers to setting the value of the CSS variable outside :root, but we want to be able to refer to a CSS variable outside of :root, which should definitely be 100% possible in postcss-css-variables.
I don't agree that this is just a dumbed down Sass-variable and that argument misses the point IMO. I'm trying to get this transformation(once it correctly transforms the CSS variables) to work in collaboration with CSS ponyfill(https://www.npmjs.com/package/css-vars-ponyfill) to deal with changing the variables at runtime.
mrmckeb commentedon Aug 8, 2019
Tnanks @chce, I'll ask the team now why that's listed but not supported. We might need to update the docs.
My point is this. Imagine you build
Button, a reusable component. It has styles like this:Now, if
--button-backgroundis set in root, no problem.If you then pass it into a component that does this (in a separate file):
That would work in Chrome perfectly. In any modern browser, that works. It's one of the core features of CSS Custom Properties.
In our app, it would completely fail. Which would be very confusing for developers...
13 remaining items
jzhen1603 commentedon Nov 6, 2019
adding the plugin "postcss-easy-import" worked for me!
RoroTitiFR commentedon Dec 27, 2019
I second all that have been said, I encounter this specific issue as well.
lodybo commentedon Feb 7, 2020
@jzhen1603 Did you have to eject before adding that plugin? It doesn't work for me at the moment. We were also counting on having IE11 support for custom properties defined in
:rootand used in our project with@import, but no dice.jzhen1603 commentedon Feb 7, 2020
@lodybo , I am not sure what you mean by eject. What I did is that I added the plugin in package.json, put it in my webpack like below and did a rebuild:
plugins: () => [ require('postcss-easy-import'), require('postcss-preset-env')({ stage: 3, }), ...lodybo commentedon Feb 13, 2020
@jzhen1603 I meant to ask if you ejected out of CRA to customize the webpack configuration? Normally the webpack config is abstracted away by CRA. I was curious how you configured it to work.
C-Higgins commentedon Dec 15, 2025
Closing this because the project is dead and I don't want it in my open issues anymore