A CSS rule contains color: black; color: var(--brand); and --brand holds the value 12px. The text renders in the color inherited from its parent, not black. Why does the earlier declaration not win?

## Two different moments where CSS can reject a value CSS normally protects you with parse-time validation. In `color: black; color: qwerty;` the second declaration is garbage the parser recognises as garbage, so it is thrown away immediately and never enters the cascade; `black` applies. Authors lean on this constantly — it is the basis of the old "declare a fallback first, then the fancy value" pattern. `var()` breaks that model, deliberately. At parse time the browser has no idea what `--brand` contains: custom property values are stored as token streams and are not validated against any grammar. So the specification says a declaration containing `var()` is **assumed valid at parse time**. It enters the cascade like anything else, and here it wins — same selector, same specificity, later in source order. `color: black` is discarded at that moment and is not recoverable. The real check happens later, when the browser computes the element's styles and performs substitution. Now it has `color: 12px`, which is not a `<color>`. The declaration is **invalid at computed-value time** (often abbreviated IACVT). ## What IACVT actually does The rule is precise and worth memorising: the property computes to the same thing it would if you had written `unset`. - For an **inherited** property such as `color`, `font-size` or `visibility`, that means the **inherited value** from the parent. - For a **non-inherited** property such as `padding`, `background-color` or `border-width`, that means the property's **initial value** — `0`, `transparent`, `medium` and so on. That is why the symptom in the question is so confusing: the text takes the parent's colour, a value that appears nowhere in the rule you are staring at. If the same mistake had hit `padding`, you would have got `0` instead, not the earlier `padding` declaration. ```css :root { --brand: 12px; } /* a length, by mistake */ p { color: black; color: var(--brand); /* wins the cascade, then becomes IACVT */ } /* computed color = inherited color, not black */ .box { padding: 8px; padding: var(--brand-pad, 4px); /* if --brand-pad holds "red": IACVT -> 0 */ } ``` ## Why the var() fallback does not save you The fallback in `var(--brand, red)` fires on exactly one condition: the custom property is **missing** on that element — never declared, or reset to the guaranteed-invalid value. If `--brand` is defined and simply holds the wrong kind of value, substitution goes ahead with the wrong value, and IACVT follows. The fallback protects against absence, not against wrongness. This trips up people who add fallbacks everywhere expecting them to act as type guards. ## Ways the wrong value gets in In a real codebase the usual causes are mundane: - A unitless number stored where a length is expected: `--gap: 10`, consumed as `padding: var(--gap)`. - A token that carries a unit and gets used where a number is expected, or vice versa. - A property intended for one type reused for another — a spacing token pushed into `color`. - An empty custom property: `--x: ;` is a valid declaration holding an empty value, which substitutes to nothing and usually leaves the declaration invalid. - A value set from outside the stylesheet that arrives as a string not matching the target property's grammar. ## How to make the failure safe The strongest fix is to give the property a type, by registering it with `@property`. A registered property has a declared `syntax` and an `initial-value`, so a value that does not match is rejected and the property uses its initial value (or the inherited value, when it inherits) rather than collapsing the consuming declaration to `unset`: ```css @property --brand { syntax: "<color>"; inherits: true; initial-value: black; } ``` Now assigning `12px` to `--brand` is caught at the source: consumers keep seeing a real colour. Without registration you are relying on discipline — consistent units in tokens, one property per value type, and never reusing a token across incompatible grammars. ## Debugging it The tell is that the computed value in devtools matches neither declaration in the rule. Inspect the element's computed styles, then look up what the custom property actually resolves to on **that** element rather than on the element where you think you declared it — inheritance means the value may come from an ancestor you were not looking at. Once you see the resolved token stream, the mismatch is usually obvious. And remember that reordering declarations will not help: the `var()` declaration wins the cascade whatever order you put it in, as long as it is not outranked.