Type-agnostic var() fallback

concepts

1. Type-agnostic var()

   var() fallback values no longer have to match the variable's registered type. Lets authors mix typed and untyped fallbacks in the same expression.

2. Registered property rescue

   Real-world pattern: a typed registered property with a gradient fallback. Pre-136 the fallback was dropped; 136+ keeps it as long as it's syntactically valid.

3. Fallback Type Matrix

   One registered --brand: <color> property crossed against six fallback shapes — literals, gradients, calc(), even a mismatched length — with computed-style readouts.

4. Design Token Debugger

   Register a typed @property token (color, length, number) and configure it as defined, undefined, or invalid. The debugger shows the computed value for five var() expressions with type-mismatched fallbacks — gradient, rgba, keyword — proving Chrome 136's type-agnostic fallback rule live.

5. Theme Escape Hatch

   A component registers --card-bg as <color>. Design themes supply gradients and token chains as fallbacks — a type mismatch. Chrome 136's type-agnostic rule uses the gradient; pre-136 falls to the registered initial. Three theme modes with a computed-value inspector.

6. Fallback Chain

   A three-link var(--a, var(--b, var(--c, #literal))) chain where each token can be defined, undefined, or a gradient (type mismatch). Step-by-step resolution trace shows where Chrome 136's type-agnostic rule diverges from the old IACVT behaviour.

why it shipped

A var() function can provide fallback value, in case the referenced custom property does not exist (or is invalid in some other way):

references

• ChromeStatus entry