Interface TokenTheme

Remarks

Distinct from base-300, which is the faint gridline and the ramp's third fill step. This one carries structure, so it is normally the stronger of the two — set both if the grid's outline should differ from its gridlines.

Hosts name this: MUI palette.divider, VS Code panel.border / editorGroup.border / contrastBorder. Translucent by default, so it composes over whichever ground it lands on.

The seam it draws is not owned by one component. Its segments belong to several — the sheet's grid edge, the tab strip's top line and the notch the selected tab cuts into it, the scrollbar and split-resizer dividers, the status bar's rule — and they must read as a single continuous line. Any of them open-coding its own color is what lets the seam drift apart, so each paints from THIS token.

A segment rendered from inside another surface (the grid edge, drawn from within the grid) declares themeSurfaceProps('app', …) so the token resolves as chrome. That is the ordinary surface mechanism, nothing specific to borders.

Remarks

A third state token rather than a reuse of color-accent: accent is a different hue role (decoration — icon accent layers, chart series), and its -content means "text on the accent fill", which this is not. Its own pair also fixes a broken guarantee. The call site painted a muted accent (color-mix(primary 75%, base-100)) but took primary-content for text — and primary-content is MUI's contrastText, computed against pure primary.main. The mute silently invalidates it: in light that pairing measures 3.17:1, under AA, where MUI believed it was guaranteeing 4.60:1. Authoring the content per mode against the ACTUAL fill removes the computation from the loop entirely.

Remarks

Authored against a mid-luminance muted accent, which is what the default fill resolves to in both modes — so both modes want dark-ish text, and neither can be derived from the accent's own contrast pairing. A host whose primary is unusually dark or light should state this alongside the fill.

Remarks

The sibling of ['color-base-hover'] color-base-hover, and it exists for the same reason: selection is an interaction state, and base-100/200/300 is a depth ramp with no slot for one. Without it, selection was open-coded at the call site as a fixed color-mix(primary 20%, transparent) — a ratio tuned against a light surface, which collapses on a dark one (20% of a mid accent over a near-black header lands within a few units of the header itself). A per-mode token lets each mode carry a ratio that actually reads. Stated relative to --sxl-color-primary, so it still follows a host's accent.

Remarks

Must be opaque — it is applied as background-color, which replaces the surface, and there is no guarantee about what it covers.

Material gets this for free by washing the paper lighter (['color-elevated-border'] explains why that stops working in a flat host). Stating it as a token lets a host put the step back deliberately, in whichever direction its language wants — lighter on dark, darker on light — instead of inheriting Material's "up is lighter" assumption. Defaults to the paper surface, so unset changes nothing.

One step per kind, not a scale. There is deliberately no elevated-2 / elevated-3, and no "elevation" token at all — elevation is a technique, which fails the token test above. Material needs a numbered ramp because lightness is its ONLY depth signal; once depth is carried by border + shadow those compose on their own (a submenu over a menu still reads), so a second fill buys nothing. A region that wants a subtle lift rather than this fill (a titlebar) paints its own wash over whatever it sits on — an app style, not a token.

Remarks

In Material, "raised" is expressed as lightness: these surfaces take a lighter fill (['color-elevated'] color-elevated) and carry no border. A flat design language holds the fill nearly constant and expresses it as border + shadow instead (VS Code's own find widget and menus do exactly this), so a host whose float fill sits within a shade of the ground has to put the structure back somewhere — and this is it. Defaults to transparent, so the Material presentation is unchanged unless a host opts in.

Remarks

The sibling --sxl-image-filter (dark-image invert) is deliberately NOT a token: it carries a runtime preference gate (enableDarkImages) that a pure mode-driven token can't express — a descendant grid scope would re-emit and un-gate it. It's a single workbook-root computed var instead (see WorkbookElement).