Custom properties are a powerful thing—thank you for spreading the word. They are so powerful that I think “Of course we could use a post-processor plugin to turn Custom Properties into plain CSS” isn’t always the case. Of course a post-processer can deal with simple substitutions, but will it be able to deal with more complex calculations, as done for example in this pen tag stripes? And a CSS post-processor has no chance to get the values when custom properties are set from the outside—be it with JavaScript or in the mark-up, as in that pen responsive table.
You surely can check browser support, but you don’t have to in this case:
—color-text-default : black;
body {
color : black;
color : var(—color-text-default);
}
Browsers that don’t support custom properties would ignore that declaration and use the fallback. Using @supports() makes sense when setting other properties than the one in the condition, e.g.
body { background: red }
@supports (—foo: “”) { body { background: green } }
“Dumb browsers look the other way”—progressive enhancement, yay! As Jeremy Keith put it into words: “you’re free to spend all your time experimenting with the latest and greatest browser technologies, secure in the knowledge that even if they aren’t universally supported yet, that’s okay: you’ve already got your fallback in place.” I’m a fan.
Gunnar Bittersmann
Custom properties are a powerful thing—thank you for spreading the word. They are so powerful that I think “Of course we could use a post-processor plugin to turn Custom Properties into plain CSS” isn’t always the case. Of course a post-processer can deal with simple substitutions, but will it be able to deal with more complex calculations, as done for example in this pen tag stripes? And a CSS post-processor has no chance to get the values when custom properties are set from the outside—be it with JavaScript or in the mark-up, as in that pen responsive table.
You surely can check browser support, but you don’t have to in this case:
Browsers that don’t support custom properties would ignore that declaration and use the fallback. Using @supports() makes sense when setting other properties than the one in the condition, e.g.
“Dumb browsers look the other way”—progressive enhancement, yay! As Jeremy Keith put it into words: “you’re free to spend all your time experimenting with the latest and greatest browser technologies, secure in the knowledge that even if they aren’t universally supported yet, that’s okay: you’ve already got your fallback in place.” I’m a fan.