desktop-mode / assets / css / variables.css

variables.css in OpenStation: Desktop Windows, Dock & Virtual Desktops for WP Admin 1.1.8, at assets/css/variables.css

1,807 lines 80.2 KB

Raw Download Zip

1	/**
2	* OpenStation — CSS Custom Properties.
3	*
4	* All design tokens for the desktop shell, carrying the OpenStation
5	* brand: https://nuriapenya.github.io/open-station-brand/
6	*
7	* ## The palette
8	*
9	* Pulse #f252fc neon identity accent
10	* Nebula #ec9bff soft identity accent
11	* Sirius #c2f1f1 aqua contrast accent
12	* Starlight #fffbff lightest — primary text on the station
13	* Void #0c0b0f darkest — the base everything sits on
14	* Obsidian #1a1721 surfaces: window bodies, cards, rows
15	*
16	* Shade ramp, Void to Starlight, for text hierarchy and lines:
17	* Astro #33303a · Silver #4d4a52 · Pewter #66636b ·
18	* Osmium #99969c · Ash #b3afb5 · Cloud #ccc8ce · Mist #e6e2e6
19	*
20	* The brand's own composition rule, followed here literally: "Void as
21	* the base, Obsidian for surfaces, Pulse and Nebula for identity
22	* moments, Sirius and Starlight for contrast, the Shade palette for
23	* text hierarchy and lines, meshes reserved for hero surfaces."
24	*
25	* ## Why these are declared at all
26	*
27	* Every rule in the tree reads its token as
28	* `var( --token, <literal> )`, and those literals are the look the
29	* shell had before the brand: WordPress-admin greys and blues. They
30	* are still there, still correct, and still what renders if this file
31	* fails to load. Declaring the tokens here is what puts the station on
32	* top of them — one declaration retints every surface that reads it.
33	*
34	* The way back is a theme, not an edit: Desktop Mode (Legacy)
35	* (`assets/desktop-themes/legacy/theme.json`) is a frozen snapshot of
36	* those pre-brand literals, and picking it in OS Settings → Themes
37	* restores the old look wholesale. A desktop theme's compiled selector
38	* weighs (0,2,0) against this file's `:root` (0,1,0) and loads after
39	* it, so any theme — Legacy or a third party's — outranks everything
40	* below.
41	*
42	* ## Semantic colours
43	*
44	* The brand defines no status palette, so danger / success / warning /
45	* info are derived rather than quoted: the hues the shell already used,
46	* lifted until they carry on a Void-to-Obsidian background, and where
47	* the brand does have a colour that means the right thing it is used
48	* instead — Sirius for info, and Holomesh's mint and warm for success
49	* and warning.
50	*/
51
52	/*
53	* ---- Typefaces -------------------------------------------------
54	*
55	* Geist and Geist Mono, the brand faces, self-hosted from
56	* `assets/fonts/` under the SIL Open Font License 1.1 (the licence
57	* text ships beside them in `OFL.txt`). Both are VARIABLE fonts: one
58	* file covers 100–900, which is why a whole typographic scale costs
59	* ~70 kB per family rather than one file per weight.
60	*
61	* `font-display: swap` paints fallback text immediately and swaps when
62	* the face arrives — on admin chrome that is almost always right,
63	* where `block` would hide every dock label until the download lands.
64	*
65	* The `url()`s are relative to THIS stylesheet, which is what keeps
66	* them correct however the plugin directory is renamed or wherever it
67	* is symlinked from.
68	*/
69	@font-face {
70	font-family: 'Geist';
71	src: url('../fonts/Geist-Variable.woff2') format('woff2');
72	font-weight: 100 900;
73	font-style: normal;
74	font-display: swap;
75	}
76
77	@font-face {
78	font-family: 'Geist Mono';
79	src: url('../fonts/GeistMono-Variable.woff2') format('woff2');
80	font-weight: 100 900;
81	font-style: normal;
82	font-display: swap;
83	}
84
85	/*
86	* ---- Registered, so "undeclared" never means transparent ---------
87	*
88	* The scope note below keeps this palette out of iframe documents on
89	* purpose: an admin page inside a window renders with the values its
90	* own stylesheets were written with. That promise has one hole CSS
91	* digs by itself — a stylesheet that consumes
92	* `var(--wp-admin-theme-color)` with no fallback, in a document where
93	* nothing declares it, does not fall back to an earlier declaration
94	* in the cascade. An unresolved `var()` is invalid at computed-value
95	* time, so the property computes to `initial` — and an unregistered
96	* custom property's initial value is the guaranteed-invalid value,
97	* which for a `background` means transparent. Core's own scheme files
98	* declare the property, but a third-party admin scheme that consumes
99	* it without declaring it renders `.button-primary` white-on-white
100	* inside every chromeless window (#702).
101	*
102	* Registering the property gives "undeclared" a real answer:
103	* WordPress's default admin colour, the same value Core's fallbacks
104	* reach for. Declarations are untouched — a scheme, the palette
105	* below, or the accent picker's inline style all keep winning exactly
106	* as before. Registration only decides what the absence of all of
107	* them computes to.
108	*/
109	@property --wp-admin-theme-color {
110	syntax: "<color>";
111	inherits: true;
112	initial-value: #3858e9;
113	}
114
115	/*
116	* ---- Scope: the shell document, and nothing else -----------------
117	*
118	* `body.os-active` rather than `:root`, and that is
119	* load-bearing rather than tidy.
120	*
121	* This stylesheet is a dependency of `chromeless.css`, so it also
122	* loads INSIDE every iframe window — a real `wp-admin` document. A
123	* palette on `:root` would reach that document and repaint WordPress's
124	* own UI: `--wp-admin-theme-color` alone would turn Core's primary
125	* buttons, links and focus rings across every admin screen, with
126	* white button text landing on a colour it was never contrast-tested
127	* against.
128	*
129	* Iframe documents carry `body.os-chromeless` instead, so
130	* they match nothing here and every rule in the tree falls back to the
131	* literal it was always written with — the WordPress-admin values.
132	* **An admin page inside a window looks exactly as it does outside
133	* one.** That is deliberate: the station is the chrome around the
134	* page, not a reskin of the page.
135	*
136	* Specificity: (0,1,1). A desktop theme compiles to
137	* `body.os-desktop-theme-<slug>`, also (0,1,1) on the same
138	* element, and its stylesheet declares `os-variables` as a
139	* dependency — so it always prints after this file and wins the tie.
140	* Do not remove that dependency; see the note in
141	* `openstation_enqueue_desktop_theme_style()`.
142	*/
143	body.os-active {
144	/*
145	* ---- Desk --------------------------------------------------
146	*
147	* `Space`, the brand's quiet deep-space backdrop: a linear
148	* gradient from near-black through to a faint violet horizon.
149	*
150	* Note this is the desk's CSS default, not usually what you see:
151	* the wallpaper layer writes the ACTIVE wallpaper into this same
152	* property as an inline style, and the shipped default is the
153	* `Galaxy` artwork (`includes/wallpapers.php`). This value is what
154	* paints before that runs, and for anyone whose wallpaper is
155	* unavailable.
156	*/
157	--os-bg: linear-gradient(160deg, #010101 0%, #111114 58%, #1e1d23 100%);
158	/*
159	* Flat colour painted on the shell itself, behind every other
160	* layer including the wallpaper.
161	*
162	* The shell is `position: fixed` over the classic admin page, and
163	* that page is WHITE. Anything that leaves a layer unpainted for a
164	* single frame — a canvas wallpaper's context being disturbed, the
165	* compositor re-rasterising after a large GPU layer goes away —
166	* shows it. This is the floor that makes that impossible: the worst
167	* a dropped frame can now look like is Void.
168	*
169	* Deliberately a solid rather than `--os-bg`: it is never
170	* seen when things are working, so it should cost one flat fill,
171	* not a second gradient rasterisation on every shell repaint.
172	*/
173	--os-backstop: #0c0b0f;
174	--os-area-inset: 0;
175
176	/*
177	* ── The icon grid ────────────────────────────────────────────
178	*
179	* ONE grid, everywhere placements are laid out: the wallpaper,
180	* folder windows, and every canvas in the site folder. Before
181	* these tokens each surface carried its own pitch and its own
182	* tile width, and the two drifted apart — the desktop ended up
183	* with an 88px tile in a 96px cell whose 8px of air the tile's
184	* own padding ate, so icons touched edge to edge while the site
185	* folder had 20px between them.
186	*
187	* The cell is derived, never declared: `cell = tile + gap`. A
188	* gap you can see is the whole point, so it is the number that
189	* gets tuned; the pitch follows.
190	*
191	* The TypeScript side mirrors these in `src/desktop-files/grid.ts`
192	* (layout maths can't read CSS), and
193	* `tests/vitest/grid-metrics.test.ts` parses this file to prove
194	* the two agree. Change a number here and that test tells you
195	* exactly which constant to move with it.
196	*/
197	--os-tile-w: 88px;
198	/*
199	* A FIXED height, and it has to fit the tallest a tile can get:
200	* 8px padding + 48px icon well + 6px gap + two clamped label
201	* lines (2 × 12px × 1.2 = 28.8px) + 8px padding = 98.8px, so
202	* 104px with a little slack for font metrics.
203	*
204	* Fixed rather than minimum because the selection ring is drawn
205	* around the tile box: let the box follow its label and a row of
206	* selected icons is a ragged run of different-height rectangles,
207	* one per label that happened to wrap.
208	*/
209	--os-tile-h: 104px;
210	--os-grid-gap-x: 20px;
211	--os-grid-gap-y: 16px;
212	/* Gutter from the top / inline-start edge of any icon canvas. */
213	--os-grid-padding: 16px;
214	/*
215	* Image-led sections opt into a bigger tile (`tileSize: 'large'`)
216	* — a shop's products read as a catalogue, not a file list. Same
217	* gaps, bigger tile.
218	*/
219	--os-tile-w-large: 132px;
220	--os-tile-h-large: 160px;
221
222	/* Window chrome — Obsidian body inside a Starlight hairline. */
223	--os-window-bg: #1a1721;
224	--os-window-border: rgba(255, 251, 255, 0.12);
225	/*
226	* Window corner. Softer than the 8px the shell carried before, so
227	* a window reads as an object on the desk rather than a panel
228	* pinned to it.
229	*
230	* The tab strip's own radius is deliberately NOT tied to this one.
231	* A tab is 30px tall, so a corner anywhere near this size eats the
232	* whole straight edge and turns the tab into a capsule — it stops
233	* reading as a folder tab attached to the page, which is the one
234	* thing the tab has to say. `--os-tabs-radius` stays smaller and
235	* independent on purpose.
236	*/
237	--os-window-radius: 16px;
238	/*
239	* Shadows stay black and go deeper than they were: on a Void desk
240	* a soft grey shadow is invisible, and depth is the only thing
241	* separating a window from the sky behind it.
242	*/
243	--os-window-shadow: 0 8px 32px rgba(0, 0, 0, 0.5), 0 2px 8px rgba(0, 0, 0, 0.3);
244	--os-window-shadow-focused: 0 12px 48px rgba(0, 0, 0, 0.6), 0 4px 12px rgba(0, 0, 0, 0.35);
245	/*
246	* Fill of the surface a window's content is revealed from once it
247	* finishes loading (OS Settings → Effects → "Window reveal").
248	*
249	* Obsidian, so a window uncovers from its own colour rather than
250	* flashing white on a dark desk. The surface has to be opaque or
251	* there is nothing to reveal FROM — the content would simply be
252	* visible the whole time and the clip animation would paint
253	* nothing. `transparent` is a legitimate value meaning "no
254	* covering surface"; the shell then skips the layer rather than
255	* animating something invisible.
256	*
257	* A reveal may override this for itself when the paint IS the
258	* reveal; `obturator` (Camera shutter) is the one built-in that
259	* does, because near-black blades are what make it a shutter.
260	*/
261	--os-window-reveal-surface: #1a1721;
262	/*
263	* Fill of the reveal's leading edge — the band that travels with
264	* the clip boundary and draws each reveal's shape (six lines on
265	* Blinds, an opening ring on Iris, a rotating spoke on Radar).
266	*
267	* `transparent` by default: the reveal reads as the page arriving,
268	* and a hard graphic edge on top of that is a deliberate look
269	* rather than the neutral one. A theme (or any stylesheet) opts in
270	* by giving this a colour — no JS and no per-reveal configuration
271	* needed, because the band follows whatever shape the active
272	* reveal has. While it computes to fully transparent the shell
273	* skips the layer altogether, so the default costs nothing.
274	*/
275	--os-window-reveal-edge: transparent;
276
277	/*
278	* ---- Title bar ---------------------------------------------
279	*
280	* Obsidian when focused, Void when not: the focused window's
281	* chrome sits one step up the Shade ramp while its unfocused
282	* neighbours sink toward the desk they are lying on. That is the
283	* entire focus signal, and it costs no colour — which matters,
284	* because the accent is spoken for.
285	*
286	* The pair used to be Astro-over-Obsidian, a step higher. It came
287	* down so a focused window's title bar and its tab strip are the
288	* SAME Obsidian, and the only thing lifting out of that surface is
289	* the tab itself. The step is the same size; the whole ramp moved.
290	*/
291	--os-titlebar-bg: #0c0b0f;
292	--os-titlebar-bg-focused: #1a1721;
293	--os-titlebar-color: #99969c;
294	--os-titlebar-color-focused: #fffbff;
295	--os-titlebar-height: 40px;
296	/* Hairline between page chrome and window chrome. */
297	--os-titlebar-divider: rgba(255, 251, 255, 0.12);
298	--os-titlebar-divider-unfocused: rgba(255, 251, 255, 0.06);
299
300	/*
301	* The status ring — leading mark of the title bar, where the app
302	* icon used to be. Four states: the resting ring is Starlight,
303	* work and success are both Pulse, failure is the danger colour.
304	*
305	* Pulse twice over is not an oversight. In flight and landed
306	* differ in FILL — an open ring breathing, then a solid disc with
307	* a check — and failure differs from both in fill AND glyph AND
308	* hue. Shape carries the distinction that colour alone cannot for
309	* a user who can't separate the two hues, and the accent stays the
310	* shell's own voice for "this is your station working".
311	*
312	* Failure resolves through `--os-ui-danger` and is the one value
313	* here that must not be quietened: a failure that whispers is a
314	* failure the user misses.
315	*
316	* The resting ring is one value in both title-bar states, not two:
317	* the ring reports a phase, and dimming it on an unfocused window
318	* would make `idle` say something different depending on which
319	* window you last clicked.
320	*/
321	--os-titlebar-activity-idle-color: #fffbff;
322	--os-titlebar-activity-color: var(--os-ui-accent, #2271b1);
323	--os-titlebar-activity-saved-color: var(--os-ui-accent, #2271b1);
324	--os-titlebar-activity-failed-color: var(--os-ui-danger, #d63638);
325	--os-titlebar-activity-size: 16px;
326
327	/*
328	* Title-bar control glyphs — minimise / maximise / close, the ⋯
329	* menu trigger, and the screen-meta cluster — in each of the two
330	* title-bar states.
331	*
332	* Both halves are named explicitly. The unfocused half would
333	* otherwise derive itself from `--os-titlebar-color` by
334	* a `color-mix()` that only runs while a desktop theme is active,
335	* and the focused half cannot derive at all: its glyphs sit on
336	* `-bg-focused`, and CSS has no contrast-safe function of a
337	* background colour.
338	*
339	* Close-button red is deliberately not in either set — it is
340	* semantic signal, not chrome, and both states resolve it through
341	* `--os-ui-danger`.
342	*/
343	--os-titlebar-btn-color: rgba(255, 251, 255, 0.55);
344	--os-titlebar-btn-color-hover: #fffbff;
345	--os-titlebar-btn-bg-hover: rgba(255, 251, 255, 0.1);
346	--os-titlebar-btn-bg-active: rgba(255, 251, 255, 0.16);
347	--os-titlebar-btn-focused-color: rgba(255, 251, 255, 0.72);
348	--os-titlebar-btn-focused-color-hover: #fffbff;
349	--os-titlebar-btn-focused-bg-hover: rgba(255, 251, 255, 0.14);
350	--os-titlebar-btn-focused-bg-active: rgba(255, 251, 255, 0.2);
351	--os-titlebar-btn-focused-outline: #f252fc;
352
353	/*
354	* The control cluster and each button face stay TRANSPARENT, so a
355	* themed title-bar texture runs edge to edge underneath them and
356	* the glyphs float on the artwork. A plate behind the controls is
357	* a choice a theme makes, not a default the framework imposes.
358	* The knobs for building one:
359	*
360	* Cluster --os-titlebar-controls-bg
361	* --os-titlebar-controls-image (+ -repeat,
362	* -size, -position)
363	* --os-titlebar-controls-radius
364	* --os-titlebar-controls-padding (inline)
365	* --os-titlebar-controls-gap
366	* Screen-meta cluster
367	* --os-titlebar-meta-bg / -image / -radius
368	* (radius falls through to the controls radius)
369	* Each face --os-ui-btn-bg / --os-ui-btn-bg-image / --os-ui-btn-radius
370	*/
371
372	/*
373	* Admin accent. Pulse, the brand's identity colour, and the value
374	* behind the `pulse` swatch that OS Settings → Appearance ships as
375	* its default (`includes/accents.php`). The accent picker writes
376	* the user's choice into this same property as an inline style, so
377	* this is the pre-JS value and the floor under every scheme block
378	* below.
379	*/
380	--wp-admin-theme-color: #f252fc;
381
382	/* Resize handle — larger hit area than visual glyph; corners
383	are transparent until hover so they don't compete with the
384	window's own drop shadow. */
385	--os-resize-size: 20px;
386	--os-resize-color: rgba(255, 251, 255, 0.18);
387
388	/*
389	* ---- The `--os-ui-*` UI palette ------------------------------
390	*
391	* The single vocabulary for every surface, text tone, border, and
392	* status colour inside window BODIES — the `<os-*>` component kit
393	* AND the feature stylesheets both read these. Setting one value
394	* retints everything that uses it, which is what makes a
395	* whole-OS repaint eleven declarations rather than a thousand.
396	*
397	* It reaches further than window bodies: the shell's own
398	* body-mounted overlays — toasts, confirm dialogs, context menus,
399	* and the command palette — read it too.
400	*
401	* Roughly 190 component-local tokens (`--os-ui-card-bg`,
402	* `--os-ui-table-header-bg`, …) fall through to these, e.g.
403	*
404	* background: var( --os-ui-card-bg, var( --os-ui-surface, #fff ) );
405	*
406	* so the ones named further down are only those whose own literal
407	* does NOT chain through the palette and would otherwise stay a
408	* light-mode value on a dark station.
409	*/
410
411	/* Surfaces — Obsidian on Void, one step up the ramp for elevated. */
412	--os-ui-surface: #1a1721;
413	--os-ui-surface-elevated: #33303a;
414	--os-ui-surface-sunken: #0c0b0f;
415	--os-ui-surface-raised: rgba(255, 251, 255, 0.06);
416	--os-ui-surface-subtle: rgba(255, 251, 255, 0.03);
417	--os-ui-bg: #1a1721;
418	--os-ui-bg-subtle: rgba(255, 251, 255, 0.03);
419
420	/*
421	* Fields — the surface an input paints, for markup in the LIGHT
422	* DOM.
423	*
424	* The kit's own controls don't need these: `<os-text-field>` and
425	* friends resolve `--os-window-bg` inside their shadow roots,
426	* which the window chrome sets. A plugin writing a plain
427	* `<input>` into a native window's body has neither, and the
428	* palette had no general answer — no `surface` variant means
429	* "input". What it had was `--os-ui-modal-field-bg`, which is a
430	* MODAL token: right value, wrong scope, and the sort of thing a
431	* plugin author finds by grepping for a colour that looks close.
432	*
433	* Consumers keep the pre-brand WordPress-admin literals as their
434	* fallbacks — `#fff`, `#8c8f94`, `#2c3338` — so an unstyled page
435	* lands on the classic admin's own field, not on nothing:
436	*
437	* background: var( --os-ui-field-bg, #fff );
438	* border: 1px solid var( --os-ui-field-border, #8c8f94 );
439	* color: var( --os-ui-field-fg, #2c3338 );
440	*/
441	--os-ui-field-bg: #33303a;
442	--os-ui-field-border: #4d4a52;
443	--os-ui-field-fg: #fffbff;
444
445	/*
446	* Field sizing. The kit's own `<os-text-field>` and `<os-textarea>`
447	* (and every kit control that hosts a typing input) read these for
448	* the control's type size and corner. The phone layer raises the
449	* size to 16px — below that, iOS zooms the whole page into a
450	* focused control and never zooms back — and rounds its search;
451	* a theme may do the same anywhere.
452	*/
453	--os-ui-field-font-size: 13px;
454	--os-ui-field-font-size-compact: 12px;
455	--os-ui-field-radius: 6px;
456
457	/* Text — Starlight down through the Shade ramp. */
458	--os-ui-fg: #fffbff;
459	--os-ui-fg-muted: #b3afb5;
460	--os-ui-fg-faint: #66636b;
461	--os-ui-text-muted: rgba(255, 251, 255, 0.6);
462	/*
463	* Text on a filled surface — and the name undersells it. Around
464	* forty rules read this token, and only about half of them sit on
465	* the accent: the rest are white-on-dark chips that never had a
466	* name of their own — the toast, the drag hint, the widget picker,
467	* the file-tile lock, the overview labels, every scrim-backed
468	* caption in OS Settings.
469	*
470	* So it is Starlight. Void reads better ON Pulse (5.9:1 against
471	* 2.9:1) and was the first choice here, but it turned all of those
472	* chips into black text on a near-black wash. One token cannot be
473	* both, and the dark-chip half is both larger and the half that
474	* fails catastrophically rather than merely weakly.
475	*
476	* The surfaces that really are a bright fill — ribbons and step
477	* chips — name their own dark text below, which is the escape
478	* hatch this token leaves open.
479	*/
480	--os-ui-fg-on-accent: #fffbff;
481
482	/* Lines. */
483	--os-ui-border: #33303a;
484	--os-ui-border-strong: #4d4a52;
485
486	/* Interaction — light washes, since the surface underneath is dark. */
487	--os-ui-hover: rgba(255, 251, 255, 0.06);
488	--os-ui-scrim: rgba(12, 11, 15, 0.72);
489
490	/*
491	* ---- Text selection ------------------------------------------
492	*
493	* Lagoon, the brand's violet-blue, at 60%. It is the one primary
494	* colour in the guidelines the shell had no job for, and this is
495	* the right job: violet-blue is what every OS has trained people
496	* to read as "selected", so it needs no learning.
497	*
498	* The alpha is where the accessibility is, and it is squeezed from
499	* both ends. A selection has to satisfy two constraints at once:
500	*
501	* 1. the selected TEXT stays readable on it — Starlight over
502	* Lagoon@60% is 5.1:1 on Obsidian, 5.5:1 on Void; and
503	* 2. the highlight is distinguishable from the unselected
504	* background — 3.4:1 and 3.5:1 respectively.
505	*
506	* Raising the alpha helps (2) and hurts (1); lowering it does the
507	* reverse. 60% is the middle of the band where both clear their
508	* bar on both surfaces. An accent wash cannot do this at all: the
509	* Pulse family only separates from the background above 75%, by
510	* which point it is a fill rather than a highlight.
511	*
512	* The text colour is Starlight — the colour body text already is.
513	* A selection that also RECOLOURS the text destroys every
514	* distinction the text was carrying: syntax highlighting, a red
515	* error, a muted timestamp. Highlighting is not restyling.
516	*/
517	--os-ui-selection-bg: rgba(159, 152, 255, 0.6);
518	--os-ui-selection-fg: #fffbff;
519
520	/* Accent — the identity moment. */
521	--os-ui-accent: #f252fc;
522	--os-ui-accent-strong: #ec9bff;
523	--os-ui-accent-soft: color-mix(in srgb, var(--os-ui-accent-dim) 14%, transparent);
524	/*
525	* Pulse, one step back — and the single knob for how loud the
526	* station is.
527	*
528	* Pulse is not a contrast problem: #f252fc carries 6.2:1 against
529	* Obsidian, better than most accents in a dark UI manage. What it
530	* is, is SATURATED — HSL 296, 97, 65 — and the places that hurt
531	* are the ones where it is spread rather than stated: a bloom
532	* behind a focused control, a 18% wash under a selected row, a
533	* fill wider than a chip. Ten of those on one panel and the whole
534	* surface hums.
535	*
536	* So the fix is not to move Pulse. It is to spend it where it is
537	* a statement and to spend THIS where it is atmosphere: the same
538	* hue with saturation and lightness pulled down together (S 77,
539	* L 53), which is what keeps it recognisably Pulse rather than a
540	* different purple. 4.6:1 on Obsidian, and Starlight over it goes
541	* from 2.8:1 to 3.8:1 — so the wash also stopped eating text.
542	*
543	* Everything ambient below resolves through it: the glows, the
544	* soft wash, the focus bloom. Turning the station up or down is
545	* one edit here.
546	*
547	* `--os-ui-accent` itself stays #f252fc. That one is the brand's,
548	* not ours — it is what the guidelines name and what
549	* `brand-palette.test.ts` pins, and moving it is a brand decision
550	* rather than a UI one.
551	*/
552	--os-ui-accent-dim: #d92ee3;
553
554	/*
555	* ---- The meshes ---------------------------------------------
556	*
557	* The brand ships five mesh gradients as SVG artwork. These are
558	* those same meshes transcribed into CSS: the base linear plus
559	* every radial glow, at the offsets, radii, colours and alphas
560	* the vector files declare, converted from the 1440×960 artboard
561	* into percentages so they scale to any box.
562	*
563	* Transcribed rather than referenced on purpose. A `url()` to an
564	* SVG cannot be animated, cannot be tinted, costs a request, and
565	* cannot resize its glows independently of the box — a mesh
566	* painted on a 40 px switch track would be one flat corner of the
567	* artwork. As gradient stacks they rasterise at whatever size the
568	* control happens to be, and `background-position` can slide them,
569	* which is the entire holographic effect: a foil that shifts as
570	* you tilt it.
571	*
572	* Layer order is inverted from the SVG. In SVG the last `<rect>`
573	* paints on top; in a CSS `background-image` list the FIRST layer
574	* is on top. So each mesh below reads bottom-glow-first and ends
575	* with its base linear.
576	*
577	* The brand's own rule — "meshes reserved for hero surfaces" — is
578	* why none of these is a surface colour. They are what the shell
579	* paints at an identity moment: a switch that is on, the primary
580	* action in a dialog, the filled part of a progress bar. See the
581	* `--os-ui-holo-*` block below for the tokens components actually
582	* read.
583	*/
584
585	/*
586	* Holomesh. Lavender base under eight glows — white, cyan, pink,
587	* warm, mint, white, pink, blue. The default holographic fill.
588	*/
589	--os-mesh-holo:
590	radial-gradient(ellipse 21.7% 39.6% at 96.5% 13.5%, rgba(159, 214, 255, 0.6) 0%, rgba(159, 214, 255, 0) 100%),
591	radial-gradient(ellipse 26.3% 57.2% at 83.3% 56.2%, rgba(243, 181, 236, 0.75) 0%, rgba(243, 181, 236, 0) 100%),
592	radial-gradient(ellipse 18.2% 47.3% at 73.6% 64.5%, rgba(255, 253, 255, 0.7) 0%, rgba(255, 253, 255, 0) 100%),
593	radial-gradient(ellipse 18.4% 34.1% at 29.8% 83.4%, rgba(147, 240, 198, 0.8) 0%, rgba(147, 240, 198, 0) 100%),
594	radial-gradient(ellipse 17.4% 35.7% at 23% 67.7%, rgba(248, 242, 182, 0.85) 0%, rgba(248, 242, 182, 0) 100%),
595	radial-gradient(ellipse 23.3% 45.9% at 45.2% 45.8%, rgba(245, 159, 232, 1) 0%, rgba(245, 168, 234, 0.55) 55%, rgba(245, 168, 234, 0) 100%),
596	radial-gradient(ellipse 29.9% 53.6% at 53.5% 7.3%, rgba(125, 239, 245, 0.9) 0%, rgba(142, 233, 247, 0.45) 60%, rgba(142, 233, 247, 0) 100%),
597	radial-gradient(ellipse 26.9% 70.7% at 29.8% 44.8%, rgba(255, 253, 255, 0.95) 0%, rgba(255, 253, 255, 0.5) 55%, rgba(255, 253, 255, 0) 100%),
598	linear-gradient(124deg, #afa2e8 0%, #b7abea 55%, #c3b8ef 100%);
599
600	/*
601	* Pulsemesh. The loud one — a blue-to-violet base torn open by
602	* magenta. Reserved for the moments Holomesh would undersell.
603	*/
604	--os-mesh-pulse:
605	radial-gradient(ellipse 39.1% 48.6% at 92% 94.5%, rgba(255, 253, 255, 0.95) 0%, rgba(255, 240, 252, 0.55) 50%, rgba(255, 240, 252, 0) 100%),
606	radial-gradient(ellipse 33.3% 50% at 61.1% 62.5%, rgba(251, 134, 236, 0.85) 0%, rgba(251, 134, 236, 0) 100%),
607	radial-gradient(ellipse 36.1% 54.2% at 10.4% 39.6%, rgba(250, 61, 248, 1) 0%, rgba(250, 61, 248, 0) 100%),
608	radial-gradient(ellipse 87.3% 104.8% at 10.6% 100%, rgba(240, 75, 245, 1) 0%, rgba(240, 75, 245, 0.75) 43%, rgba(240, 75, 245, 0) 100%),
609	radial-gradient(ellipse 36.1% 45.8% at 92.4% 12.5%, rgba(125, 239, 245, 0.95) 0%, rgba(125, 239, 245, 0) 100%),
610	radial-gradient(ellipse 43.1% 54.2% at 81.3% 34.4%, rgba(108, 143, 245, 0.6) 0%, rgba(108, 143, 245, 0) 100%),
611	linear-gradient(236deg, #8d9bf3 0%, #c878f0 100%);
612
613	/* Auromesh. Lavender through mint into cyan — the calm mesh. */
614	--os-mesh-auro: linear-gradient(80deg, #d1c6f8 9.5%, #cefada 50%, #b8ffff 90.5%);
615
616	/* Starmesh. A Starlight glow falling away into Cloud. */
617	--os-mesh-star:
618	radial-gradient(ellipse 72.7% 72.7% at 50% 12.5%, #fffbff 0%, #fffbff 67.8%, #ccc8ce 100%);
619
620	/* Miomesh. The mascot's own sweep. Mio's, and used sparingly. */
621	--os-mesh-mio: linear-gradient(90deg, #f252fc 7%, #aa67ff 48.3%, #a580ff 70.7%, #4b3eff 93%);
622
623	/*
624	* ---- Holographic controls -----------------------------------
625	*
626	* What a control reads when it wants to be holographic. Every
627	* `<os->` resolves these through a private `--_holo-` alias (see
628	* `src/ui/holo.ts`), so a desktop theme can re-point any of them
629	* and every control in the kit changes together.
630	*
631	* The holographic state is a MOMENT, not a skin. A control paints
632	* `--os-ui-holo-fill` when it is on, selected, primary or filled —
633	* the one instant it is speaking for the brand — and wears
634	* ordinary Obsidian the rest of the time. That is the difference
635	* between a station and a novelty; a panel where every control is
636	* iridescent has no identity moments left to spend.
637	*/
638
639	/* The fill itself. Holomesh, so the mesh is the default look. */
640	--os-ui-holo-fill: var(--os-mesh-holo);
641	/*
642	* A hero FIELD, as distinct from a hero control.
643	*
644	* `--os-ui-holo-fill` is sized for a surface a control wears — a
645	* button, a chip, a progress bar. Stretch that same value across
646	* a few hundred square pixels of panel and a theme's answer stops
647	* working: Legacy's `#f0f6fc -> #f6f7f7` reads as "on" on a 40px
648	* chip and as nothing at all on a rail, where it lands within a
649	* few units of the surface behind it.
650	*
651	* So a large decorative field reads THIS instead, and a theme
652	* gets to answer the two cases separately — how a control looks
653	* when it is on, and how much of itself the station shows in the
654	* background. Legacy sets a flat pre-brand wash here while
655	* leaving its control fill alone.
656	*
657	* The default is an aurora, and it is built differently from the
658	* five meshes on purpose. Those are OPAQUE light surfaces — the
659	* darkest stop in Holomesh still sits above 60% luminance — which
660	* is right for a control that has to read as lit against whatever
661	* is behind it. Spread one across a rail and the only way to calm
662	* it down is `opacity`, which drags every hue toward the surface
663	* underneath: on Void that is grey, and the mesh dies as a
664	* grey-mauve smear.
665	*
666	* So the alpha lives in the COLOUR STOPS here, over transparent.
667	* The desk shows through instead of being covered, the hues keep
668	* their chroma at any strength, and the field stays dark the way
669	* an aurora is dark — light added to a night sky, not a pale
670	* sheet laid over one. Hues are the brand's: violet and Nebula
671	* through the upper curtains, Sirius cyan and Holomesh's mint
672	* below, one wide Pulse bloom tying them together.
673	*/
674	--os-ui-hero-mesh:
675	radial-gradient(ellipse 62% 38% at 34% 20%, rgba(170, 103, 255, 0.58) 0%, rgba(170, 103, 255, 0) 74%),
676	radial-gradient(ellipse 54% 33% at 58% 36%, rgba(236, 155, 255, 0.45) 0%, rgba(236, 155, 255, 0) 76%),
677	radial-gradient(ellipse 68% 30% at 26% 50%, rgba(125, 239, 245, 0.32) 0%, rgba(125, 239, 245, 0) 74%),
678	radial-gradient(ellipse 58% 28% at 46% 66%, rgba(147, 240, 198, 0.26) 0%, rgba(147, 240, 198, 0) 76%),
679	radial-gradient(ellipse 96% 62% at 40% 42%, rgba(242, 82, 252, 0.18) 0%, rgba(242, 82, 252, 0) 82%);
680	/*
681	* Glyphs and text ON that fill. Void, not Starlight — every mesh
682	* in the brand is a LIGHT surface (its darkest stop, Holomesh's
683	* #afa2e8, still sits at 62% luminance), so Starlight on it is a
684	* white-on-lilac 1.4:1 that looks fine in a mock and is unreadable
685	* on a screen. Void carries at 8.6:1 against the same stop.
686	*/
687	--os-ui-holo-ink: #0c0b0f;
688	/*
689	* The hover film. A control that is NOT in its holographic state
690	* still hints at one under the pointer: a low-alpha sweep of the
691	* mesh's own hues, laid over whatever the surface already is.
692	*
693	* Alphas are deliberately in the 6–12% range. This lands on
694	* Obsidian, where anything stronger stops reading as a sheen and
695	* starts reading as a second, wrongly-coloured surface.
696	*/
697	--os-ui-holo-sheen: linear-gradient(
698	124deg,
699	rgba(159, 214, 255, 0.1) 0%,
700	rgba(236, 155, 255, 0.12) 34%,
701	rgba(242, 82, 252, 0.1) 58%,
702	rgba(147, 240, 198, 0.09) 100%
703	);
704	/*
705	* The iridescent hairline. Painted as a gradient on a padding-box
706	* mask rather than a `border-color`, because a border cannot hold
707	* a gradient and `border-image` loses the corner radius.
708	*/
709	--os-ui-holo-edge: linear-gradient(
710	124deg,
711	rgba(154, 242, 255, 0.7) 0%,
712	rgba(236, 155, 255, 0.85) 38%,
713	rgba(242, 82, 252, 0.7) 62%,
714	rgba(159, 152, 255, 0.6) 100%
715	);
716	/* Resting edge — the same hairline, quieted, for an idle control. */
717	--os-ui-holo-edge-quiet: linear-gradient(
718	124deg,
719	rgba(154, 242, 255, 0.22) 0%,
720	rgba(236, 155, 255, 0.28) 38%,
721	rgba(242, 82, 252, 0.22) 62%,
722	rgba(159, 152, 255, 0.2) 100%
723	);
724	/*
725	* The bloom around a holographic surface. Pulse, because on a Void
726	* desk the glow is what separates "lit" from "light-coloured".
727	*/
728	--os-ui-holo-glow: 0 0 0 1px color-mix(in srgb, var(--os-ui-accent-dim) 20%, transparent),
729	0 2px 10px color-mix(in srgb, var(--os-ui-accent-dim) 15%, transparent);
730	--os-ui-holo-glow-strong: 0 0 0 1px color-mix(in srgb, var(--os-ui-accent-dim) 30%, transparent),
731	0 4px 18px color-mix(in srgb, var(--os-ui-accent-dim) 26%, transparent),
732	0 1px 3px rgba(12, 11, 15, 0.6);
733	/*
734	* The unlit half — switch tracks, empty progress, the unchecked
735	* checkbox.
736	*
737	* This was a sunken Void well, and it was a mistake that measured
738	* badly: `rgba(12, 11, 15, 0.55)` composites to #121017 on an
739	* Obsidian panel, which is 1.07:1 against that panel. An off
740	* switch was, to a very good approximation, not drawn. WCAG 1.4.11
741	* asks for 3:1 on the boundary of a control, and this was not in
742	* the same postcode.
743	*
744	* So the well is LIFTED rather than sunk: a Starlight wash, which
745	* also means it tracks whatever surface a theme puts behind it
746	* instead of pinning a grey that only works on Obsidian. Every
747	* dark OS does the same thing with its switches for the same
748	* reason — on a dark UI the visible thing is the lighter one.
749	*
750	* The fill alone still only reaches ~1.6:1, which is a look
751	* rather than a boundary. The 3:1 comes from the edge below, and
752	* the two together are what make an off switch findable.
753	*/
754	--os-ui-holo-track: rgba(255, 251, 255, 0.16);
755	/*
756	* The unlit half's boundary. Pewter, and not a rounder-looking
757	* neighbour, because Pewter is the first step on the Shade ramp
758	* that reaches 3.00:1 against Obsidian — Silver manages 2.03 and
759	* Astro 1.37. This is the declaration that makes an off control
760	* satisfy WCAG 1.4.11.
761	*/
762	--os-ui-holo-track-edge: #66636b;
763	/*
764	* Focus. One ring for the whole kit — Pulse, offset, over a soft
765	* halo, so it reads on Obsidian, on a mesh, and on the near-white
766	* of a legacy theme alike.
767	*
768	* Note which layer dims and which does not. The RING is full Pulse
769	* and stays there: it is the only thing on screen saying where the
770	* keyboard is, and a focus indicator is the last place to trade
771	* legibility for calm. Only the bloom behind it comes down, from
772	* 45% to 30%, and onto the dim — which is the layer that was
773	* making a focused control look like it was on fire.
774	*/
775	--os-ui-focus-ring: 0 0 0 2px rgba(12, 11, 15, 0.9),
776	0 0 0 4px var(--os-ui-accent, #f252fc),
777	0 0 12px 2px color-mix(in srgb, var(--os-ui-accent-dim) 30%, transparent);
778	/*
779	* …and one for FIELDS, which is a different problem. A text input
780	* already has a border to thicken and it sits in a column of other
781	* inputs, so the ring above — designed to survive landing on a
782	* bright mesh — reads as an alarm on a settings form. This one
783	* tightens the field's own edge to Pulse and puts a soft halo
784	* outside it: unmistakable, and quiet enough to live in a stack of
785	* twelve.
786	*/
787	--os-ui-focus-ring-field: 0 0 0 1px var(--os-ui-accent, #f252fc),
788	0 0 0 4px color-mix(in srgb, var(--os-ui-accent-dim) 16%, transparent);
789
790	/*
791	* The selected row of a VERTICAL `<os-tabs>`: the sidebar in
792	* OpenStation Preferences, and any native window that lays its
793	* pages down the side rather than across the top.
794	*
795	* Three layers, and the split is the whole point. Colour repeated
796	* down nine rows is wallpaper, so the accent is spent as a
797	* two-pixel EDGE and the row itself gets only a wash that falls
798	* away: it appears where it is cheap to look at and expensive to
799	* ignore.
800	*
801	* `-edge` is the accent the user picked, flat. It used to be
802	* Miomesh, and a mesh does hold up at 2px where a radial one
803	* would crop to an arbitrary lilac — but the edge is the loudest
804	* thing on the page that says "this row", and a row that says it
805	* in Pulse while the controls beside it say it in the chosen
806	* accent reads as two systems.
807	*
808	* `-wash` and `-bloom` are AMBIENT accent, so both resolve through
809	* `--os-ui-accent-dim` like every other glow in the kit. Turning
810	* the station down is still one edit. The Starlight stop in the
811	* middle of the wash is what keeps the row from reading as a pink
812	* smear: it lifts the surface under the label rather than tinting
813	* it, and it is gone by the time the row ends.
814	*/
815	--os-ui-tab-edge: linear-gradient(
816	var(--os-ui-accent, #f252fc),
817	var(--os-ui-accent, #f252fc)
818	);
819	--os-ui-tab-wash: linear-gradient(
820	90deg,
821	color-mix(in srgb, var(--os-ui-accent-dim) 16%, transparent) 0%,
822	rgba(255, 251, 255, 0.04) 42%,
823	transparent 100%
824	);
825	--os-ui-tab-bloom: linear-gradient(
826	90deg,
827	color-mix(in srgb, var(--os-ui-accent-dim) 26%, transparent),
828	transparent
829	);
830
831	/*
832	* ---- Motion --------------------------------------------------
833	*
834	* Four durations and three curves, and every animated thing in the
835	* kit picks from them. Not for tidiness: a panel where the switch
836	* settles in 220ms, the segmented thumb in 300 and the tab
837	* underline in 150 does not read as three well-tuned controls, it
838	* reads as one surface that cannot keep time.
839	*
840	* The scale is roughly logarithmic because perceived duration is:
841	* 90 and 140 are distinguishable, 220 and 240 are not.
842	*/
843	/* A state flip with no travel — a colour, an opacity, a tick. */
844	--os-ui-motion-fast: 140ms;
845	/*
846	* How long the foil takes to tilt, and the kit's default. One
847	* duration for every holographic transition, so a panel full of
848	* controls moves as one surface rather than as thirty independent
849	* ones.
850	*/
851	--os-ui-holo-transition: 220ms;
852	/* Something crossing a distance: a thumb, a drawer, a card. */
853	--os-ui-motion-slow: 340ms;
854	/* An ambient loop — a shimmer, a drift. Long enough to ignore. */
855	--os-ui-motion-ambient: 12s;
856
857	/*
858	* The curves. `spring` overshoots ~9% and settles; it is what makes
859	* a knob feel thrown rather than moved, and it is wrong for
860	* anything that changes size (an overshooting width reads as a
861	* glitch, not as weight).
862	*/
863	--os-ui-ease-spring: cubic-bezier(0.32, 1.5, 0.55, 1);
864	/* Decelerating. The default for anything arriving. */
865	--os-ui-ease-out: cubic-bezier(0.22, 0.9, 0.28, 1);
866	/*
867	* Accelerating — the mirror of `out`, and the default for anything
868	* LEAVING. A surface that eases out on the way in and eases in on
869	* the way out is the difference between "dismissed" and "undone":
870	* decelerating into nothing reads as the thing hesitating, which
871	* is the wrong note when the user has already moved on.
872	*/
873	--os-ui-ease-in: cubic-bezier(0.4, 0, 1, 1);
874	/* Symmetric, for a loop that has to come back where it started. */
875	--os-ui-ease-loop: cubic-bezier(0.45, 0, 0.55, 1);
876
877	/*
878	* Status. Derived, not quoted — see the header note. Info takes
879	* Sirius and success takes Holomesh's mint because the brand
880	* already has a colour that means those things; danger and warning
881	* are the shell's own hues lifted until they carry on Obsidian.
882	*/
883	--os-ui-danger: #ff5a5a;
884	--os-ui-danger-hover: #ff8a8a;
885	--os-ui-success-fg: #93f0c6;
886	--os-ui-warning-fg: #f8f2b6;
887	--os-ui-warning: #f8f2b6;
888	--os-ui-warning-bg: rgba(248, 242, 182, 0.1);
889	--os-ui-warning-border: rgba(248, 242, 182, 0.24);
890	--os-ui-info-fg: #c2f1f1;
891	--os-ui-info-bg: rgba(194, 241, 241, 0.1);
892
893	/*
894	* ---- Component tokens the palette cannot reach --------------
895	*
896	* Each of these is read with a literal of its own rather than a
897	* `var( --os-ui-<palette> )` chain, so the palette above does not
898	* carry to it. Everything else in the kit is left alone and
899	* inherits.
900	*/
901
902	/*
903	* Dialogs, menus and flyouts.
904	*
905	* The `--os-ui-modal-*` names below are the escape hatch
906	* `<os-modal>` needs. Its dialog surface is dark whatever the
907	* admin colour scheme says, so it re-points `--os-ui-fg`,
908	* `--os-ui-fg-muted`, `--os-ui-border`, `--os-window-bg` and
909	* `--os-ui-button-bg-hover` on its own `:host` — and a declaration
910	* on the host outranks anything the host inherits, which is how
911	* the palette used to stop at the dialog's edge. It reads these
912	* instead, so the station owns the dialog again and the literals
913	* behind them stay as the no-stylesheet floor.
914	*
915	* The set has to cover a dark context COMPLETELY, and the four
916	* added last are the ones that proved it. A dialog re-pointing
917	* only its text colours is fine while the palette around it is
918	* dark too — every unre-pointed token happens to agree. Put a
919	* LIGHT palette outside it (any theme in the admin's own colours,
920	* Legacy included) and the halves come apart: `--os-ui-surface`
921	* stays white, so `<os-select>` inside the dialog painted a white
922	* trigger and the re-pointed `--os-ui-fg` wrote near-white text
923	* onto it. `--os-ui-hover` was a black wash over a dark row.
924	*
925	* So the rule for anything added here: if a token names a SURFACE
926	* or a wash on one, the dialog owns it. Leaving one out is not
927	* "inherit the theme", it is "disagree with the other five".
928	*/
929	--os-ui-modal-bg: #1a1721;
930	--os-ui-modal-text: #fffbff;
931	--os-ui-modal-text-muted: #b3afb5;
932	--os-ui-modal-border: #4d4a52;
933	--os-ui-modal-field-bg: #33303a;
934	--os-ui-modal-button-bg-hover: rgba(255, 251, 255, 0.14);
935	--os-ui-modal-surface: #1a1721;
936	--os-ui-modal-surface-elevated: #33303a;
937	--os-ui-modal-border-strong: #4d4a52;
938	--os-ui-modal-hover: rgba(255, 251, 255, 0.06);
939	--os-ui-confirm-dialog-bg: #1a1721;
940	--os-ui-context-menu-bg: #1a1721;
941	--os-ui-context-menu-separator-color: rgba(255, 251, 255, 0.1);
942	--os-ui-flyout-shadow: 0 16px 48px rgba(0, 0, 0, 0.6);
943	--os-ui-card-shadow-hover: 0 4px 16px rgba(0, 0, 0, 0.45);
944	--os-ui-ribbon-shadow: 0 2px 4px rgba(0, 0, 0, 0.45);
945
946	/* Tables. */
947	--os-ui-table-bg: #1a1721;
948	--os-ui-table-header-bg: #33303a;
949	--os-ui-table-border: rgba(255, 251, 255, 0.1);
950	--os-ui-table-column-border: rgba(255, 251, 255, 0.16);
951	--os-ui-table-row-hover: rgba(255, 251, 255, 0.06);
952	--os-ui-table-stripe: rgba(255, 251, 255, 0.03);
953	--os-ui-table-sticky-edge: 2px solid rgba(255, 251, 255, 0.14);
954
955	/* Notices and badges — tinted washes of their own status colour. */
956	--os-ui-notice-error-bg: rgba(255, 90, 90, 0.12);
957	--os-ui-notice-error-border: rgba(255, 90, 90, 0.28);
958	--os-ui-notice-success-bg: rgba(147, 240, 198, 0.12);
959	--os-ui-notice-success-border: rgba(147, 240, 198, 0.28);
960	--os-ui-notice-warning-bg: rgba(248, 242, 182, 0.12);
961	--os-ui-notice-warning-border: rgba(248, 242, 182, 0.28);
962	--os-ui-notice-info-bg: rgba(194, 241, 241, 0.12);
963	--os-ui-notice-info-border: rgba(194, 241, 241, 0.28);
964	--os-ui-notice-neutral-bg: rgba(255, 251, 255, 0.06);
965	--os-ui-notice-neutral-border: rgba(255, 251, 255, 0.14);
966	/*
967	* A link inside a notice reads Nebula, the same value `--os-link`
968	* gives every other shell link — NOT the accent.
969	*
970	* Undeclared, the base fell through to `--wp-admin-theme-color`,
971	* which OpenStation Preferences → Appearance writes inline on `<html>`
972	* from the accent picker. That made the one piece of text a notice
973	* most needs the user to read take whichever hue they chose for
974	* focus rings. An accent is an identity colour; legibility on a dark
975	* surface is not something it can promise, so the link stops asking
976	* it to. Hover lifts to Starlight, and both ends stay in the palette.
977	*
978	* These are consumed from a DOCUMENT-tree rule in `desktop.css`, not
979	* only from the component's own `::slotted( a )`. See the comment
980	* there: a slotted link is a document-tree element, so wp-admin's
981	* bare `a` rule outranks anything the shadow root says about it.
982	*/
983	--os-ui-notice-link: #ec9bff;
984	--os-ui-notice-link-hover: #fffbff;
985	--os-ui-badge-danger-bg: rgba(255, 90, 90, 0.16);
986	--os-ui-badge-success-bg: rgba(147, 240, 198, 0.16);
987	--os-ui-badge-warning-bg: rgba(248, 242, 182, 0.16);
988	--os-ui-badge-info-bg: rgba(194, 241, 241, 0.16);
989	--os-ui-badge-neutral-bg: rgba(255, 251, 255, 0.08);
990
991	/*
992	* Fills that must stay fills. Each of these paints a solid shape —
993	* a ribbon, a chip, a focused input's edge — and each was reading
994	* a token the palette turned into a 10%-alpha wash or into the
995	* body colour itself. A ribbon the same colour as the card behind
996	* it is not a subtle ribbon, it is a missing one.
997	*/
998	/*
999	* Text on the bright status fills. These are the surfaces the
1000	* `--os-ui-fg-on-accent` note points at: a ribbon filled with Pulse,
1001	* Sirius or Holomesh mint is a LIGHT surface, and Starlight on it
1002	* disappears.
1003	*/
1004	--os-ui-ribbon-fg: #0c0b0f;
1005	--os-ui-step-chip-fg: #0c0b0f;
1006	/*
1007	* The step chip is the right size and shape for the mesh: a small
1008	* round fill, one per row, already carrying dark text. Its
1009	* `--os-ui-step-chip-fg` above is Void, which is what the mesh
1010	* needs anyway — the two decisions were made independently and
1011	* agree, which is usually the sign a palette is holding together.
1012	*/
1013	--os-ui-step-chip-bg: var(--os-mesh-holo);
1014
1015	/*
1016	* The default ribbon. One per tile, small, angled, and already
1017	* paired with Void ink above — which is what a mesh needs anyway.
1018	* The status ribbons below keep their flat colours: a ribbon that
1019	* says "deprecated" should say it in warning yellow, not in brand.
1020	*/
1021	--os-ui-ribbon-bg: var(--os-mesh-holo);
1022
1023	--os-ui-ribbon-info: #c2f1f1;
1024	--os-ui-ribbon-warning: #f8f2b6;
1025	--os-ui-ribbon-neutral: #4d4a52;
1026	--os-ui-crumb-bg: #33303a;
1027	--os-ui-tag-input-input-border: #f252fc;
1028
1029	/*
1030	* Pairs that have to stay distinguishable. Hover and pressed, or
1031	* base and shimmer, both resolve through `--os-ui-hover` — one wash
1032	* for two states reads as a dead control, so the second step of
1033	* each pair is named.
1034	*/
1035	--os-ui-btn-bg-active: rgba(255, 251, 255, 0.12);
1036	/*
1037	* `<os-button>` ghost + secondary. Their resting wash and their
1038	* hover wash BOTH fall through to `--os-ui-hover` — in two different
1039	* rules, with two different literals behind them (6% and 10%), so
1040	* declaring the palette collapsed them onto one value and the
1041	* buttons stopped reacting to the pointer entirely. Primary is
1042	* unaffected: it hovers with `filter: brightness()` over its
1043	* accent fill rather than through this token.
1044	*/
1045	--os-ui-button-bg-hover: rgba(255, 251, 255, 0.14);
1046	--os-ui-key-bg-hover: rgba(255, 251, 255, 0.1);
1047	--os-ui-key-bg-pressed: rgba(255, 251, 255, 0.16);
1048	--os-ui-table-skeleton-highlight: rgba(255, 251, 255, 0.14);
1049
1050	/* Code, logs, progress, ratings, avatars. */
1051	--os-ui-code-border: 1px solid rgba(255, 251, 255, 0.1);
1052	--os-ui-log-border: 1px solid rgba(255, 251, 255, 0.08);
1053	--os-ui-log-row-border: 1px solid rgba(255, 251, 255, 0.06);
1054	--os-ui-progress-track-bg: rgba(255, 251, 255, 0.1);
1055	/*
1056	* The filled part of a progress bar is the one surface in the kit
1057	* that is already a hero: bounded, watched, and the only thing
1058	* moving on screen. So it takes Holomesh, and the bar stretches
1059	* the mesh as it grows — the hue travelling from lavender toward
1060	* cyan IS the progress, which a flat accent could only report.
1061	*
1062	* Retinted here rather than in `<os-progress-bar>` because the
1063	* component's own literal has to stay the pre-brand WordPress blue
1064	* (it is the no-stylesheet floor, and it is what Legacy collected).
1065	* The tone modifiers — success, warning, danger — still declare
1066	* flat colours and still win: a failing job should read as red, not
1067	* as brand.
1068	*/
1069	--os-ui-progress-fill: var(--os-mesh-holo);
1070	--os-ui-rating-star: #f8f2b6;
1071	--os-ui-rating-fill: linear-gradient(90deg, #f8f2b6 0%, #fffbff 100%);
1072	--os-ui-avatar-dot-ring: #1a1721;
1073	/* The avatar's hover halo. It was a fixed indigo — a hue no
1074	palette in the station names — so it lit itself in a colour
1075	nothing around it used. Pulse. */
1076	--os-ui-avatar-halo: #f252fc;
1077	/* Search-match highlight inside a label. A WASH, not a fill: the
1078	text keeps its own colour, so the wash has to stay light enough
1079	for Starlight to carry over it. */
1080	--os-ui-search-highlight-bg: rgba(248, 242, 182, 0.3);
1081	/*
1082	* The content graph's cluster hue is NOT retinted. Graph node
1083	* colours are composed artwork that encodes meaning — the docs list
1084	* them under "what stays fixed" — and moving this one to Nebula put
1085	* white cluster labels on a pale lilac chip at 1.9:1. It keeps its
1086	* own colour, and the label keeps carrying on it.
1087	*
1088	* The graph's toolbar is chrome, though, and it does follow. The
1089	* count pill on an ACTIVE filter chip is a 70%-white fill, and it
1090	* was carrying `--os-ui-accent-strong` numerals — Nebula on white,
1091	* ~1.7:1. It is one more bright fill naming its own dark text, the
1092	* same escape hatch `--os-ui-ribbon-fg` and `--os-ui-step-chip-fg`
1093	* take, and for the same reason.
1094	*/
1095	--os-ui-cg-chip-count-fg-active: #0c0b0f;
1096
1097	/*
1098	* ---- The widget card's public token contract ----------------
1099	*
1100	* Five names a third-party widget stylesheet is told to read.
1101	* The list lives in `src/plugins/starter-widget/styles.css`,
1102	* which is the file plugin authors copy — so it is a contract,
1103	* not a convenience, and four of the five were documented
1104	* without ever being declared. Every consumer fell through to
1105	* the light-mode grey in its own `var()` fallback, on a card
1106	* whose glass is dark: Post Stats' metadata measured 3.81:1
1107	* where `.os-widgets__title` on the same surface measures 18.4.
1108	*
1109	* They are mostly literals rather than aliases of the text ramp,
1110	* and that is the point. `.os-widgets__card` paints a fixed dark
1111	* glass — `--os-ui-color-surface` below IS that colour, and the
1112	* card reads it — under every desktop theme, so a name that
1113	* flips with the theme is the wrong chain here: Legacy's
1114	* `--os-ui-fg-muted` is `#50575e`, which lands at 2.54:1 on the
1115	* glass and makes the bug WORSE for anyone wearing it. The two
1116	* text names below do chain, but through the two names Legacy
1117	* keeps light — the ones describing the same on-dark chrome
1118	* this card is.
1119	*
1120	* A theme that wants to move a widget card declares these names
1121	* itself, the way Legacy already declares the accent.
1122	*/
1123	--os-ui-color-surface: rgba(20, 20, 22, 0.55);
1124	/* What the card's own `color` already resolves to — so a widget
1125	asking for "primary text" gets the text it inherited. */
1126	--os-ui-color-text: var(--os-ui-fg-on-accent, #fffbff);
1127	/* The shell's muted-on-dark. 9.2:1 on the glass, and Legacy
1128	keeps it at `rgba( 255, 255, 255, 0.7 )`. */
1129	--os-ui-color-text-subtle: var(--os-fg-muted, rgba(255, 251, 255, 0.7));
1130	/* A hairline INSIDE the card, so a touch stronger than the
1131	card's own 0.08 edge, which is drawn against the wallpaper.
1132	Literal because no general on-dark hairline exists: the ones
1133	Legacy keeps light are `--os-dock-border` and
1134	`--os-cn-border`, and borrowing either is the right value at
1135	the wrong scope. It reads quieter than what it replaces —
1136	the widgets' own fallback was `#e5e7eb`, a light-theme
1137	divider that on dark glass drew the loudest line in the
1138	station. 0.12 is what the window and dock edges use. */
1139	--os-ui-color-border: rgba(255, 251, 255, 0.12);
1140	/* The one name that has to reach the accent picker. It was a
1141	hard `#f252fc`, so a widget told to "use the accent for
1142	buttons and links" stayed brand pink after the user chose
1143	teal, while every control around it moved. */
1144	--os-ui-color-accent: var(--os-ui-accent, #f252fc);
1145
1146	/*
1147	* ---- Typography --------------------------------------------
1148	*
1149	* Geist for everything human — headlines, UI copy, body text — and
1150	* Geist Mono for the instrument voice: labels, metadata, statuses,
1151	* code. Both faces are declared above; a stack without them still
1152	* reads correctly, which is why every entry ends in a generic
1153	* family.
1154	*
1155	* The chrome / body split is the one real decision here, and it is
1156	* the one real desktop environments make. Here both sides run
1157	* Geist: the station is one surface, and the title bar is not a
1158	* different product from the window under it.
1159	*
1160	* Note that iframe windows render a real wp-admin document in a
1161	* separate browsing context that this stylesheet does not reach —
1162	* these tokens style the shell and native windows.
1163	*/
1164	--os-font: 'Geist', system-ui, sans-serif;
1165	--os-titlebar-font: 'Geist', system-ui, sans-serif;
1166	--os-ui-font: 'Geist', system-ui, sans-serif;
1167	--os-ui-font-mono: 'Geist Mono', ui-monospace, monospace;
1168
1169	/*
1170	* ---- Desktop-theme texture family -------------------------
1171	*
1172	* These are DELIBERATELY not declared. Every rule that consumes
1173	* one reads it as `var( --name, <initial> )`, so an unset variable
1174	* resolves to the CSS initial value and costs exactly nothing.
1175	* Declaring them with `none` up here would be equivalent but would
1176	* imply they are part of the default palette — they are not. They
1177	* exist only while an uploaded or code-registered desktop theme is
1178	* active, and only the compiled theme stylesheet ever sets them.
1179	*
1180	* TITLEBAR --os-titlebar-image
1181	* --os-titlebar-image-repeat
1182	* --os-titlebar-image-size
1183	* TITLEBAR_FOCUSED --os-titlebar-image-focused
1184	* (falls back to the unfocused image)
1185	* WINDOW_FRAME --os-window-border-image-source
1186	* --os-window-border-image-slice
1187	* --os-window-border-image-width
1188	* --os-window-border-image-repeat
1189	* WINDOW_CORNER_* --os-window-corner-{ne,nw,se,sw}-image
1190	* --os-window-corner-size (shared)
1191	* --os-window-corner-inset (shared;
1192	* how far inside the rounded corner the
1193	* ornament sits. Defaults to the resize
1194	* handle's 3px overhang plus a share of
1195	* --os-window-radius, because the
1196	* window clips its descendants)
1197	* WINDOW_FRAME_FOCUSED
1198	* --os-window-border-image-focused-*
1199	* (same four sub-properties as WINDOW_FRAME)
1200	* WINDOW_BODY --os-window-body-image
1201	* TABBAR --os-tabs-image
1202	* TITLEBAR_CONTROLS --os-titlebar-controls-image
1203	* TITLEBAR_BUTTON --os-ui-btn-bg-image
1204	* DOCK --os-dock-bg-image
1205	* --os-dock-bg-image-repeat
1206	* --os-dock-bg-image-size
1207	* DOCK_ITEM --os-dock-item-image
1208	* DESKTOP --os-desktop-image
1209	* --os-desktop-image-repeat
1210	* --os-desktop-image-size
1211	* ICON_TILE --os-tile-image
1212	* WIDGET --os-widget-image
1213	* MENU --os-ui-menu-bg-image
1214	* DIALOG --os-ui-dialog-bg-image
1215	* SCRIM --os-ui-scrim-image
1216	* PANEL --os-ui-panel-bg-image
1217	* TOAST --os-ui-toast-bg-image
1218	* TABLE_HEADER --os-ui-table-header-bg-image
1219	* BUTTON --os-ui-button-bg-image
1220	*
1221	* Every `image` slot also gets `<prop>-repeat` and `<prop>-size`
1222	* companions (the corners share one `-size`, and
1223	* TITLEBAR_FOCUSED inherits TITLEBAR's).
1224	*
1225	* Consumers: window-chrome.css (titlebar, frame, body, tab bar),
1226	* window-states.css (corners), dock.css, desktop.css (wallpaper,
1227	* icons, widgets), and the `<os-*>` component stylesheets under
1228	* `src/ui/components/` for the last seven.
1229	* Authoring reference: docs/desktop-themes.md.
1230	*/
1231
1232	/*
1233	* ---- Badges ----------------------------------------------
1234	*
1235	* Sizes stay undeclared and DERIVED: every badge sizes itself off
1236	* the icon it decorates — the dock badge off
1237	* `--os-dock-icon-size`, the wallpaper badges off
1238	* `--os-icon-image-size` — so a user who picks a large
1239	* dock, or a theme that scales its icons, doesn't end up with a
1240	* speck stuck to an oversized tile.
1241	*
1242	* Dock --os-dock-badge-size (overrides the
1243	* whole derivation; font + padding follow it)
1244	* --os-dock-badge-font-size / -padding
1245	* --os-dock-badge-offset / -bg / -fg
1246	* --os-dock-badge-font-weight
1247	* Desktop icon --os-icon-badge-size / -font-size
1248	* --os-icon-badge-padding / -bg / -fg
1249	* Recycle bin --os-recycle-badge-size / -font-size
1250	* / -bg / -fg. Falls through to the generic
1251	* icon-badge token, so "badges are 22px" reaches
1252	* the bin too.
1253	*
1254	* The count badges wear Pulse, and wear it as a LITERAL gradient:
1255	* both stops used to resolve through `--os-ui-danger`, which the
1256	* palette moved, flattening the badge to one flat fill and turning
1257	* its numerals Void by accident. Naming the stops here keeps it a
1258	* gradient on purpose. The bin's neutral badge is deliberately not
1259	* part of this: a count of things in the trash is ambient state,
1260	* not something asking for you.
1261	*
1262	* **The numerals are Void, not Starlight, and that is a
1263	* requirement rather than a preference.** Starlight on Pulse is
1264	* 2.9:1, which fails AA for text this small; Void on Pulse is
1265	* 6.8:1. Any future retint of these has to keep the pair legible,
1266	* so check the ratio before swapping the ink back to white.
1267	*/
1268	--os-dock-badge-bg: linear-gradient(180deg, #f97dff 0%, #f252fc 100%);
1269	--os-dock-badge-fg: #0c0b0f;
1270	--os-icon-badge-bg: linear-gradient(180deg, #f97dff 0%, #f252fc 100%);
1271	--os-icon-badge-fg: #0c0b0f;
1272	--os-recycle-badge-bg: rgba(26, 23, 33, 0.85);
1273	--os-recycle-badge-fg: rgba(255, 251, 255, 0.96);
1274	--os-dock-recycle-badge-bg: rgba(26, 23, 33, 0.85);
1275	--os-dock-recycle-badge-fg: rgba(255, 251, 255, 0.92);
1276
1277	/*
1278	* ---- Tooltips ---------------------------------------------
1279	*
1280	* Two tokens own every tooltip CHIP in the shell — the dock tile
1281	* tooltip and the content-graph satellite tooltip.
1282	*
1283	* They are worth naming rather than leaving derived. Without them
1284	* tooltips borrow their colours from unrelated families —
1285	* `--os-ui-scrim` (an overlay BACKDROP) or `--os-ui-surface-elevated`
1286	* for the surface, `--os-ui-fg-on-accent` for the text — and those
1287	* pairings come apart the moment the palette moves. On this
1288	* palette `--os-ui-fg-on-accent` is Void, which would have rendered
1289	* near-black text on a near-black chip.
1290	*
1291	* A chip is deliberately the SAME dark lozenge on every desktop
1292	* theme, which is why these two are flat values and not derived
1293	* from anything. That is right for one line of text pinned to a
1294	* control, and wrong for a rich card: the My WordPress entity
1295	* hover card used to read them and showed up Obsidian over a white
1296	* Legacy window. It has its own derived family now —
1297	* `--os-my-wordpress-card-*`, further down — and it still names
1298	* these two as its last fallback.
1299	*/
1300	--os-tooltip-bg: #33303a;
1301	--os-tooltip-fg: #fffbff;
1302
1303	/*
1304	* ---- Dock --------------------------------------------------
1305	*
1306	* Void glass over the desk, with a Starlight hairline. The tile
1307	* hover wash and the focus ring are the dock's identity moment:
1308	* Pulse, at the two alphas that read as "warm" and "here".
1309	*
1310	* `--os-dock-icon-color` is a COLOUR, not a fill, and
1311	* that is load-bearing: every image glyph in the dock is painted
1312	* as a mask filled with this colour — a theme's own iconset via
1313	* `"iconColor": "currentColor"`, and plugin / CPT artwork via
1314	* `currentColor` on the tile. One token drives dashicons, theme
1315	* art, plugin art, and the hover transition between them.
1316	*
1317	* Consumers: dock.css, dock-peek.css (which re-states the hover
1318	* rule and so must read the same two tokens).
1319	*/
1320	--os-dock-width: 56px;
1321	--os-dock-icon-size: 20px;
1322	/*
1323	* The indicator line a dynamic dock collapses into while parked
1324	* (Preferences → Appearance → Desktop layout → Dock behavior):
1325	* the iOS home indicator, painted in the accent at partial alpha
1326	* so it reads as a mark on the wallpaper rather than a control.
1327	* `-length` runs along the rail's edge, `-thickness` across it; a
1328	* theme retunes any of the three.
1329	*/
1330	--os-dock-indicator-length: 180px;
1331	--os-dock-indicator-thickness: 5px;
1332	--os-dock-indicator-bg: color-mix( in srgb, var( --os-ui-accent, #f252fc ) 72%, transparent );
1333	--os-dock-bg: rgba(12, 11, 15, 0.72);
1334	--os-dock-icon-color: rgba(255, 251, 255, 0.72);
1335	--os-dock-icon-color-hover: #fffbff;
1336	--os-dock-item-bg-hover: rgba(242, 82, 252, 0.18);
1337	/*
1338	* The status indicator and the focus ring, and both say "this
1339	* one" about a tile the user chose — so they read the accent
1340	* rather than a fixed Pulse. Pulse is still what an untouched
1341	* install shows, because that is what the picker starts on.
1342	*/
1343	--os-dock-item-outline: var(--os-ui-accent, #f252fc);
1344	/*
1345	* Hairline between the dock and the desktop. Reaches the side
1346	* placements (as a single inline-edge border) AND the floating
1347	* bottom pill (as its full outline). Set `transparent` for a
1348	* borderless dock.
1349	*
1350	* The bottom pill's own chrome is separately overridable, because
1351	* it is deliberately a different piece of glass — a warmer tint, a
1352	* brighter top edge, an inset highlight, a drop shadow. Each falls
1353	* back to the shared value above it.
1354	*/
1355	--os-dock-border: rgba(255, 251, 255, 0.1);
1356
1357	/*
1358	* The dividers INSIDE the rail, which are a different job from the
1359	* outline around it: they separate tiles that belong to different
1360	* groups — core menus, plugin apps, and OpenStation's own controls.
1361	*
1362	* One treatment for all of them. An earlier pass gave the
1363	* WordPress-to-OpenStation boundary Pulse and dropped the
1364	* core-to-plugin one to a hairline, on the theory that only one
1365	* boundary was worth reading. Two weights in one short rail read as
1366	* two unrelated ideas instead of one system, so both are now the
1367	* same line: Pulse at the waist, falling away to nothing at both
1368	* ends, with a soft glow to hold it against the dock tint.
1369	*
1370	* Resolved one step back from the accent through
1371	* `--os-ui-accent-dim`, where every ambient use of Pulse resolves,
1372	* so "tone the station down" stays one edit.
1373	*/
1374	--os-dock-divider: color-mix(in srgb, var(--os-ui-accent-dim) 70%, transparent);
1375	--os-dock-floating-bg: rgba(12, 11, 15, 0.62);
1376	--os-dock-floating-border: rgba(255, 251, 255, 0.12);
1377	--os-dock-floating-border-top: rgba(255, 251, 255, 0.18);
1378	--os-dock-floating-highlight: rgba(255, 251, 255, 0.1);
1379	--os-dock-floating-shadow: rgba(0, 0, 0, 0.55);
1380
1381	/*
1382	* The phone layer (`mobile.css`). Its surfaces are the dock's
1383	* family — translucent glass over the wallpaper, light glyphs —
1384	* and read the dock tokens above for fill, text and lines. What
1385	* the dock has no word for is declared here: the glass a tile, a
1386	* round control and a switcher card are cut from, its pressed
1387	* state, the shadow under a tile, the scrim behind the switcher,
1388	* and the label shadow that keeps text legible over any wallpaper.
1389	* A desktop theme that reskins the dock reskins the phone with it;
1390	* one that wants the phone alone has these.
1391	*/
1392	--os-mobile-glass: rgba(255, 251, 255, 0.1);
1393	--os-mobile-glass-strong: rgba(255, 251, 255, 0.16);
1394	--os-mobile-glass-border: rgba(255, 251, 255, 0.14);
1395	--os-mobile-tile-shadow: 0 8px 20px rgba(0, 0, 0, 0.35);
1396	--os-mobile-card-shadow: 0 -8px 24px rgba(0, 0, 0, 0.4);
1397	--os-mobile-sheet-shadow: 0 -12px 40px rgba(0, 0, 0, 0.45);
1398	--os-mobile-window-shadow: 0 12px 32px rgba(0, 0, 0, 0.45);
1399	--os-mobile-scrim: rgba(0, 0, 0, 0.55);
1400	--os-mobile-top-scrim: rgba(0, 0, 0, 0.45);
1401	--os-mobile-label-shadow: 0 1px 2px rgba(0, 0, 0, 0.6);
1402
1403	/*
1404	* ---- The OpenStation layout ---------------------------------
1405	*
1406	* The constellation: the flyout that fans a menu's submenu out of
1407	* its tile on hover, on every rail in every layout. The rail's
1408	* divider used to live here too; it is shared chrome now and reads
1409	* through `--os-dock-divider`.
1410	*
1411	* The constellation's SURFACE is Obsidian, deliberately. The mesh
1412	* is spent on the row under the pointer and on the head's icon
1413	* halo — the two moments where the panel is answering the user —
1414	* and nowhere else. A flyout that was iridescent edge to edge
1415	* would have nothing left to say when you actually pointed at
1416	* something in it.
1417	*/
1418	--os-cn-surface: rgba(26, 23, 33, 0.82);
1419	--os-cn-border: rgba(255, 251, 255, 0.14);
1420	--os-cn-shadow: 0 24px 64px rgba(0, 0, 0, 0.62),
1421	0 2px 8px rgba(0, 0, 0, 0.4);
1422	--os-cn-fg: #fffbff;
1423	--os-cn-fg-muted: rgba(255, 251, 255, 0.62);
1424	--os-cn-legend: rgba(255, 251, 255, 0.4);
1425	--os-cn-divider: rgba(255, 251, 255, 0.1);
1426	/* The row under the pointer — the panel's identity moment. */
1427	--os-cn-row-fill: var(--os-ui-holo-fill);
1428	--os-cn-row-ink: var(--os-ui-holo-ink);
1429	/* Beam: the thread from the panel's underside down to the tile. */
1430	--os-cn-beam: color-mix(in srgb, var(--os-ui-accent-dim) 80%, transparent);
1431	--os-cn-radius: 14px;
1432	/*
1433	* Above every window and above the dock. Two panels coexist while
1434	* the pointer moves along the rail — one dismissing, one arriving
1435	* — and the retiring one is painted one step below so it can
1436	* never fade out on top of the menu being read.
1437	*/
1438	--os-cn-z: 2147483000;
1439
1440	/*
1441	* ---- Shell surfaces ----------------------------------------
1442	*
1443	* The panels, tab strips and washes that belong to the shell
1444	* rather than to the component kit. Same Obsidian-on-Void
1445	* composition; the selection wash is Pulse.
1446	*/
1447	--os-accent: #f252fc;
1448	--os-link: #ec9bff;
1449	--os-danger: #ff5a5a;
1450	--os-border: rgba(255, 251, 255, 0.1);
1451	--os-hover: rgba(255, 251, 255, 0.06);
1452	--os-selected: rgba(242, 82, 252, 0.18);
1453	--os-fg-muted: rgba(255, 251, 255, 0.7);
1454	/*
1455	* Shell text. Undeclared before the brand and it had to be: it read
1456	* light on the desk (tile labels over the wallpaper) and dark
1457	* inside a window, and one value broke one of the two. The station
1458	* settles the argument — every surface it owns is dark now, so
1459	* Starlight is right in both places.
1460	*/
1461	--os-fg: #fffbff;
1462	/*
1463	* "…on light" is a name from before the station, and it is now a
1464	* misnomer worth keeping: every surface that reads it — the folder
1465	* window, its preview pane, the upload HUD — was a light card and
1466	* is Obsidian today. The token means "text on the surfaces this one
1467	* names", and those surfaces are dark, so the text is Starlight.
1468	* Renaming it is a public-API change for the sake of tidiness; the
1469	* comment is cheaper and the behaviour is what matters.
1470	*/
1471	--os-fg-on-light: #fffbff;
1472	--os-panel-bg: #1a1721;
1473	--os-panel-header-bg: rgba(255, 251, 255, 0.04);
1474	--os-folder-window-bg: #1a1721;
1475	--os-my-wordpress-bg: #1a1721;
1476	--os-my-wordpress-fg: #fffbff;
1477	--os-my-wordpress-surface: rgba(255, 251, 255, 0.06);
1478	/*
1479	* The entity hover card — the "thumb" that floats over a tile with
1480	* a title, a featured image and an excerpt.
1481	*
1482	* It is NOT a dock chip, and it used to be painted as one.
1483	* `--os-tooltip-bg` is a fixed dark lozenge on every theme by
1484	* design — one line of text, always the same object, no reason to
1485	* follow anything. The card borrowed it, so a light desktop theme
1486	* summoned an Obsidian card over a white window, with a border in
1487	* `--os-ui-border` and an excerpt in `--os-ui-fg-muted` that both
1488	* followed the WINDOW instead. Three families, one surface.
1489	*
1490	* The card is window furniture: it belongs to the surface it was
1491	* summoned from, so it follows the theme that paints that surface.
1492	* Every value below is DERIVED rather than declared flat, which is
1493	* what makes that true — a theme that names only
1494	* `--os-my-wordpress-bg` (Legacy names exactly that, `#fff`) moves
1495	* the card with the window for free, and a theme that wants the
1496	* card alone names a `-card-` token.
1497	*
1498	* A card lands on the same colour as the window under it, so the
1499	* border and the shadow are the whole reason it reads as a
1500	* separate object. Neither is decoration here and neither may
1501	* collapse into the background — which is exactly what the border
1502	* did: `--os-ui-border` is #33303a on this palette, the SAME value
1503	* `--os-tooltip-bg` had, so the card had no edge at all.
1504	*
1505	* The shadow is the one flat value in the family. A drop shadow is
1506	* cast light, dark on a light theme and dark on a dark one, so
1507	* there is no window token for it to follow; it is named so a
1508	* theme can still reach it.
1509	*/
1510	--os-my-wordpress-card-bg: var(--os-my-wordpress-bg, #1a1721);
1511	--os-my-wordpress-card-fg: var(--os-my-wordpress-fg, #fffbff);
1512	--os-my-wordpress-card-fg-muted: var(--os-ui-fg-muted, #b3afb5);
1513	--os-my-wordpress-card-border: var(--os-ui-border, #33303a);
1514	--os-my-wordpress-card-shadow: 0 8px 28px rgba(0, 0, 0, 0.45);
1515	--os-my-wordpress-card-thumb-bg: var(
1516	--os-media-tile-bg,
1517	rgba(255, 251, 255, 0.05)
1518	);
1519	--os-my-wordpress-card-lock-bg: var(
1520	--os-ui-badge-danger-bg,
1521	rgba(255, 90, 90, 0.16)
1522	);
1523	--os-ai-panel-bg: rgba(26, 23, 33, 0.97);
1524	/*
1525	* ---- Window tab strip ---------------------------------------
1526	*
1527	* A window with sub-pages reads as three surfaces stacked in
1528	* depth, and the values below are that ramp: Astro on the focused
1529	* title bar, VOID for the track the tabs sit in, then the page
1530	* itself. The track is the darkest of the three on purpose — it
1531	* has to stay a distinct band under BOTH title-bar states, and
1532	* Obsidian would collapse into the unfocused bar (also Obsidian)
1533	* exactly when a window has the least going on to distinguish it.
1534	*
1535	* The active tab is not a colour, it is the page arriving early.
1536	* `chromeless.css` paints every admin page inside a window `#fff`
1537	* whatever the admin colour scheme says, so the tab can name that
1538	* white and the joint between the two is seamless. Retinting the
1539	* tab means retinting the page it belongs to, and these two move
1540	* together or the seam comes back.
1541	*
1542	* `-color-muted` is the second tone anything nested in an active
1543	* tab needs — the external tab's detach and close chips. It is
1544	* the only reason a "muted on light" value exists this far down a
1545	* dark palette.
1546	*/
1547	--os-tabs-bg: #1a1721;
1548	/*
1549	* The track on an UNFOCUSED window, which follows the title bar
1550	* down to Void rather than holding Obsidian.
1551	*
1552	* A focused window already reads as two surfaces: title bar and
1553	* track are the same Obsidian, and the tab lifts out of them. Let
1554	* the track keep that Obsidian while the bar above it dims and
1555	* the window reads as THREE, with the strip belonging to neither
1556	* the chrome above nor the page below. Following the bar down
1557	* keeps the count at two in both states.
1558	*
1559	* Both tracks read this: the shell's strip on an iframe window,
1560	* and `<os-tabs variant="window">` inside a native one. The track
1561	* is chrome in both cases, so it dims with the chrome; what keeps
1562	* the tab attached to the content while that happens is the
1563	* plate's fill, which wears the body's own colour rather than the
1564	* track's.
1565	*
1566	* Note the asymmetry with the title bar's pair, which is
1567	* deliberate: there, `--os-titlebar-bg` is the unfocused base and
1568	* `-focused` is the modifier. Here the base is the LIT value,
1569	* so a theme naming one track colour lands on the state where the
1570	* track is doing the most work.
1571	*
1572	* A theme that sets only `--os-tabs-bg` (Legacy, and anything
1573	* written before this token existed) resolves through it in both
1574	* states and keeps its single strip colour.
1575	*/
1576	--os-tabs-bg-unfocused: #0c0b0f;
1577	--os-tabs-color: #b3afb5;
1578	--os-tabs-active-bg: #fff;
1579	--os-tabs-active-color: #0c0b0f;
1580	--os-tabs-active-color-muted: rgba(12, 11, 15, 0.6);
1581	/*
1582	* The plate's own body: a frosted crown resolving to flat page
1583	* white well before the joint.
1584	*
1585	* Every stop is OPAQUE, and that is a requirement rather than a
1586	* preference. The face used to be translucent over a
1587	* `backdrop-filter`, which promotes it to its own compositor layer
1588	* and leaves a faint grey hairline where that layer is clipped —
1589	* down the plate's sides and across its bottom, which is precisely
1590	* where this design has a bright rail and needs everything else to
1591	* be invisible.
1592	*
1593	* The last stop must also land above the joint (the bottom
1594	* `--os-tabs-radius` of the plate), because the joint is painted
1595	* in flat `--os-tabs-active-bg` and a body still tinted where the
1596	* two meet draws a seam of its own. If you retune these stops,
1597	* check the bottom edge first.
1598	*/
1599	--os-tabs-active-frost: linear-gradient(
1600	180deg,
1601	#f4eff9 0%,
1602	#ffffff 58%
1603	);
1604	/*
1605	* The crown. Holomesh, masked away before the joint for the same
1606	* reason. It is on exactly ONE tab at a time — that is what keeps
1607	* the mesh an identity moment instead of wallpaper, and it is the
1608	* rule the rest of the kit follows. Set it to `none` to get the
1609	* plain frosted plate back.
1610	*/
1611	--os-tabs-active-crown: var(--os-mesh-holo);
1612	--os-tabs-active-crown-opacity: 0.3;
1613	/*
1614	* The rail: one continuous line around the silhouette of
1615	* page-plus-tab.
1616	*
1617	* This is the one place the accent is spent on the tab strip, and
1618	* spending it here is what lets the tab itself stay uncoloured —
1619	* so it is the accent the user picked, flat, and not Pulsemesh.
1620	* A mesh here would be the accent everywhere else on the tab
1621	* strip disagreeing with the one line that carries it. Written as
1622	* a gradient rather than a colour because the rail is painted as
1623	* a background-image through a mask.
1624	*
1625	* Set it to `none` for the plain frosted plate with no line.
1626	*/
1627	--os-tabs-rail: linear-gradient(
1628	var(--os-ui-accent, #f252fc),
1629	var(--os-ui-accent, #f252fc)
1630	);
1631	--os-tabs-rail-width: 2px;
1632	--os-media-tile-bg: rgba(255, 251, 255, 0.05);
1633	--os-media-visual-bg: rgba(255, 251, 255, 0.04);
1634	--os-skeleton-low: rgba(255, 251, 255, 0.05);
1635	--os-skeleton-high: rgba(255, 251, 255, 0.13);
1636	--os-drop-preview-bg: rgba(242, 82, 252, 0.1);
1637	--os-drop-preview-border: rgba(242, 82, 252, 0.55);
1638
1639	/*
1640	* File tiles — anywhere a `.os-file-tile` (or sibling
1641	* canvas tile) renders. The defaults match the desk: Starlight
1642	* labels over a dark sky, with a Pulse selection wash.
1643	*
1644	* Surfaces that are light in their own right override these in
1645	* their own scope, e.g.:
1646	*
1647	* .desktop-mode-folder-window {
1648	* --os-tile-fg: #1d2327;
1649	* --os-tile-hover-bg: rgba(0, 0, 0, 0.06);
1650	* }
1651	*
1652	* Plugin authors can override any of these in their own theme
1653	* to retint tiles globally without touching the rules below.
1654	*/
1655	--os-tile-fg: var(--os-fg, #fffbff);
1656	--os-tile-fg-muted: rgba(255, 251, 255, 0.7);
1657	--os-tile-hover-bg: rgba(255, 251, 255, 0.12);
1658	--os-tile-selected-bg: rgba(242, 82, 252, 0.24);
1659	--os-tile-focus-ring: var(--wp-admin-theme-color, #f252fc);
1660	--os-tile-shortcut-bg: rgba(12, 11, 15, 0.7);
1661	--os-tile-shortcut-fg: #fffbff;
1662	--os-tile-shortcut-shadow: 0 1px 3px rgba(0, 0, 0, 0.6);
1663
1664	/*
1665	* Label rendering tokens. The desk is dark at every wallpaper, so
1666	* a soft drop-shadow boosts legibility against the artwork,
1667	* regular weight, default antialiasing.
1668	*
1669	* Light-context surfaces (folder windows, My WordPress, any
1670	* future window with a light body) rebind these in their own
1671	* scope so tile labels render with the same crispness as the
1672	* surrounding chrome — no per-surface duplicate rules.
1673	*/
1674	--os-tile-label-shadow: 0 1px 2px rgba(0, 0, 0, 0.6);
1675	--os-tile-label-weight: 400;
1676	--os-tile-label-smoothing: auto;
1677	--os-tile-label-color: var(--os-tile-fg);
1678
1679	/*
1680	* Admin bar — how many pixels of the bar stay on screen while it
1681	* is parked off the top edge in `dynamic` mode. This is the
1682	* VISIBLE seam only: small enough to read as "nothing is there".
1683	* Themes may retune it; `0` makes the bar invisible until hovered.
1684	*/
1685	--os-admin-bar-peek: 4px;
1686
1687	/*
1688	* How far BELOW the parked bar the invisible reveal zone reaches.
1689	* Decoupled from the peek on purpose — the seam wants to be a
1690	* hairline, the pointer target wants to be forgiving, and tying
1691	* them together forces one of the two to be wrong. The band the
1692	* user actually has to hit is `peek + this`.
1693	*
1694	* CEILING: keep `peek + reveal-zone` comfortably under the admin
1695	* bar's own height (32px, 46px below 783px). Past that, leaving
1696	* the revealed bar drops the pointer straight back into the zone,
1697	* which re-reveals it — an oscillation loop, not a wider target.
1698	*/
1699	--os-admin-bar-reveal-zone: 16px;
1700
1701	/* Z-index layers */
1702	--os-z-base: 100;
1703	--os-z-dock: 200;
1704	--os-z-adminbar: 9991;
1705	--os-z-fullscreen: 99999;
1706	/* Window-link layer — above widgets (z 1), behind windows (z 100+). */
1707	--os-z-window-links: 50;
1708	/*
1709	* Mio layer — above every window (windows run 100 + stack
1710	* index) so the companion can perch on top of them, but below
1711	* the dock (200) so it never covers navigation.
1712	*/
1713	--os-z-mio: 190;
1714	/*
1715	* The desktop-name caption. Same reasoning as Mio, one step up:
1716	* above every window so a maximized Dashboard cannot hide it, and
1717	* above the companion, since a momentary message should not be
1718	* the thing that gets perched on. Still under the dock (200).
1719	*/
1720	--os-z-desktop-name: 195;
1721	/*
1722	* The notch — on the desk, under the windows (100 + stack index),
1723	* above the window-link wires (50) so a tie never draws across the
1724	* pill. It hangs over the strip a window's title bar occupies, and
1725	* a pill floating above someone's window is the shell talking over
1726	* the thing they are working in.
1727	*/
1728	--os-z-notch: 60;
1729
1730	/*
1731	* Window-link ties (relation splines between windows). The accent
1732	* follows the admin color scheme. Solid colors only — the resting
1733	* dimming is done with stroke-opacity/fill-opacity in
1734	* window-links.css, NOT color-mix(): an unresolvable color-mix()
1735	* inside a custom property makes the consuming declaration invalid
1736	* at computed-value time, which turns SVG strokes invisible and
1737	* marker fills black (the written rgba() fallback declaration is
1738	* already gone from the cascade by then). Overridable per scheme
1739	* or by plugins/themes without touching the renderer.
1740	*/
1741	--os-window-link-color: var(--wp-admin-theme-color, #f252fc);
1742	--os-window-link-color-active: var(--wp-admin-theme-color, #f252fc);
1743	--os-window-link-width: 1.5px;
1744	--os-window-link-accent: var(--wp-admin-theme-color, #f252fc);
1745	/*
1746	* Halo behind related windows (`.os-window--linked`).
1747	* A literal rgba of Pulse rather than a color-mix() of the accent —
1748	* same no-color-mix rationale as above: if this token failed to
1749	* resolve, the whole box-shadow declaration (elevation shadow
1750	* included) would go invalid. Schemes/plugins that retint the
1751	* accent should override this too.
1752	*/
1753	--os-window-link-glow: rgba(242, 82, 252, 0.45);
1754	}
1755
1756	/*
1757	* ---- Iframe windows keep a light body -----------------------------
1758	*
1759	* A window hosting a real `wp-admin` page is not a station surface — it
1760	* is a frame around someone else's document, and that document is
1761	* light. The reveal surface is what covers such a window while it
1762	* loads, so a dark one wiping back to a white page is a flash in the
1763	* wrong direction.
1764	*
1765	* The window's own background is deliberately NOT overridden here, and
1766	* that was learned the hard way: `chromeless.css` paints the iframe's
1767	* canvas, so nothing of the window shows through the page anyway —
1768	* while the tab strip above it carries a 16px `mask-image` fade at
1769	* each end (the "scroll for more tabs" affordance). A mask makes the
1770	* element's own background transparent, so a white window behind a
1771	* dark strip turned that invisible cosmetic into a white gradient
1772	* bleeding into the chrome. The strip needs the station's colour
1773	* behind it; the page needs its own; those are two different surfaces
1774	* and only one of them belongs to the window element.
1775	*
1776	* Native windows — the ones the station draws itself — are excluded
1777	* and keep the Obsidian reveal from the palette above.
1778	*/
1779	.os-window:not( .os-window--native ) {
1780	--os-window-reveal-surface: #fff;
1781	}
1782
1783	/*
1784	* ---- The WordPress admin colour scheme no longer tints the shell ----
1785	*
1786	* There used to be nine blocks here, one per admin colour scheme, each
1787	* setting `--wp-admin-theme-color` on
1788	* `.os-shell[data-os-scheme="…"]`. They are gone,
1789	* and their removal is a bug fix as much as a rebrand.
1790	*
1791	* OS Settings → Appearance writes the user's chosen accent as an inline
1792	* style on `<html>` — deliberately, so it also reaches the WordPress
1793	* admin bar, which is a SIBLING of `#os-shell`. But those
1794	* blocks matched the shell root, a descendant of `<html>`, and for
1795	* custom properties the nearest ancestor with a value wins no matter
1796	* what the specificity of the rule that set it was. So inside the shell
1797	* the scheme always beat the picker: choosing Rose, or Pulse, changed
1798	* the admin bar and nothing else. Every focus ring, tab underline, sort
1799	* arrow and selection wash kept the colour of the admin scheme.
1800	*
1801	* With the accent picker defaulting to Pulse there is nothing left for
1802	* these blocks to express: the station has one identity colour, and a
1803	* user who wants their admin scheme's hue picks it in the same panel.
1804	* The `data-os-scheme` attribute is still stamped on the
1805	* shell root for plugins and themes that key off it.
1806	*/
1807