02 — Visual Doctrine

Color Semantics


Color in IDL is semantic, not literal. Raw hex values are not permissible in component declarations or component-tier token definitions. Every color reference in a component MUST resolve to a named semantic color token. This constraint enables theme-ability, platform-appropriate color translation, and contrast-mode adaptation without modifying component declarations.

Color Token Tiers

Color tokens follow the three-tier hierarchy: Primitive tokens declare raw color values (e.g., color.blue.500 = #3B82F6). Semantic tokens assign purpose to primitive colors (e.g., color.text.interactive → color.blue.500). Component tokens scope semantic colors to a specific component (e.g., button.text.default → color.text.interactive). Components reference only component-tier color tokens.

Required Semantic Color Categories

  • color.background.* — surface and container backgrounds.
  • color.text.* — foreground text and icon colors.
  • color.border.* — stroke and divider colors.
  • color.interactive.* — interactive element states (default, hover, pressed, disabled).
  • color.status.* — feedback states (success, warning, error, info).
  • color.overlay.* — scrim, backdrop, and shadow colors.

Theme-Ability

Because components reference only semantic tokens, themes are implemented by re-mapping semantic tokens to different primitive values — the component declarations are unchanged. A dark theme remaps color.background.surface from a light primitive to a dark primitive. Every component that references that semantic token adopts the new value at compile time without modification.