/* ============================================================================ ProDAQ License Manager design tokens — SINGLE SOURCE OF TRUTH for colour. Layer 1 SEMANTIC (components consume ONLY these) --c-* Layer 2 STATUS (LOCKED, never restyled) --s-* plus the theme-independent scale: --sp-*, --radius-*, --font-*, focus, motion. WHAT CHANGED, AND WHY THIS FILE IS A THIRD OF ITS OLD LENGTH ----------------------------------------------------------- It arrived as a lift of ProDAQ's token sheet: a Layer-1 --p-* palette plus five themes (Ledger light/dark, Night Shift, Slate, Graphite light/dark, High Contrast), each selected by a `data-theme` attribute on . Nothing in this app ever set that attribute. There is no theme picker, no theme endpoint and no generated per-theme sheet — those are ProDAQ features — so not one of those blocks could ever match, and every screen in the app has always been painted by the "safety net" values on bare :root at the bottom of the file. About 300 lines of it were unreachable by construction, which is worse than dead: it read as though changing Ledger's teal would change the app, and it would not have changed a pixel. So the themes are gone and the values that were actually live are stated once, here, plainly. The --p-* layer went with them: an indirection whose only purpose was letting a theme remap the semantic names is just a second name for the same colour once there is one theme. THE PALETTE IS NOW THE LOGIN SCREEN'S. It used to be ProDAQ's warm-paper-and-teal, which had nothing to do with the violet gradient the sign-in page has always worn — the app changed character the moment you signed in. --c-primary is the login accent, the surfaces are its cool greys, and --brand-stops below is literally the gradient off .login-stage, which is what lets the topbar carry the same colour as the page the operator just came from. Never hard-code a colour in a component or in shell.css. app.css's own vocabulary (--bg, --accent, --line, --text-dim) is kept as ALIASES onto these, so the older sheet's rules keep working while pointing at one set of values. ============================================================================ */ :root { color-scheme: light; /* ---- Type stacks -------------------------------------------------------- */ --font-display: 'Archivo', "Segoe UI", system-ui, sans-serif; --font-body: 'Archivo', "Segoe UI", system-ui, sans-serif; --font-mono: 'IBM Plex Mono', ui-monospace, "Cascadia Mono", Consolas, monospace; /* ---- Spacing unit + scale ----------------------------------------------- */ --sp-1: 4px; --sp-2: 8px; --sp-3: 12px; --sp-4: 16px; --sp-6: 24px; --sp-8: 32px; /* ---- Radius ------------------------------------------------------------- Three steps, not two. --radius-control is the small one worn by buttons and chips; --radius-card is the middle one for panels that sit INSIDE a surface (a dropdown, a table viewport); --radius-panel is the big one for the two surfaces a screen is actually made of, the page card and the modal. Giving those two a radius of their own is most of what separates "a bordered box" from "a card" — at 6px everything in the app was the same mild rectangle. */ --radius-control: 8px; --radius-card: 12px; --radius-panel: 18px; /* ---- Density ------------------------------------------------------------ */ --row-height: 40px; --cell-pad-y: var(--sp-2); /* ---- Focus -------------------------------------------------------------- */ /* Only the date picker's focused DAY cell still draws a ring: every other control in the app answers a Tab by thickening its own bottom rule instead (see --field-* below), and a 30px calendar square has no rule to thicken. --focus-offset went with the rest — a ring inset into the cell it marks needs a negative offset, not the shared positive one. */ --focus-width: 2px; /* ---- Motion ------------------------------------------------------------- */ --motion-fast: 120ms; --motion-base: 200ms; --motion-ease: cubic-bezier(0.2, 0, 0, 1); /* ---- Layer 2 STATUS — LOCKED --------------------------------------------- Never restyled, and always paired with a WORD on screen: colour carries emphasis, never the meaning on its own (WCAG 1.4.1). Each is checked to clear 4.5:1 on white, because status text is small and is the text most likely to be read in a hurry. */ --s-normal: #0F7A52; /* green — in force, delivered, healthy */ --s-alert: #9A6100; /* amber — expiring, not yet sent */ --s-alarm: #C62828; /* red — expired, revoked, refused */ --s-offline: #4A5A75; /* grey — suspended, superseded, stale */ /* There is deliberately no --s-info. ProDAQ's locked set has five; this app has no neutral notice to paint with one, and a token nothing consumes is a colour nobody has checked. */ /* ---- The brand gradient -------------------------------------------------- The three stops off .login-stage, as STOPS rather than as a finished gradient, so the angle can differ where the shape does. The login page is a full-viewport stage and takes 43deg; the topbar is a 56px band and takes ~100deg, because a steep angle across a shallow box shows one stop and loses the other two. Same three colours either way, which is the point — the bar the operator lands on is painted in the page they just left. PASTEL, so what sits on it is DARK ink. White on #DBC0F5 is about 1.6:1 and unreadable; the two tokens below are the pair that clears AA against the darkest stop (#918CD9): --c-on-brand measures 5.4:1 and --c-on-brand-muted 4.7:1, and both improve across the rest of the sweep. Do not swap either for a translucent white "to soften it" — that is exactly the change that puts the navigation at 2:1 on the light middle of the bar. SINCE THE PALETTE MOVED TO GREYS these three stops are the LOGIN STAGE's and little else. The rail no longer borrows them — it has --chrome-stops below, dark, with light ink — and .topbar's own `background` line is commented out, so the bar is the page background carrying dark ink. Uncommenting it puts the gradient back and nothing here has to change for that. */ --brand-stops: #6f6c72 0%, #9f9ba3 46%, #b1aecb 100%; --c-on-brand: #1B2032; --c-on-brand-muted: #4F5570; /* ---- CHROME: the dark surface, and the ink that goes on it --------------- Worn by the two places this app paints a coloured plane over its own content — THE RAIL and THE MODAL HEAD BAND. Separate from --brand-stops on purpose, and this is the fix for text that could not be read on either. Both used to wear the brand gradient with dark ink, which worked while those stops were pastel violet. Once the palette moved to greys it stopped working in both directions at once. The grey sweep spans a THREE-TO-ONE range of luminance (#6f6c72 to #b1aecb), and no single ink clears 4.5:1 across a span that wide: dark ink dies at the dark end, white ink dies at the light end. The rail's four nav labels sat at roughly 2:1, and a dialog's subtitle at about 1.4:1 over the left of its own header. Rather than force one gradient to serve a pastel login stage AND two chrome surfaces, the chrome gets three stops of its own — dark, in the same grey family, with light ink. THE RULE FOR RETUNING THESE: keep the LIGHTEST stop at or below #5A5761. White then clears ~7:1 on it and --c-on-chrome-muted ~4.8:1, and the MUTED ink is the one that decides it — inactive nav labels and dialog subtitles are 12–13px, so they need 4.5:1, and they are the text a reader is scanning. Check against the light END of the sweep, never the dark one: the dark end always passes, which is how the previous version looked correct in a screenshot of the rail's wordmark and failed on every item beneath it. */ --chrome-stops: #3D3B45 0%, #4C4A55 55%, #5A5761 100%; --c-on-chrome: #FFFFFF; --c-on-chrome-muted: rgb(255 255 255 / 0.75); /* ---- Layer 1 SEMANTIC ---------------------------------------------------- */ --c-bg: #F3F4FB; --c-surface: #F7F7FC; --c-surface-raised: #FFFFFF; --c-border: #E1E3F0; --c-border-soft: #EEEAF8; --c-text: #20233A; --c-text-muted: #68708A; --c-primary: #6259E8; --c-primary-alt: #A56BEF; /* the gradient's far end — hover on the login submit, accents */ --c-primary-ink: #FFFFFF; --c-focus: #6259E8; --c-selection: #F0EDFF; /* primary at ~8% on white: hovered rows, open menu items */ /* ---- Elevation ----------------------------------------------------------- Tinted with the brand's ink rather than pure black, so a shadow on this palette reads as depth under a violet light rather than as grey soot. Three steps, and only three: a resting surface, a hovered one, and the overlay a modal floats on. The page card and the modal each build their own stack out of these plus an inset highlight — an elevation token cannot carry a highlight, because that layer has to be painted INSIDE the box rather than under it. */ --elev-sm: 0 1px 3px rgba(45, 35, 90, 0.06); --elev-lg: 0 18px 44px rgba(91, 70, 150, 0.14); --elev-overlay: 0 28px 70px rgba(55, 35, 100, 0.22); } /* ---- The field rule ------------------------------------------------------- Every text box, drop-down and picker in the app is now the login page's input: no box and no fill, just a rule under the caption's field that thickens and takes the accent on focus. These three tokens are that rule, and they live here so the sign-in form and the admin forms cannot drift into two kinds of input. The colours are the login sheet's originals, stated as the ink at a fraction rather than as picked greys: a hairline under a field is the one place a chosen grey goes wrong first, because it has to sit correctly on the white card AND on the tinted head band above it. The FOCUS indicator is the rule itself — thicker, accent-coloured, with a soft glow beneath. That is a change in weight, hue and area at once, which is what an indicator has to be when there is no box to draw a ring around. See the note on .login-input in app.css: an outline here fires on the autofocused field and puts a box back around a form drawn not to have one. */ :root { --field-line: rgba(70, 65, 110, 0.25); --field-line-hover: rgba(70, 65, 110, 0.45); --field-placeholder: rgba(32, 35, 58, 0.38); }