Design tokens

Everything visual in forte-ui resolves through a CSS custom property. Components never contain a hardcoded colour, size or duration — which is why re-pointing a token restyles every component at once, coherently. This page is the global token reference; the tables are generated from the shipped stylesheets at build time, so they cannot drift from what actually renders. Per-component knobs (--forte-button-*, --forte-dialog-*, …) are a separate mechanism documented on Styling components and on each component's own page.

How to override a token

Set it on :root, or on a theme scope to affect one subtree:

:root {
  --forte-radius-control: var(--forte-radius-2);
  --forte-shadow-2: 0 2px 8px oklch(0 0 0 / 0.12);
}

Your CSS always wins. The library ships every rule inside @layer forte.*, and layered rules lose to unlayered author CSS regardless of specificity — no !important needed, ever.

Two things to know before overriding:

• A typo fails silently. var(--forte-color-pannel) is not an error — the declaration simply becomes invalid at computed-value time and the element inherits instead. Check names against these tables.
• Preset-owned tokens live on :root alone. Tokens marked rewritten by presets below are what data-forte-radius and data-forte-density rewrite. Overriding one on :root moves the default, but any preset attribute on an ancestor still wins for its subtree.

Colour

The accent, secondary and gray ramps — --forte-accent-1…12, --forte-secondary-1…12, --forte-gray-1…12 — are derived from the seeds described on the Theming page, in both light and dark mode. Prefer changing the seed over overriding ramp steps: the derivation is what keeps the palette coherent and the contrast pairs certified.

Components consume the ramps through semantic aliases, which are the right level for surgical overrides — they re-derive per scope and follow light/dark automatically when you assign them a ramp step:

Surfaces, text and borders

Brand

Status

Status hues are fixed rather than seed-derived — a brand colour must not be able to make an error look reassuring. The aliases below are what components read; behind them sit fixed ramp steps (--forte-danger-2…11, --forte-success-*, --forte-warning-*, --forte-info-*) you can retune if your palette needs different alarm colours.

Focus ring

The ring is two tones that contrast with each other, so one boundary always clears 3:1 against whatever sits behind the control (WCAG SC 1.4.11) — a single accent-coloured ring cannot promise that.

Spacing

An eight-step scale on a 4px base. Components use it for all internal padding and gaps.

Typography

Radius

The numbered scale plus the three semantic radii components actually read. Prefer overriding the semantic ones — or better, a radius preset, which is the form that nests correctly.

Controls and density

Control heights, padding and the surface metrics — the group the density presets rewrite. The --forte-app-bar-h-* heights are here too: an AppBar is exactly that tall at each size, and the token exists so the layout around one — a sticky sidebar's offset, a page's scroll-padding-top — can read it.

Elevation

Motion

Durations, travels and scales. The reduced-motion behaviour is built into the tokens themselves — under the OS preference or a data-forte-motion attribute, travels collapse to 0px and scales to 1 while durations only shorten — so consuming these tokens gives you correct reduced-motion handling without writing a media query. The spring easings (--forte-ease-spring-*) are sampled damped-oscillator curves; each pairs with its matching --forte-duration-spring-*, and truncating a spring with a shorter duration looks broken.

For tooling

This same inventory ships in the package as machine-readable JSON — every token with its default, its typed registration where one exists, and every overriding selector:

import tokens from "@forte-ui/react/docs-data/tokens.json";

These tables are rendered from that file, as is anything else that needs the full token surface — theme editors, lint rules, design-tool sync.