Design token policy

Change the system once, not hundreds of selectors.

FG UI components share one design language through reusable --fgui-* custom properties. Use semantic tokens when the value has a reusable meaning, then let components inherit the system.

Built with FG UI itself.

This page is built entirely with FG UI using the same components, layout primitives, icons and interactions available in the kit. No Bootstrap, Tailwind or external UI framework is required.

Do

Use semantic tokens

color: var(--fgui-text);
background: var(--fgui-surface);
border-color: var(--fgui-border);

Brand, status, surface, text, border, spacing, radius, shadow and z-index values should use an existing semantic token when one exists.

Avoid

Do not hard-code system meanings

color: #344c5d;
background: #ffffff;

If the value already has a reusable FG UI meaning, use the token rather than duplicating a raw value into component rules.

Theme readiness

Change the tokens, keep the components.

Use semantic tokens to theme FG UI instead of forking hundreds of selectors. Changing --fgui-primary, for example, can rebrand large parts of an interface immediately.

Try it live
Shared token changes are powerful.

Changing a shared token can affect many components. System-level token changes should be tested across the interface rather than treated as an isolated colour edit.