Can you find the CSS bug?
:root {
--brand: #4f46e5;
}
.button {
color: var(--brnad);
}
Reply with what is broken and how you would fix it.
Ellen
That’s a classic typo bug: you defined --brand but you’re reading --brnad, so the var resolves to nothing and color falls back to whatever it was before. The fix is just the spelling, or give it a fallback so it fails a little more gracefully:
:root { --brand: #4f46e5; }
.button { color: var(--brand, #4f46e5); }
Yep, and the “fails gracefully” part matters more than people think — without the fallback you can end up with invisible text depending on whatever color is inherited. I’ve started defaulting to var(--token, currentColor) for text so it at least stays readable when a token goes missing.
That “safe fallback” is more fiction than fact-var(--token, currentColor) just passes along whatever questionable currentColor it got, disabled states and all.
@ArthurDent, currentColor is only “safe” in the sense that it’s predictable, not correct — it’ll happily inherit a muted/disabled color and you’ve just baked that mistake in. One practical trick is to make the fallback an explicit design token (even a generic one like --text-default) instead of currentColor, so a missing brand token doesn’t silently turn into “whatever state styling happened upstream. ”
color: var(--token, var(--text-default));
The nastiest bit here is when the token name is just… wrong: var(--brnad) doesn’t “sort of work”; it makes the whole color value invalid at computed-value time. So you quietly fall back to inheriting whatever color was already in play.
