CSS Custom Properties

Declare a small design system

CSS custom properties, often called variables, store values under names beginning with two hyphens. Declaring shared colours on :root makes them available throughout the document. Use names that describe a role, such as --bg-primary for the main background and --accent for a highlight, rather than a name tied to one component.

:root {
  --bg-primary: #10131a;
  --text-primary: #f4f5f7;
  --accent: #7c5cff;
}

This is a small generic palette, not a complete page stylesheet. In the quest, identify repeated colour values and move them into a single :root block.

Use var() wherever the role appears

Read a custom property with var(--name). Use the property in any declaration that accepts that value, such as background, text colour or border. This is the core of the quiz idea: var(--accent) retrieves the value declared for --accent.

.button {
  color: var(--text-primary);
  background: var(--accent);
}

A fallback after a comma can provide a value if a property is missing or invalid: var(--accent, rebeccapurple). The fallback is a safety net; it does not replace declaring your intended theme values.

Retheme by changing one source

When many components use the same variable, changing its value in :root updates them together. This makes a dark-to-light theme adjustment faster and prevents slightly different copies of the same colour. Variables also make design intent visible: --surface-card communicates more than repeating an unexplained hex code.

Refactor with care

For the practical, search the stylesheet for repeated colours, define a small set of role-based properties in :root and replace the repeated literals with var(). Keep one-off values literal when turning them into variables would add confusion. After refactoring, check that every variable name matches exactly and that the page still has readable contrast. A variable centralises a value; it does not guarantee the value is accessible or attractive.

Do a before/after refactor you can verify

Suppose .buy-link and .contact-link both repeat the same accent colour. First inspect the current page and note its appearance. Define --colour-accent in :root, replace each repeated background value with var(--colour-accent), and save. The refactor should initially preserve appearance; changing the one variable afterward should update both controls.

Test a deliberate typo in one disposable declaration: var(--colour-acccent) references a missing property. Without a fallback, the declaration becomes invalid at computed-value time and the property uses its inherited or initial behaviour. It does not always fall back to an earlier declaration as you might expect. Inspect Computed styles to locate the problem, then restore the exact name.

Custom properties inherit and can be overridden within a component or theme selector. A declaration on .special can shadow the root value for that element/subtree. If only one area changes, inspect that cascade before adding more root declarations. var's fallback helps a missing custom property; it is not a universal validator of the resulting property's value.

Rehearse the practical's whole change

Choose three repeated palette roles in your own site, define them once, replace their repeated uses and confirm the site still looks right. Temporarily alter the accent and check every intended control changes; restore or keep the deliberate palette. Retest text/button contrast after a colour change—centralising an inaccessible colour does not fix accessibility.

Before activity 1.6, identify the :root palette, show at least one actual var use and explain one missing-name diagnosis. Your next lessons add motion and test reduced-motion behaviour on the same polished control.