/** * css/shell/tokens.css * Design tokens for the mobile shell UI (Type Shifter 1). * * Every colour, radius and — critically — every fixed bar height used by the * shell is defined once here. The bar heights matter more than they look: * the app bar, quick bar, progress bar and tab bar are all position:fixed, * and the page's own padding has to reserve exactly the space they occupy. * Deriving those paddings from two separate variables added with calc() is * how the previous nav's tab bar and sheet edges drifted apart on a real * device, so each edge here reads ONE token, never a sum of two. * * Scope: nothing in this file applies unless carries .ts-shell, which * js/shell/shell.js only adds at <=768px. Desktop is untouched. * * Dependencies: none. Loaded before every other shell stylesheet. */ body.ts-shell { /* ---- chrome (dark is the shell's native look) ---------------------- */ --ts-bg: #000000; --ts-surface: #111114; --ts-surface-2: #1a1a1f; --ts-surface-3: #232329; --ts-border: #26262d; --ts-border-soft: #1e1e24; --ts-text: #f4f4f6; --ts-text-dim: #9a9aa4; --ts-text-faint: #6d6d78; /* The accent is the app's, not this file's. It was a green declared here, and because this sheet loads AFTER styles-core.css it quietly overrode the app-wide accent for the whole phone UI: every bar, tab and button stayed green when the rest of the app moved to burgundy. It reads the core tokens now, so styles-core.css is the one place the colour lives. Two jobs, two tokens, as on the desktop. --ts-accent is a FILL (a button, the progress bar) and carries white ink. --ts-accent-text is the accent AS TEXT, and on this near-black chrome that has to be the light rose: burgundy text on black reads at about 2:1. --ts-accent-ink is deliberately NOT declared here any more. It was a near-black meant for a bright green fill; left in place it would sit on burgundy at 1.9:1. The core token is the right one. */ --ts-accent: rgb(var(--ts-accent-rgb)); --ts-accent-soft: rgb(var(--ts-accent-rgb) / 0.2); --ts-accent-text: var(--ts-accent-light); --ts-icon: #a855f7; --ts-danger: #f87171; /* ---- the reading page (deliberately warm, not pure white) ---------- */ --ts-page: #f8f6ef; --ts-page-ink: #14161a; --ts-track: #3a3a42; /* ---- geometry ------------------------------------------------------ */ --ts-appbar-h: 3.5rem; /* logo + title + actions */ --ts-quickbar-h: 3.25rem; /* Copy / Highlights / zoom / Focus */ --ts-progress-h: 0.25rem; /* Single source of truth for the space reserved at the bottom. The tab bar's own height, the progress bar's offset and the page's bottom padding all read THIS token directly — never a calc() of two — so their edges are geometrically guaranteed to meet. It is deliberately generous: smaller values leave the tabs inside Android's bottom-edge gesture zone, which swallows touches before they ever reach the WebView. */ --ts-bottom-reserve: 7.25rem; /* Where the icons sit inside that tall box (the rest is gesture-zone clearance that still belongs to the bar, so it is never bare canvas). */ --ts-tabbar-content-h: 3.75rem; --ts-radius: 0.875rem; --ts-radius-sm: 0.625rem; --ts-gap: 0.75rem; --ts-pad: 1rem; --ts-shadow: 0 0.5rem 1.5rem rgba(0, 0, 0, 0.45); } /* Light mode: the chrome lifts, the reading page stays warm. Only the surface/text tokens change — accents and geometry are shared. */ body.ts-shell.light-mode { --ts-bg: #f2f2f4; --ts-surface: #ffffff; --ts-surface-2: #f7f7f9; --ts-surface-3: #ececf0; --ts-border: #dcdce2; --ts-border-soft: #e6e6ea; --ts-text: #16181d; --ts-text-dim: #5c5f68; --ts-text-faint: #868a94; --ts-accent: rgb(var(--ts-accent-rgb)); --ts-accent-soft: rgb(var(--ts-accent-rgb) / 0.12); --ts-accent-text: var(--ts-accent-deep); --ts-icon: #7c3aed; --ts-track: #d4d4dc; --ts-shadow: 0 0.5rem 1.5rem rgba(0, 0, 0, 0.12); }