CSS var() fallback not applied when a custom property holds an invalid value type

Question

GoalI want a design-token setup where var(--token, fallback) reliably protects components, so that if a token is ever assigned a value of the wrong type (for example a length where a color is expected), the component still renders with its declared fallback color instead of losing the declaration entirely.Constraint and uncertaintyMy understanding is that the fallback in var() only applies when the custom property is unset or explicitly set to the guaranteed-invalid value. If --token is defined but holds a value invalid for the target property, the declaration becomes invalid at computed-value time and resolves to the inherited or initial value — silently, with no console error. That makes the fallback useless for the exact failure mode I care about.I am aware @property allows registering a custom property with a syntax, inherits, and initial-value, which could enforce typing and revert invalid assignments to the initial value. However, I am unsure how this interacts with unregistered tokens, older browsers that ignore @property, and tokens composed from multiple var() references.QuestionsIs registering every design token with @property the intended way to get predictable invalid-value handling, or is there a lighter-weight pattern?When a registered property receives an invalid assignment, does it revert to its initial-value in all cases, or only for direct assignments?How should tokens behave in browsers without @property support — is graceful degradation to untyped behavior acceptable?

Tasadduq Burney · Answer

AnswerThe fallback in var(--token, fallback) is only used when the custom property is unset (or explicitly set to the guaranteed‑invalid keywords unset, initial or inherit). If the property is defined but holds a value that is syntactically valid yet semantically wrong for the target property (e.g., --token: 16px used where a color is expected), the var() function substitutes that value, the declaration becomes invalid at computed‑value time, and the property resolves to its inherited or initial value – the fallback is never consulted.Confirmed factsThe var() fallback mechanism is defined in the CSS Cascading and Inheritance Level 4 spec and triggers only for the "guaranteed‑invalid" state of a custom property.When a custom property is registered with @property and given a syntax, inherits, and initial-value, the browser treats assignments that do not match the syntax as invalid and replaces them with the declared initial-value during value computation.Browsers that do not implement @property ignore the rule entirely and treat all custom properties as , preserving the existing untyped behavior.Steps to get predictable invalid‑value handlingRegister each design token with @property, specifying the appropriate syntax type (e.g., , ) and an initial-value that matches your desired fallback.Use the token in components as var(--token, fallback). The fallback now serves only as a safety net for the case where the token is truly unset; type mismatches are handled by the registration.If you must support browsers without @property (IE11, Safari <14), accept that tokens will remain untyped and the var() fallback will not protect against type errors. In that environment you can either:Limit token usage to values that are safe for all target properties, orProvide a build‑time polyfill or CSS‑postprocessor that strips or replaces invalid assignments.Missing diagnostic detailDo you need to support browsers that lack @property (IE11, Safari <14)? Knowing this determines whether you can rely solely on registration or must add a degradation strategy.

CSS var() fallback not applied when a custom property holds an invalid value type

Goal

Constraint and uncertainty

Questions

1 answer

Answer

Confirmed facts

Steps to get predictable invalid‑value handling

Missing diagnostic detail

Your perspective belongs here.

0 question comments