Design tokens

Everything visual in forte-ui resolves through a CSS custom property. Components never contain a hardcoded color, 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.

Color

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 color 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 colors.

Focus ring

The ring is brand-colored and still measured: the outline is --forte-color-primary-text, the ramp step the contrast harness holds to 4.5:1 for every seed, and it sits on a gap filled with the near-page -outer tone rather than on the control itself — so a solid primary button and a ghost one ring against the same known background (WCAG SC 1.4.11). The seed itself cannot promise that, which is why it is the caret and not the ring. It grows out of the control's edge while fading in, and shrinks back while fading out, on --forte-focus-ring-duration; the distance is --forte-focus-ring-travel, a travel token, so reduced motion keeps the fade and drops the movement.

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 behavior 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.