CSS Variables in Bricks: A Practical Setup Guide

Design systems fall apart when every Bricks class invents its own spacing and color values. One card uses 18px padding, the next uses 1.25rem, a third hard-codes 24px in the builder panel, and suddenly your homepage looks like four different sites sharing a logo. The fix is boring and reliable: put tokens in CSS variables, then reference those variables from global classes so every section stays consistent.

This guide walks through a practical setup for Bricks Builder sites that need to stay maintainable as you add service silos, blog templates, and campaign landing pages. The goal is not a perfect design-token encyclopedia on day one. The goal is a small, named set of variables that your team actually uses.

Why CSS variables beat scattered builder values

Bricks makes it easy to style elements directly. That speed is useful for prototypes and deadly for production systems. When a primary yellow appears as #faff69 in twelve places and #FAFF69 in three more, you cannot run a safe find-and-replace. Variables give you one source of truth and make intentional exceptions obvious.

Variables also travel well between the static prototype and the Bricks child theme. If your hand-authored CSS already uses :root tokens, porting into Bricks means preserving names — not inventing a second system of global class overrides.

Start with a small token set

You do not need fifty variables on day one. Ship the ones your homepage and first service page already use, then expand only when a new pattern repeats twice.

• Canvas, surface, and ink colors for backgrounds and text
• Primary accent reserved for CTAs and proof accents
• Muted text and border colors for secondary hierarchy
• Spacing scale from xs through 3xl
• Radius tokens for buttons and cards
• Font stacks for display, body, and mono

A workable starter set looks like this:

:root {
  --bg-canvas: #1c1c1c;
  --bg-surface: #171717;
  --ink: #171717;
  --text: #f5f5f5;
  --text-muted: #a3a3a3;
  --primary: #faff69;
  --border-muted: rgba(255,255,255,0.12);
  --space-xs: 0.5rem;
  --space-sm: 0.75rem;
  --space-md: 1rem;
  --space-lg: 1.5rem;
  --space-xl: 2rem;
  --space-2xl: 3rem;
  --space-3xl: 4.5rem;
  --radius-sm: 6px;
  --font-display: "Outfit", system-ui, sans-serif;
  --font-body: "Satoshi", system-ui, sans-serif;
}

Wire tokens into Bricks without fighting the builder

Add the variables in your child theme base CSS (or a dedicated tokens chunk), then use them in global classes. Prefer classes over element-level color picks when you want tokens to win. Bricks inline styles can beat stylesheet order, so teach the team: if it is a reusable pattern, it belongs on a class.

Buttons as the first proof

Buttons are the highest-signal place to enforce tokens. Primary buttons should always pull –primary for background and near-black ink for label text. Secondary buttons should share radius and padding while swapping fill and border.

.btn-primary {
  background: var(--primary);
  color: var(--ink);
  border-radius: var(--radius-sm);
  padding: var(--space-md) var(--space-xl);
  font-family: var(--font-body);
}
.btn-secondary {
  background: transparent;
  color: var(--text);
  border: 1px solid var(--border-muted);
  border-radius: var(--radius-sm);
  padding: var(--space-md) var(--space-xl);
}

Section spacing next

Once buttons are stable, move section padding to tokens. A hero, metrics band, and FAQ should not invent unique vertical rhythm. Use –space-3xl for major sections and –space-2xl for denser editorial blocks. If one section needs more air, create a named modifier like .section–airy rather than typing 96px into the panel.

.section {
  padding-block: var(--space-3xl);
}
.section--compact {
  padding-block: var(--space-2xl);
}

Naming conventions that survive growth

Name tokens by role, not by the first component that needed them. –yellow-button is a trap; –primary communicates intent. Prefer –text-muted over –gray-3. When marketing asks for a seasonal accent, add –accent-campaign and leave –primary alone so CTAs stay consistent.

If a value appears more than twice, it belongs in a variable.

House rule

Document the reservation rule in your design system notes: primary is for CTAs and proof accents only. Using the yellow as decoration on icons, underlines, and random highlights kills hierarchy and trains users to ignore the real call to action.

Breakpoints, fluid type, and what not to tokenize yet

Teams often ask whether breakpoints should be CSS variables. You can store them as custom properties for documentation, but media queries still need literal values in most browsers unless you adopt a preprocessor or newer range syntax carefully. Keep breakpoint decisions in one CSS file and reference the same numbers in Bricks responsive settings.

Fluid type is useful, but do not invent a twelve-step modular scale before your content hierarchy is clear. Start with display, H2, H3, body, and small. Promote a size to a token only after it appears in multiple templates.

Common gotchas on Bricks projects

• Element-level colors silently override class tokens — audit with DevTools before blaming the stylesheet
• Mixing rem and px in the same scale makes spacing feel random on zoom
• Duplicating tokens in Bricks Variables UI and child CSS without a sync process creates drift
• Global classes with giant _cssCustom blobs re-paste entire stylesheets — prefer chunked CSS keyed to BEM names

When you port from a static prototype, keep the original semantic class names (hero, service-card, faq__trigger). The CSS chunks already target those names. Renaming for cleaner Bricks labels forces a second migration.

A simple rollout plan

Week one: define the starter :root set and convert buttons, links, and section padding. Week two: convert cards, form fields, and footer. Week three: sweep for hard-coded hex in global classes and delete dead duplicates. Each week, visual-diff a couple of key pages so token swaps do not silently shift layout.

Done well, CSS variables make Bricks feel like a design system instead of a pile of styled boxes. You still get builder speed — you just stop paying for it with inconsistency every time the brand yellow needs a tweak.