Option to add fallbacks

[eirikbacker]

• Custom properties can take a second argument as a fallback value
• If a browser supporting custom properties encounters a var, this overrules a preserved css property even if the custom property definition does not exists. The following code:

h1 {
  color: var(--color);
}

/* becomes */

h1 {
  color: red;
  color: var(--color);
}

..therefore results in custom property-compliant browsers getting a black h1, while non-compliant browsers gets a red h1

Adding a fallback option could solve this, ensuring a consistent fallback-experience:

h1 {
  color: var(--color);
}

/* with { preserve: true, fallback: true } should become */

h1 {
  color: red;
  color: var(--color, red);
}

[eirikbacker]

@jonathantneal I have a complete branch fixing this feature (inc. tests), but my user does not seem to have permission to push a new branch to this repository? :)

[jonathantneal]

I’m a little confused because I think the functionality you are asking for is already what this plugin. Could you describe what this plugin does and what you are asking it to do differently? Sorry for the trouble I am having understanding.

[eirikbacker]

Indeed :) sorry - might be me who haven'f figured it out too :) but, currently, transforming this:

:root {
  --color: red;
}
h1 {
  color: var(--color);
}

becomes:

:root {
  --color: red;
}
h1 {
  color: red;
  color: var(--color);
}

but, I want it to become:

:root {
  --color: red;
}
h1 {
  color: red;
  color: var(--color, red); /* Notice red is automatically added as fallback here */
}

Use case: I am creating a design system. I want the components of this system to not depend upon global custom properties (for instance --color), but I want them to both have a nice fallback, and also respect --color if it is set :)

[eirikbacker]

Maybe it is easier to see if I get permission to push the branch? :)

[pascalduez]

@eirikbacker If you want to submit a Pull Request, you'll need to fork the repo first, and push your branch to the fork, not the original repo.
See https://help.github.com/en/articles/creating-a-pull-request-from-a-fork

[jonathantneal]

Also, see the documentation to this project, which is listed when you go to open an issue.

https://github.com/postcss/postcss-custom-properties/blob/master/CONTRIBUTING.md#submitting-pull-requests

---

This plugin is only for compatibility fallbacks, so I would not want to add this kind of functionality. You should write a different plugin for this, as it might be very useful to others.

[arshaw]

@eirikbacker, I needed this same exact functionality. My project fullcalendar has a "common" package that would have ideally been able to define a set of css variables, and then a set of plugins that consume these variables. It seemed impossible to make thes variables available cross-package so I settled upon a solution similar to the one you proposed where the default value for a variable is baked into the var statement as the second param (the "fallback"). This eliminates the need to output a :root with all the variable values, which wouldn't be portable cross-package.

Anyway, here's the info to start using it. Maybe it will be useful to others:

• fork
• npm package @arshaw/postcss-custom-properties
• relevant modified code
• use the preserveWithFallback set to true