Styles

Use the surface hierarchy deliberately: Panel is a top-level page region; Settings section groups preferences inside a dialog or settings surface; Control card groups application controls or a coherent specimen; Subsection divides a card internally; specialized groups such as Category group live below that level. Density changes space inside components; Rhythm changes local gaps between related controls; top-level page/section composition remains authored structure.

Public typography roles are Headings, Text, and Monospace. Internally these map to --font-display, --font-interface, and --font-mono; “display” and “interface” are implementation names, not additional user-facing roles.

Colors owns authored theme surfaces, semantic UI roles, and palette families. Accessibility owns user adaptations such as color-vision correction. The color-vision control shown here is only a synchronized shell mirror. Application/component CSS should consume component-facing aliases such as --input; authored source roles such as --input-shared and --input-inset describe how that alias is resolved, not a choice each component should make independently.

Component-facing semantic aliases

Authored / resolved input-surface roles

Global semantic status colors

Discrete palette families · Standard exact / colorblindness-assisted

Standard mode uses exact protected samples. Deuteranopia, Protanopia, and Tritanopia transform runtime colors at the current correction strength; sequential families preserve source positions and categorical families are reselected in the assisted display space.

Accessibility owns adaptations, not authored palette identity. The authored theme stays unchanged. Assist modes use simulation-driven daltonization: 0% is the exact authored color and 100% applies the full mode-specific correction. Components continue to request semantic color roles; the accessibility layer adapts their rendered presentation.

Choose a category by semantic purpose, then choose the smallest component anatomy that satisfies the interaction. Do not choose a component merely because it looks similar. The order below is the framework taxonomy used by Styles, AGENTS, Architecture, and new-project work.

Dialog is modal and owns a focused workflow that temporarily blocks the underlying page. Popover is anchored and non-modal; it presents contextual detail or local actions while the page remains active. Floating panel is a movable, optionally resizable workspace surface that remains open while the page stays interactive; geometry belongs to Interface state, and narrow layouts may fall back to modal presentation.

Reusable control text is deliberately quiet: buttons, chips, segmented choices, and control values use the shared Regular control-text weight; structural/control labels use Medium, and selection/primary state does not increase weight. Primary is the principal commit/advance action and should normally appear at most once per local action cluster. Secondary is an ordinary alternate/utility action. Text is deliberately low-emphasis and local. A plain Chip is passive identity/category metadata; a Status chip is passive semantic state and adds only semantic tint plus the 8 px traffic-light dot. Status-bar actions are buttons, not chips. Badge is reserved for passive qualifiers/counts such as Placeholder; authenticated identity is an interactive Account button, not a badge. Icon glyph sizes are role-based: Primary 24 px, Contextual 20 px, Compact 14 px, Traffic light 8 px.

Segmented control chooses exactly one option from a small visible set. Switch changes an immediate current/persistent state such as Show labels or Enable grid. Checkbox means include/select, especially in forms, batch operations, import/export, or “include X” payload semantics. Do not choose between switch and checkbox based on appearance alone.

Field classes describe layout anatomy, not input type. .field-control is the explicit presentation boundary for a text-like input, select, or textarea when application typography must not leak into the control; it may be combined with the layout anatomies below. Use .field-inline for compact label/control pairs, .field-stack for label above a full-width input/select with optional supporting text, and .field-row for dense label/control rows inside compact cards. Search is simply an input type inside the appropriate field anatomy. Sliders keep their dedicated label + track + value triplet.

Composition arranges primitives; it does not redefine their semantics. .control-group gives heterogeneous switch/field/slider rows one shared label lane; its label width and typography are controlled by the global --control-group-label-* tokens and may be overridden on one group. Compound rows wrap by logical control group: label + switch, label + slider + value, and label + select stay atomic. Components that can be narrow inside a wide page respond to their own container width. When a control-aligned label becomes stacked, return it to normal in-flow field anatomy.

Choose by data shape: Readout is one compact scalar summary; Value list is several key/value metadata pairs; Data table is comparable records or measurements with row/column semantics; Visualization host is a graphical data viewport. Semantic categorical state belongs in a Status chip instead of any of these.

These are the standard filled icon names retained by the framework. Semantic status glyphs use their global status colors here. The two-pip die is a local SVG derived from the filled casino die silhouette so the pair reads as one family.

Token ownership follows the same hierarchy: Density modifies component padding/height, Rhythm modifies local gaps, fixed anatomy tokens define invariant component relationships, and structural tokens compose top-level surfaces. Prefer the highest-level semantic token that matches the job.

Density

Rhythm

Fixed component anatomy

Structural layout