-
-
Notifications
You must be signed in to change notification settings - Fork 75
postcss-custom-properties: Enable usage of function for preserve option #778
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Hi @bjentsch 👋 What is the motivation for preserving some properties but not others? |
Hi @romainmenke ✌️ With postcss-css-variables, we used injection from the TypeScript/JS side to change the variables at runtime while still providing a fallback for older browsers that don't natively support custom properties yet. We would like to replicate this behaviour with postcss-custom-properties. When preserving some of the variables, those can then be dynamically altered by scripting during runtime, e.g. for a darkmode switch or dynamic color state transitions. |
But then why not preserve all CSS variables? Is it to minify the CSS bundle? My concern is that this plugin is intended as a fallback for browsers that have no support for CSS variables and not intended to reduce the size. Personally I preserve both the CSS variables and the fallback for projects that still need to support ancient browsers like IE. For more modern projects the plugin is disabled. |
Yes, for this specific project, we only want to preserve variables that are to be mutated by scripting later on. The other variables should be inlined. |
If the variables that should be inlined are more like constants it might be interesting to use something like design tokens : https://github.com/csstools/postcss-plugins/tree/main/plugins/postcss-design-tokens#readme (there are other plugins that do similar things) That plugin inlines final values and doesn't produce CSS variables. You can also spin of your own variant of But I don't think this feature request aligns with the current goal of the plugin, which is to polyfill custom properties in old browsers like IE. We try to keep these plugins focussed on a single use case. We have just finished removing |
Alright, thanks, I will dig into design tokens. I think we would be able to go with these, although to be honest it will add a layer of complexity for daily dev work. Up until now, we could just mix "static variables" (= design tokens) and "dynamic variables" (= custom properties which can be modified by scripting) into one variable declaration CSS file. This won't be possible with the design tokens as far as I can tell from looking at the design-tokens repo. |
Yes, that is why a fork would be interesting. I am sure there will be others with the same needs and we are happy to advice on and share your version (if you decide to build and publish it). |
Closing the PR as I don't see a chance of this getting merged, thanks for your input @romainmenke. 🤗 |
I was just about to comment here too 🤗 Out of curiosity is there anything in particular that would make it easier for you to maintain and publish a fork? We sometimes have to say no to a feature request like this, but it is always a tough choice. |
postcss-css-variables has a neat configuration option that enables devs to preserve custom properties under certain circumstances, using a function.
What it basically does is that it passes a declaration object to the configured function, which does its filtering magic and then returns a boolean indicating if the custom property should be preserved alongside the compiled output. Possible criteria for the function could be the declarations content, filename, ... you name it.
This PR is my go at implementing this functionality as an addition to only specifying
true
/false
on thepreserve
configuration option.WDYT?