desktop-mode / assets / css / variables.css

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

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