CSS custom properties: share tokens without losing fallbacks

How the rule works

A receipt surface has one border color across summary cards and form fields. Scope the token to that surface so another product section can use a different palette without a global collision. The fallback keeps the border visible if the token is absent, but it does not rescue a value that is present yet invalid for the destination property. A token that changes color may affect contrast in every component that reads it. Keep state colors paired with their backgrounds, document what owns each token, and check the computed value when a component looks unexpectedly transparent.

.receipt-surface { --receipt-border: #b7c4d1; }
.receipt-surface .receipt-card {
  border: 1px solid var(--receipt-border, #8b9bad);
  padding: 1.25rem;
}

Cost and verification

The browser substitutes the token during style calculation; no script is required. Shared tokens reduce duplicated literals, though a large unscoped token system can make simple changes harder to trace. The fallback in this sample is an alternate border color, not a full theme. Test a card inside and outside the token scope, then inspect dark and forced-color environments. A custom property does not automatically type-check like a standard property unless explicitly registered.

Common Mistakes

• Do not assume var() fallback applies after an invalid substituted value.
• Do not put every token on the document root without an owner.
• Do not change foreground colors without reviewing their paired surfaces.

Connected lessons

• CSS Foundations
• CSS cascade layers: set precedence before selectors grow
• CSS color and contrast: pair text with its real surface
• CSS dark mode and forced colors: honor distinct user settings

Extend this decision

• CSS @property: type a custom value and control inheritance

Related component decisions

• CSS :host: make a component variant an explicit host contract