Info CSS variable used with no fallback value
Why var(--name, fallback) is safer than var(--name) alone, and what happens when a custom property is undefined.
The validator flags a var(--custom-property) call with no second argument — the fallback value used if the custom property isn't defined at that point in the cascade.
Example
/* No fallback — invalid if --brand-color isn't set */
.button { color: var(--brand-color); }
/* With a fallback */
.button { color: var(--brand-color, #2563eb); }Why it matters
Custom properties (CSS variables) can be undefined for reasons that have nothing to do with a typo — a component might be reused on a page that never set a theme variable, a build step might strip an unused :root block, or the variable might only be defined behind a media query that isn't active. Whenever var() resolves to nothing, the whole declaration becomes invalid at computed-value time — the property falls back to its inherited value, or its initial value if nothing is inherited, rather than simply "doing nothing." A fallback (var(--name, value)) guarantees a sane result either way, which matters most for properties where inheriting or resetting to initial would look visibly broken (colors, spacing, sizes).
Frequently asked questions
Is a fallback always necessary?
Not always — if a custom property is guaranteed to be set globally (e.g. defined once on :root and never conditionally), a fallback is just defensive redundancy. It matters most for component-level variables that a consumer might reasonably forget to set.
Can the fallback itself be another var()?
Yes — var(--a, var(--b, red)) is valid and chains fallbacks, resolving to --a if set, otherwise --b if that's set, otherwise red.