/* Dark is the default palette (the app shipped dark-only for its first ~48 rounds, so absence of a data-theme stamp must keep looking exactly like it always did). A pre-paint script in index.html resolves the workspace's saved mode - system/light/dark - to an explicit data-theme="light|dark" stamp on , so this file never needs a prefers-color-scheme media block: JS owns the resolution, CSS just carries the two palettes. */ :root { color-scheme: dark; /* Base font: Settings → Appearance swaps the leading family via applyThemeFont() */ --font-stack: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, sans-serif; --bg: #0f1117; --bg2: #1a1d27; --bg3: #242736; --border: #2e3247; /* A CONTROL's boundary, as opposed to --border's grouping edge. Same "one token, two roles" split as --accent/--accent-text: a card outline wants to be quiet (1.33:1 is right - the surface change is doing the work) and an input's edge is the only thing telling a reader where to type, which WCAG 1.4.11 puts at 3:1. Sharing one token meant light mode rendered a near-white field on a white card behind a 1.38:1 line, which is the most visible thing wrong with light mode and was invisible in dark, where --bg/--bg2 differ enough to draw the box by themselves. */ --border-strong: #707381; --text: #e0e0e8; --text2: #9498b0; --accent: #6c5ce7; --accent-hover: #5b4dc2; /* The accent in a TEXT role (links, chips, the active tab) - a separate token because the two roles want opposite things from one hue: a fill wants to be saturated enough to carry a white label, and text on --bg3 wants 4.5:1. The bare --accent is 3.05:1 on --bg3 here, so every link in the app was under AA in the theme it was developed in. ⚠ Both of these, and --on-accent below, are RE-DERIVED in JS by applyThemeColor() whenever the owner picks a custom accent - these literals are the default accent's answers and the pre-paint fallback, nothing more. */ --accent-text: #8c80ec; /* The gradient's SECOND stop (2026-08-03), and ⚠ it is derived rather than picked. The owner can set a custom accent (applyThemeColor re-derives --accent-text and --on-accent from it), so a literal pink here would be a fixed hue sitting next to a hue the owner chose - the one pairing nobody reviewed. Mixing the accent toward --success keeps the two stops a fixed distance apart in the same space, so the sheen reads as one colour moving rather than as two colours meeting, whatever accent is live. It is declared once: custom properties resolve lazily, so this line answers differently in each theme without being restated in the light block. */ --accent-2: color-mix(in oklch, var(--accent) 62%, var(--success)); --success: #00b894; --warning: #fdcb6e; /* ── The --on-X family: text sitting ON a solid fill of --X. ──────────────────────────────── The dark theme's soft amber needs dark text and the light theme's deep amber needs white - a literal #333 there would go illegible the moment the fill darkens. ⚠ That argument was made for --warning alone and never asked of its siblings, so #fff sat on --success at 2.54:1 (the Approve / Send-all button) and on --danger at 3.16:1 for ~100 rounds. ⚠ Why this has to be a TOKEN and cannot be a light-mode override in the component that draws the chip: inside a shadow root there is no `:root[data-theme="light"]` to select - the host document's attribute is not reachable across the boundary (`:host-context` is the only reach and is not portable). Custom properties DO inherit through it. So in this app a colour that varies by theme has exactly one available spelling, and it is this one. The pairing is checked by NAME in `tests/theme.test.ts`: every --on-X must clear AA against --X in both palettes, so adding a fill token and its label is one step and forgetting the label is a failure rather than a guess. */ --on-accent: #fff; --on-warning: #11131e; --on-success: #11131e; --on-danger: #11131e; --on-text2: #11131e; --on-viz-1: #11131e; --on-viz-3: #11131e; --on-viz-dim: #fff; --on-viz-ord-2: #11131e; --danger: #e17055; /* The toast-error surface: a red-tinted panel, not a solid --danger fill */ --danger-surface: #2a1a1a; /* The barely-there "raised surface" tint (locale cards, accordions): white-at-2% reads as lift on dark but is invisible on white, so the tint must flip with the theme */ --lift: rgba(255, 255, 255, 0.02); /* Shadows carry most of the depth on dark; on light the borders do, so these soften there */ --shadow-pop: 0 8px 24px rgba(0, 0, 0, 0.4); --shadow-modal: 0 20px 60px rgba(0, 0, 0, 0.45); --radius: 8px; /* ⚠ ONE HEIGHT FOR EVERY CONTROL IN THE APP, and it is a token because the controls are spread across a global sheet, six style fragments and a dozen shadow roots - which is exactly how they drifted (owner, 2026-08-11, of the press kit's appearance strip: "different heights across the UI components... same on other pages like Smart links"). Nothing was WRONG in any single file: a button derived its floor from its own padding and line-height (40.4px), the three input types that had ever been reported pinned 37px each, a plain text input took whatever the UA gave it, and a color swatch was not styled at all. Four correct rules, four heights, one row. 40px is the number the app's BUTTONS already were, so the most visible control does not move. A custom property is also the only kind of rule that reaches a shadow root, which is what lets the select trigger and the multiselect share it (round 148's rule, once more). ⚠ It is a floor, never a fixed height: text scaled to 150% has to be able to grow its box. */ --control-h: 40px; /* The app-wide dot texture's strength; see body::before. Zero in the high-contrast palettes. */ --dot-grid-opacity: 9%; /* The SAME texture on a page that is ONE card on an empty field - the sign-in gate. Stronger on purpose (there are no cards for the grid to fill the gaps between, so it carries the page), and a TOKEN rather than a literal for the reason NOTE 5 on `body::before` gives: the four high-contrast palettes take both of these to 0%, and a percentage written into the rule would be a decision `prefers-contrast` could not reach. ⚠ It shipped as a literal `11%` and did exactly that - a high-contrast reader got a clean app and a still-textured sign-in page (§AC.4), which `tests/theme.test.ts` could not see, because the gate catches a hardcoded COLOR and this was a hardcoded PERCENTAGE over a correct token. */ --dot-grid-opacity-solo: 11%; /* THE ACCENT WASH BEHIND THE SIGN-IN CARD (2026-08-09, owner: Crew's sign-in *"looks cooler than the app one, and I think it's because the crew one has a glow or something around the login container"*). Right, and the reason is written down in `src/crew/views.ts`: that glow was in the mock and shipped only in Crew, so the app's own gate - the door every customer comes through - kept the flat version. A wide, soft wash lifts the middle of the field so the dot grid sits IN something rather than on flat black, and the card lands on the lit part. A TOKEN for `--dot-grid-opacity-solo`'s exact reason, and it is the same decision one surface over: this is a full-surface layer whose whole job is to compete with the words a little, so the four high-contrast palettes take it to 0% and a literal here would be a strength `prefers-contrast` could not reach. `tests/theme.test.ts` enforces both halves. ⚠ **15%, where Crew's identical rule says 9%, and copying its number is what NOT to do.** A percentage in a `color-mix` is an amount of PAINT, not an amount of light: Crew's page sits on a lighter ground than this app's `--bg`, so the same 9% lifted its field twice as far as it lifted ours. Both were shipped, screenshotted and sampled at the same two spots - the far corner and the field beside the card - and 15% here is what puts our lift on Crew's (+7 luminance, measured, in the dark palette). **When you carry a visual value across surfaces, carry the RESULT and re-derive the number**; the value that travels is "the field lifts by about this much", and the literal that produces it is a fact about whatever it is painted on. */ --signin-glow-opacity: 15%; /* How far anything docked in the bottom-right corner must sit from the bottom edge (2026-08-07). It is 24px - the plain inset - until `` mounts and raises it to clear its own 48px launcher, which is why it is a TOKEN and not a literal in two places: the corner is shared now, and a second surface that ever docks there reads this instead of guessing a clearance. ⚠ Declared HERE rather than left to a `var(…, 24px)` fallback, so it is discoverable in the palette and `tests/theme.test.ts` can see that it resolves. */ --gh-corner-dock: 24px; /* ── Text scale (§R) ────────────────────────────────────────────────────────────────────────── The multiplier Settings → Accessibility sets, and the reason every font-size in this app is a `rem`. Read `html { font-size }` below for what it multiplies and why nothing else scales. */ --gh-text-scale: 1; /* ── The focus ring (WCAG 2.4.7) ────────────────────────────────────────────────────────────── ⚠ Tokens for the same reason the motion durations are: a `:focus-visible` rule written once at document scope reaches nothing inside a shadow root, and every island and component has been shadow since round 100. So the RULE is duplicated (here for the light chrome, `focusStyles` in `sharedStyles.ts` for the shadow side) and the VALUES are custom properties, which do cross - otherwise the two copies drift and only one of them is the one a keyboard user meets. `--accent-text` rather than `--accent`: this is the accent in its READABLE role (the token's own comment above), and a ring is a thin line that has to be seen against three surfaces. The 2px offset is what makes a ring on a filled button visible at all - drawn flush it sits on the fill and disappears into it. */ --focus-ring-color: var(--accent-text); --focus-ring-width: 2px; --focus-ring-offset: 2px; /* Data-viz series slots - validated (CVD separation + 3:1 contrast) against --bg2, in BOTH palettes: same hues, stepped per surface (see the light block) */ --viz-1: #3987e5; --viz-2: #199e70; --viz-3: #c98500; /* The chorus's echo in the Sections timeline - a subordinate relative of --viz-3, and a real token rather than the color-mix() it used to be so that it can HAVE an --on- label. A derived fill cannot be paired with one by name, and this one lands mid-tone in both palettes, which is exactly where the label flips. Same rendered colour as the mix it replaces. */ --viz-3-soft: #7f5b18; --on-viz-3-soft: #fff; --viz-dim: #565b78; --viz-grid: #232738; /* Ordinal blue ramp for ordered stages (funnel) - validated monotone, light end clears the surface. The 250→600 steps clear BOTH surfaces (2.11:1 on white, 2.07:1 on dark), so the ramp is deliberately theme-invariant */ --viz-ord-1: #86b6ef; --viz-ord-2: #5598e7; --viz-ord-3: #2a78d6; --viz-ord-4: #184f95; /* ── Motion (round 149, BACKLOG B.4) ────────────────────────────────────────────────────────── Three durations and one easing, because the app only makes three kinds of promise: something responded to me (fast), something changed (base), something arrived (slow). A fourth would be a decision nobody could restate. ⚠ These are TOKENS for the same reason the colours are, and the reason is worth knowing before reaching for the obvious implementation: the usual reduced-motion reset (`@media (prefers-reduced-motion: reduce) { *, *::before, *::after { animation: none } }`) **cannot cross a shadow boundary**, and every island and component in this app has been shadow since round 100 - so a global reset would silently protect nothing. Custom properties DO inherit through the boundary, which makes flipping them at :root the only spelling that actually reaches the elements that animate. */ --motion-fast: 0.15s; --motion-base: 0.25s; --motion-slow: 0.4s; /* Decelerating: leaves immediately, settles gently. One easing, so nothing has to be chosen. */ --motion-ease: cubic-bezier(0.2, 0, 0, 1); /* Loops that DECORATE (the skeleton shimmer): a period and an iteration count. Only the count changes under reduced motion - one pass, then a plain grey block, which is all the shimmer was ever adding to. Status loops are a different token below. */ --motion-decor-loop: 1.5s; --motion-decor-iterations: infinite; /* Loops that carry INFORMATION - a spinner, the connection check's pulse. */ --motion-status-loop: 0.7s; /* The SHEEN: the slow gradient drift across the wordmark, added 2026-08-03 when the owner asked for the landing page's look in the app. Its own token because it is an order of magnitude slower than the shimmer and for the opposite reason: the shimmer says "something is loading" and this says nothing at all, which is what lets it collapse to a single pass with no loss. */ --motion-sheen-loop: 9s; /* The page's entrance on a route change. One rise, never a loop. */ --motion-enter: 0.42s; } /* ⚠ Not "no motion": WCAG 2.3.3 is about NON-ESSENTIAL animation, and the distinction has teeth here. A transition is decoration over a state the DOM already carries, so it collapses. A skeleton shimmer decorates a wait, so it stops after one pass and leaves a plain grey block. **A spinner does not stop**, because it is the only evidence that work is in flight - a still spinner is a spinner that lies, and "did my click register?" is a worse experience than a rotating ring for someone who asked for less motion. It slows down instead. */ /* ⚠ `:root:not([data-motion="full"])`, not a bare `:root` (§R). Round 149 honored the platform preference and gave the owner no way to say anything about it, which is the half §R was filed for: an accessibility SETTING has to be able to disagree with the OS in both directions, or it is a readout. `data-motion` is stamped on by `frontend/a11y.ts` (and pre-paint by index.html): absent or "system" = whatever the platform says, "reduced" = the block below, "full" = this one stands down. ⚠ The two token blocks are DUPLICATED on purpose - CSS has no way to name a set of declarations and apply it from two selectors - so `tests/motion.test.ts` asserts they are character-identical. A drift here is a preference that works from the OS and not from the app. */ @media (prefers-reduced-motion: reduce) { :root:not([data-motion="full"]) { /* Not 0s: a zero-length transition never fires `transitionend`, and anything waiting on one would hang. 0.01ms is instant to a reader and still a real transition to the engine. */ --motion-fast: 0.01ms; --motion-base: 0.01ms; --motion-slow: 0.01ms; /* Both halves, and the gate is what noticed: capping the shimmer at one iteration still leaves one full 1.5s sweep across the screen, which is exactly the movement the preference asked not to see. The period collapses too, so the skeleton is simply a grey block. */ --motion-decor-loop: 0.01ms; --motion-decor-iterations: 1; --motion-status-loop: 1.6s; /* Both of the 2026-08-03 additions are pure decoration over a state the DOM already has, so both collapse outright - a sheen that finishes one 9s pass is still 9s of movement nobody asked for, which is the mistake the shimmer's own comment above records. */ --motion-sheen-loop: 0.01ms; --motion-enter: 0.01ms; } } /* The same block, reached from the app's own setting instead of the platform's. Someone on a shared or managed laptop cannot always change the OS preference, and someone who wants less motion in THIS app and not in every other one has no OS spelling for that at all. */ :root[data-motion="reduced"] { /* Not 0s: a zero-length transition never fires `transitionend`, and anything waiting on one would hang. 0.01ms is instant to a reader and still a real transition to the engine. */ --motion-fast: 0.01ms; --motion-base: 0.01ms; --motion-slow: 0.01ms; /* Both halves, and the gate is what noticed: capping the shimmer at one iteration still leaves one full 1.5s sweep across the screen, which is exactly the movement the preference asked not to see. The period collapses too, so the skeleton is simply a grey block. */ --motion-decor-loop: 0.01ms; --motion-decor-iterations: 1; --motion-status-loop: 1.6s; /* Both of the 2026-08-03 additions are pure decoration over a state the DOM already has, so both collapse outright - a sheen that finishes one 9s pass is still 9s of movement nobody asked for, which is the mistake the shimmer's own comment above records. */ --motion-sheen-loop: 0.01ms; --motion-enter: 0.01ms; } /* The light palette. Every text/surface pairing here is contrast-checked to ≥4.5:1 (AA) - and as of round 148 that is a TEST (`tests/theme.test.ts`) rather than this sentence, because the sentence was true of the pairing its author had in mind (white, --bg2) and false against --bg3: --warning read 4.09:1 and --danger 4.42:1 on the surface half the app's cards use. The status colors are darker steps of the same hues because on white they double as text, and #00b894-style brights sit under 3:1 there. --viz-2/--viz-3 sit below 3:1 on white by design (the validated reference steps for these hues) - legal because every chart pairs them with a legend and printed totals, never color alone, and the test carries that exemption with its reason instead of a silent pass. */ :root[data-theme="light"] { color-scheme: light; --bg: #f2f3f8; --bg2: #ffffff; --bg3: #e9ebf4; --border: #d8dbe8; --border-strong: #85878f; --text: #21253a; --text2: #5c6280; /* --accent-hover is the same value in both palettes and that is not an oversight: a hover moves away from the LABEL, which is a fact about the accent, so the surface has no vote. It is restated here only because the light block would otherwise inherit the dark one silently, and a token that happens to agree should say so. --accent-text is the opposite case - its whole job is to be legible ON a surface, so it does differ, which is why applyThemeColor() has to re-run on a MODE flip and not only on a colour change. */ --accent-hover: #5b4dc2; --accent-text: #6656d9; --success: #00795c; --warning: #916100; --on-accent: #fff; --on-warning: #fff; --on-success: #fff; --on-danger: #fff; --on-text2: #fff; /* ⚠ Pure black, not the app's ink, and it is the one place in the palette that differs: this fill sits in the narrow luminance band where #11131e reads 4.05:1 and white 4.42:1 - neither clears AA, and only #000 does (4.76:1). `onColor()` in shared/contrast.ts encodes the same fallback for the accent an owner picks, for the same reason. */ --on-viz-1: #000; --on-viz-3: #11131e; --on-viz-dim: #11131e; --on-viz-ord-2: #11131e; --danger: #ba4325; --danger-surface: #fdeee9; --lift: rgba(20, 26, 60, 0.04); --shadow-pop: 0 8px 24px rgba(15, 20, 40, 0.14); --shadow-modal: 0 20px 60px rgba(15, 20, 40, 0.18); --viz-1: #2a78d6; --viz-2: #1baf7a; --viz-3: #eda100; --viz-3-soft: #ebc26e; --on-viz-3-soft: #11131e; --viz-dim: #9ba2bd; --viz-grid: #e7e9f2; /* ⚠ THE DOT TEXTURE IS STRONGER HERE THAN IN THE DARK PALETTE, AND ONE NUMBER COULD NOT SERVE BOTH (owner, 2026-08-13: *"the dot pattern needs to be a tad stronger in light mode, where they're almost invisible. They're just right in dark mode"*). `--dot-grid-opacity` lived only on `:root` - the dark palette - so light inherited it, and the arithmetic explains why that looked like a fair deal and was not. The dots are the TEXT color at N% over the page, so at 9% both palettes land about 19/255 away from their own background: the same delta, which is what makes a shared token so tempting. But an increment of 19 read against near-white is far weaker to the eye than the same 19 read against near-black, so identical numbers buy visibly different textures. **A token shared across two palettes is only shared if the thing it controls is perceived the same way in both** - a color pairing gets checked for this (`tests/theme.test.ts` does the contrast math); a strength never was. Dark keeps 9%/11% untouched, because the owner says dark is right and the only bug is here. ⚠ These are deliberately NOT restated in the two light high-contrast blocks: those take both to 0% and out-specify this one, so the texture still disappears where `prefers-contrast` asks. */ --dot-grid-opacity: 16%; --dot-grid-opacity-solo: 19%; } /* ── HIGH CONTRAST (§R) - a THIRD and FOURTH palette, not a filter ──────────────────────────────── Settings → Accessibility, and `@media (prefers-contrast: more)` when the owner leaves it on "system". `data-contrast="high"` is stamped on by `frontend/a11y.ts`, exactly like `data-motion`, and for the same reason: the attribute is only a selector hook, and what actually reaches the shadow-rooted islands is the token values these blocks set. ⚠ **A palette, and deliberately not `filter: contrast(1.4)` or a blanket "text goes white".** A filter is applied to PIXELS, so it hits the cover art, the waveform and every chart at the same time - a photograph the owner uploaded is not a contrast problem to be fixed - and it cannot be checked by the gate that makes all of this real. Two more sets of token values can be: both blocks below are in `tests/theme.test.ts`'s `PALETTES`, so every pairing the app draws is measured in FOUR palettes now, and a high-contrast block that is high contrast everywhere except on raised rows fails the same way the light palette did in round 148. ⚠ **Neither block touches `--accent`, `--accent-hover` or `--on-accent`, and that is required rather than an omission.** Those three are DERIVED at runtime from the accent the owner picked (`theme.ts`'s `deriveAccentTokens`) and written as INLINE styles on , which beat any selector here - so a literal in these blocks would be dead on every install that has ever opened the color picker. `a11y.ts` re-derives them when the contrast changes instead, which is also more correct: they are computed against whatever surfaces are live, so they follow this palette automatically. `--accent-text` IS declared, because it is what the pre-derive first paint uses and what the gate measures. */ :root[data-contrast="high"] { --bg: #000000; --bg2: #0c0e15; --bg3: #1a1d29; /* A grouping edge stops being decoration here: at this contrast the surfaces are close enough together that the border is what separates a card from the page. */ --border: #5c6178; --border-strong: #b0b5c8; --text: #ffffff; --text2: #d6dae8; /* ⚠ The gate picked this value, not a designer: `tests/theme.test.ts` requires the literal to be exactly what `applyThemeColor()` derives for the DEFAULT accent against THESE surfaces, or the app repaints the accent a shade different the moment /api/settings/theme resolves. A "more contrasty" hand-picked purple here would be a flash on every boot of a palette chosen by someone who is sensitive to exactly that. */ --accent-text: #8476eb; --success: #4fdba9; --warning: #ffd77a; --danger: #ff9d85; --danger-surface: #3a1512; /* The status fills got brighter, so their labels flip - the round-148 rule that this family is checked BY NAME and that adding a fill without its label is a failure rather than a guess. */ --on-warning: #000000; --on-success: #000000; --on-danger: #000000; --on-text2: #000000; --viz-grid: #3a3f55; /* The dot grid is a texture at 9% of the text colour - at this contrast it reads as noise over the one palette whose whole point is that nothing competes with the words. */ --dot-grid-opacity: 0%; --dot-grid-opacity-solo: 0%; --signin-glow-opacity: 0%; } :root[data-theme="light"][data-contrast="high"] { --bg: #ffffff; --bg2: #ffffff; /* ⚠ The one value the gate moved: `--bg3` started at #e8eaf2 and put `--accent-text` at 4.36:1 on a raised row - under AA, in the palette built to be readable. It is the light theme's own lesson (round 148) arriving in the palette that exists because of it: a surface a designer reads as "barely tinted" is a real background to the text on top of it. */ --bg3: #e4e7f1; --border: #6f7488; --border-strong: #2b2e3d; --text: #000000; --text2: #33374a; /* As the dark block above: derived, not picked. */ --accent-text: #6153d0; --success: #0b6b4f; --warning: #7a4a00; --danger: #a52f14; --danger-surface: #ffe4de; --on-warning: #ffffff; --on-success: #ffffff; --on-danger: #ffffff; --on-text2: #ffffff; --viz-grid: #cbd0e0; --dot-grid-opacity: 0%; --dot-grid-opacity-solo: 0%; --signin-glow-opacity: 0%; } /* "System" on the contrast control means this: the platform's own answer, which is what an install that never opens the setting gets. ⚠ `:not([data-contrast])` rather than a bare `:root` - someone who has explicitly chosen "standard" has said they do NOT want this, and a media query that overrules an explicit choice is the readout problem the motion block above is written against. */ @media (prefers-contrast: more) { :root:not([data-contrast]) { --bg: #000000; --bg2: #0c0e15; --bg3: #1a1d29; --border: #5c6178; --border-strong: #b0b5c8; --text: #ffffff; --text2: #d6dae8; --accent-text: #8476eb; --success: #4fdba9; --warning: #ffd77a; --danger: #ff9d85; --danger-surface: #3a1512; --on-warning: #000000; --on-success: #000000; --on-danger: #000000; --on-text2: #000000; --viz-grid: #3a3f55; --dot-grid-opacity: 0%; --dot-grid-opacity-solo: 0%; --signin-glow-opacity: 0%; } :root[data-theme="light"]:not([data-contrast]) { --bg: #ffffff; --bg2: #ffffff; --bg3: #e4e7f1; --border: #6f7488; --border-strong: #2b2e3d; --text: #000000; --text2: #33374a; --accent-text: #6153d0; --success: #0b6b4f; --warning: #7a4a00; --danger: #a52f14; --danger-surface: #ffe4de; --on-warning: #ffffff; --on-success: #ffffff; --on-danger: #ffffff; --on-text2: #ffffff; --viz-grid: #cbd0e0; --dot-grid-opacity: 0%; --dot-grid-opacity-solo: 0%; --signin-glow-opacity: 0%; } } * { margin: 0; padding: 0; box-sizing: border-box; } /* THE DOT GRID, app-wide (owner, 2026-08-05). One dot every 22px, in the text colour at 9%. ## What this was, and why it is not that any more It shipped as a STEP SEQUENCER - the same grid with an accent-coloured dot on every fourth column, four steps to the bar with the downbeat lit - chosen from six candidates the owner looked at on the real pages (dot grid, sequencer, vinyl grooves, grooves+dots, waveform horizon, staff lines). Two things retired the beat, in this order, and both are worth keeping because they generalise: NOTE 1 - **the accent is a knob the USER owns** (Settings -> Appearance), so an accent-coloured dot on every screen makes the whole app loud the day somebody picks neon pink, and nothing here can reach that. A texture keyed to a user-chosen colour has a character we do not control. NOTE 2 - the beat survived one round as a monochrome dot and then went too: at app-wide density the emphasis reads as busy rather than as rhythm. **A pattern that is right for one card on an empty field is not automatically right behind a working screen** - the same texture wants different strengths, and sometimes fewer ideas, as the density goes up. NOTE 3 - painted on a FIXED layer rather than on `body`, so it does not scroll with the content: a texture sliding under a long table is motion nobody asked for, and it would tile visibly at the seam of every page-height. NOTE 4 - it is visible only in the GUTTERS, because every surface above it is opaque. That is the whole effect, and it is why `tableStyles` had to give the bare tables a surface first - without one, the dots ran straight through the rows of the Outlets table. */ body::before { content: ""; position: fixed; inset: 0; z-index: 0; pointer-events: none; /* NOTE 5 - the strength is a TOKEN (§R), because the high-contrast palettes take it to 0%. That palette exists so nothing competes with the words, and a texture behind them is the one thing in the app whose entire job is to compete a little. A literal here would be a decision `prefers-contrast` could not reach - the motion tokens' argument, in a second lane. */ background-image: radial-gradient(color-mix(in srgb, var(--text) var(--dot-grid-opacity), transparent) 1px, transparent 1px); background-size: 22px 22px; } /* Everything the app draws sits above the layer. */ body > * { position: relative; z-index: 1; } /* ── The text-size control's one point of contact with the app (§R) ─────────────────────────────── Every `font-size` in `src/frontend` and in this file is a `rem`, and `rem` resolves against THIS declaration. That is the whole mechanism, and each half of it was chosen against an alternative that looked simpler: ⚠ **`rem`, not a class or a wrapper scale.** A `rem` resolves against the document root from anywhere, including inside a shadow root - and every island and component in this app has been shadow since round 100, so a `:root.text-large` class or an `em` cascade from `.layout` reaches none of them. It is round 148's rule once more: an ambient condition reaches a shadow-rooted element only through something that inherits, and a length that resolves against the root is the font-size-shaped version of that. ⚠ **`100%`, not `16px`.** A percentage here resolves against the browser's own default text size, so someone who has already raised it in their browser keeps that and the app's multiplier stacks on top. Writing `16px` would silently overrule a setting they made once for every site. ⚠ **Only text scales, and that is the feature rather than a limitation** (§R's design note, which asked what this buys over ⌘+). Browser zoom already scales everything and every browser has one - building a worse copy of it would have built nothing. What no browser offers is *text bigger, layout the same*, which is WCAG 1.4.4 / 1.4.12 and what someone who can read this app's layout but not its 13px hints actually needs. So spacing, control boxes, icons and the sidebar stay in `px` ON PURPOSE: a padding in `rem` would grow the chrome back around the bigger text and undo the gain. If you add a `rem` to anything that is not a font-size, you have quietly turned this into zoom - `tests/a11y.test.ts` fails that. */ html { font-size: calc(100% * var(--gh-text-scale, 1)); } body { font-family: var(--font-stack); /* Set by applyThemeFont when a custom base font carries its own tracking; else `normal` */ letter-spacing: var(--font-tracking, normal); background: var(--bg); color: var(--text); line-height: 1.6; } /* ── Focus (WCAG 2.4.7) ─────────────────────────────────────────────────────────────────────────── ⚠ Before §R there were TWO `:focus-visible` rules in the whole app, which means a keyboard user could not see where they were - and that is not one bug among many, it is the bug that makes every other keyboard fix impossible to check by hand. This rule and its shadow twin (`focusStyles` in `components/sharedStyles.ts`) are the app's answer. `:focus-visible`, not `:focus`: the browser's own heuristic already knows a mouse click on a button should not draw a ring while a Tab onto the same button should. Writing `:focus` would put a ring on everything the owner clicks, which is the reason rings get deleted from apps in the first place. ⚠ `:focus-visible` on a shadow HOST is not the same question as on its contents, and both matter: an element that delegates focus (``) matches on the host, and one that renders a plain `