How custom properties enable dynamic theming

WHAT THIS TESTS This checks whether you understand custom properties as runtime, cascading values, and can use them to centralize theming instead of scattering colors across components. It separates people who only know Sass variables from those who grasp live CSS variables.

A GOOD ANSWER COVERS CSS custom properties are declared with a leading double dash and read with var(). Unlike Sass variables, they exist in the browser at runtime, participate in the cascade, and inherit down the tree, so redefining one on an ancestor instantly updates every descendant that consumes it. For scalable theming, define semantic tokens on :root, like a background, surface, text, and accent color. Components reference only these tokens via var(), never raw hex values. To theme, override the same token names under a scope: a data-theme attribute on html, a class, or a prefers-color-scheme media query. Because resolution is live, toggling the attribute reskins the whole UI with zero recompilation and no JavaScript beyond flipping the attribute.

COMMON WRONG ANSWERS Using Sass variables for themes, which resolve at build time and cannot switch at runtime. Hardcoding colors inside each component, defeating central control. Defining theme overrides on every element instead of one scope. Forgetting to provide fallbacks for older contexts.

LIKELY FOLLOW-UPS How do custom properties differ from Sass variables? How would you support system preference automatically? How do you avoid a flash of the wrong theme on load? Can custom properties be updated from JavaScript?

ONE CONCRETE EXAMPLE On :root you set --color-bg to white and --color-text to near-black; under html[data-theme=dark] you redefine --color-bg to near-black and --color-text to off-white. Every component uses var(--color-bg) and var(--color-text). Switching the data-theme attribute, or matching prefers-color-scheme dark, instantly flips the entire interface using the same component CSS.