Anydocs Documents
Theme Configuration

Colors and Styles

Understand theme color overrides and the boundary of what they actually control.

Color configuration overrides semantic theme tokens. It is not an arbitrary component-level styling system. Understand the fields first, then make small deliberate changes.

Color fields shared by all built-in themes

All three built-in themes accept the shared fields `primary`, `primaryForeground`, `accent`, and `accentForeground`, but they do not consume them to the same extent. `classic-docs` and `atlas-docs` make broader use of this shared palette. In `blueprint-review`, the main color entry point today is `primary`, and the other shared fields should not be treated as equally strong visual controls.

Only `classic-docs` uses `sidebarActive` and `sidebarActiveForeground` to style active sidebar entries. `atlas-docs` and `blueprint-review` do not currently treat those two fields as a primary styling surface.

Format and validation workflow

Color values must use `#RRGGBB`. After changing them, verify at least three areas: links and emphasis in body content, active navigation states, and overall contrast around code and callout regions.

What these fields do not do

Color overrides do not enable dark mode, and they do not provide an arbitrary typography or component styling system. They only override semantic color slots exposed by the current theme.

Start with shared tokens: If you are still finding the visual direction, start with `primary` and `accent`. That is usually easier to validate than changing every field at once.
Do not assume identical color behavior across themes: Even when the field names match, the visual impact can differ between themes. After switching themes, preview again instead of assuming the same color result carries over unchanged.
← BrandingBuild From Source →