Look at this CSS and take a guess what color our text will be. No tricks, this is the only relevant code:<\/p>\n\n\n
:root<\/span> {\n --color<\/span>: green;\n --color<\/span>: notacolor;\n color<\/span>: red;\n color<\/span>: var<\/span>(--color, blue);\n}<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\nPerhaps surprisingly, the answer is the default text color, usually black. Let\u2019s figure out why that\u2019s the case and how to write a fallback that works.<\/p>\n\n\n\n
var()<\/code> Fallbacks<\/h2>\n\n\n\nThe value blue<\/code> seems a likely candidate to be our color, doesn’t it? After all, we often call the 2nd parameter of var()<\/code> its “fallback” value. However, this type of fallback is only used in the following circumstances:<\/p>\n\n\n\n\n- The custom property isn\u2019t defined.<\/li>\n\n\n\n
- The custom property’s value is the
initial<\/code> keyword.<\/li>\n\n\n\n- The custom property is animation-tainted<\/a> and is used in an animation property.<\/li>\n<\/ul>\n\n\n\n
and<\/em>…<\/p>\n\n\n\n\n- The custom property isn\u2019t registered with
@property<\/code>.<\/li>\n<\/ul>\n\n\n\nSince a registered custom property must<\/em> be given an initial value, it\u2019ll always have a valid value and will never<\/em> use its fallback.<\/p>\n\n\n\nOur custom property is defined, not animated tainted, and its value isn\u2019t a keyword, so we can throw away blue<\/code> and keep looking.<\/p>\n\n\n\nFallback Declarations<\/h2>\n\n\n\n
Usually in CSS, we can rely on the cascade to fallback to a previous valid value, leading to a common pattern where we declare the property twice:<\/p>\n\n\n
overflow<\/span>: hidden<\/span>;\noverflow<\/span>: clip<\/span>;<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\nBrowsers that don\u2019t support the clip<\/code> keyword will discard the entire declaration and use hidden<\/code> instead.<\/p>\n\n\n\nUnfortunately, custom properties don\u2019t work like this.<\/p>\n\n\n\n
When parsing a custom property or its matching var()<\/code> function, the browser doesn\u2019t know if it\u2019s valid until it comes time to compute its value. So instead they are treated as always<\/em> valid, and any previous declarations get discarded.<\/p>\n\n\n\nIf you want to prevent a custom property from being overwritten, you\u2019ll have to mark it as important<\/a>.<\/p>\n\n\n\nThat means --color: green;<\/code> gets discarded immediately upon discovering --color: notacolor;<\/code>, and color: red;<\/code> is discarded when we get to color: var(--notacolor, blue);<\/code>.<\/p>\n\n\n\nIn the end, our CSS computes to:<\/p>\n\n\n
color<\/span>: notacolor<\/span>;<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\nUnsurprisingly, this isn\u2019t valid, and that\u2019s why we get black as our color.<\/p>\n\n\n\n