Bits of .NET

🎨 The CSS Variable That Kept Reverting to a Value Nobody Set Anymore

A CSS custom property (`–my-variable`) that’s supposed to be controlled dynamically (via JavaScript, or overridden in a more specific selector) can silently fall back to its declared default value inside a `var()` function – not because the override failed, but because the custom property was never actually successfully set in the first place, often due to a typo in the property name or the override being applied to the wrong element in the DOM tree.

🔎 The Problem

.card {
  background-color: var(--card-bg, white);  /* white is the FALLBACK */
}

document.querySelector(".card").style.setProperty("--card-bh", "#f0f0f0");
// Typo: --card-bh instead of --card-bg

// The custom property --card-bg was never actually set by this line -
// a completely DIFFERENT, never-referenced property named --card-bh
// was created instead. CSS silently falls back to the declared default
// (white) inside var(--card-bg, white), with no error anywhere - a
// misspelled custom property name simply does nothing, rather than
// failing loudly the way a typo in a JavaScript variable name would.

✅ Fix: Verify the Property Name Is Actually Being Set

• `getComputedStyle(element).getPropertyValue(‘–card-bg’)` in the browser console directly confirms what value (if any) is actually set for a specific custom property on a specific element – the fastest way to confirm whether the property itself has the expected value, independent of whatever styles are supposedly reading it.
• Browser DevTools’ Elements/Inspector panel, specifically the Computed styles tab, lists every custom property currently in effect on a selected element (including inherited ones) – useful for confirming both that a property is set AND which element in the DOM tree it’s actually set on, since custom properties inherit down through descendants unless explicitly reset.
• Choosing consistent, deliberately verbose custom property names (avoiding easily-confused near-duplicates within the same codebase) reduces how likely a typo like this is to happen in the first place – a linter or a build-time CSS custom property validation step can also catch a reference to a property name that’s never defined anywhere in the stylesheet.

⚠️ Why CSS’s Silent Failure Here Is Genuinely Different From JavaScript’s

• A typo in a JavaScript variable name usually throws a `ReferenceError` immediately – a typo in a CSS custom property name does nothing of the sort, since an unrecognized or empty custom property is valid CSS by design (it simply computes to its “guaranteed-invalid value,” which triggers `var()`’s fallback), and that design choice is exactly what makes this class of typo silent instead of loud.
• This is worth checking specifically whenever a custom property that’s set via JavaScript never seems to have any visible effect – confirming the exact property name being set matches, character for character, the property name actually referenced inside `var()` in the CSS.