Decision — scheme and style are separate axes

Status: accepted 2026-10-10.

The decision

  • Scheme and style are separate choices. The scheme picks the colours: one of the nine palettes. The style picks the chrome's forms and lengths: plain, pro, studio or classic. A theme context has a scheme, a style, a mode and a contrast. A style of "none" means the scheme's own style, which keeps every existing selection exactly as it was.
  • Any palette takes any style. A chrome style draws from the chrome colour roles. The pro, studio and classic palettes author those roles. Every other palette derives them from its semantic pairs, through a typed and documented mapping in the design (families.chrome.derive). For example, the bar is the base surface, cards the secondary surface, and selections and the menu highlight the accent pair. A colour a palette does author always wins over the derivation. In the other direction, the plain style draws any palette through its semantic pairs, which every palette has.
  • The contrast rules still hold. The pairs keep their WCAG checks. Derived text roles sit on surfaces of the same pair, or close to them, and the design tests that text on derived chrome meets AA (4.5:1) in every hue palette, mode and contrast. The authored chrome palettes stay exact, as before.
  • Light or dark base comes from the palette. Whether the chrome sits on a light or a dark base is read from the lightness of its own chrome colour, not from the style. A light palette in a style first designed for a dark one is still drawn light.
  • Decorations and caption side sit beside the axes. They change no colour or length, so they are not part of the design context:
    • csd: the application draws its own title bar, as before;
    • ssd: the compositor decorates the window, and the application shows its menus and right-hand controls in a menu-bar row;
    • caption side right (the default) or left. On the left the order is Close, Minimize, Maximize, with Close in the corner, and the menus follow the captions.
  • Every surface takes the axes. Settings has appearance.style, appearance.decorations and appearance.caption_side. The shared theme file has style:, decorations: and caption_side:. Each application's View → Theme menu has a Style group and a Decorations group. An app's own choice persists, and older saved state loads with the defaults.

Why

Palette and style answer different questions. Tying them together meant a colour preference forced a layout, and a layout preference forced colours. As separate axes, each new palette works in every style and each new style works with every palette.

Consequences

  • Every scheme, style, mode and contrast combination compiles; the design tests compile them all.
  • A new palette needs no chrome colours to work in a chrome style. It can still author any of them where the derived colour is not the one wanted.
  • The style family's binding from each scheme to its own style remains. It is what "the scheme's own style" resolves to.
  • The style family no longer carries a base token. The light or dark base is the palette's, as described above.

This page as Markdown · This page describes the current main branch of MixOS.