/* * tokens.css — geometry tokens for the agent CRM. * * THIS IS THE FILE THE INCREMENTAL ROLLOUT EDITS (epic MPCRM-2102, MPCRM-2109). * * The UI is being modernised by moving border radius ~1px per release, on the * premise that a 1px step is below the perceptual threshold while six of them * are not. Users should feel the change without being able to point at it. That * only works if a step is one edit — so every radius in the app resolves through * a token declared here, and a ramp step is a single line changed below. * * Load order matters: this file must come AFTER bootstrap_theme1.css and the * per-user theme, because those are what consume the tokens. A page that loads * the theme CSS without this file renders with the fallbacks in the var() calls * — which is deliberate, and is what keeps the client portal frozen. See * docs/engineering/design-tokens.md. * * Theme scoping: theme1 (light) is the :root default; theme2 (dark) would * override only what differs. Today nothing differs — see the note at the end. * The active theme arrives as data-theme on , set in header.php. * * Ramp targets — see MPCRM-2109: * --radius-sm 4.0px -> 6px badges, chips * --radius-md-sm 3.2px -> 6px small controls * --radius-md 4.0px -> 8px base controls * --radius-md-lg 4.8px -> 10px large controls * --radius-lg 5.0px -> 10px cards, modals, panels * --radius-enroll 15.0px -> 8px enroll buttons — ramps DOWN, the long pole * * Move ONE step per production deploy, not per calendar week: two deploys in a * week would double the step. If a release is skipped, still take one step on * the next — catching up 2px at once is the visible jump this exists to avoid. */ :root { /* * Values below are TODAY'S RENDERED values — the result of the whole * cascade, not what any single file says. Bootstrap sets most of these and * the theme files then override some, so these were read off the final * computed value rather than off bootstrap_theme1.css. The fractional ones * are exact: no root font-size is set anywhere, so 1rem = 16px. */ /* .badge — 0.25rem from Bootstrap, not overridden by either theme */ --radius-sm: 4px; /* * Controls. Bootstrap scales radius with control height and we keep that * relationship rather than flattening it: a single value would make * .btn-sm proportionally far rounder than .btn-lg, and small controls would * take the largest jump in the whole programme (3.2px -> 8px) on the * elements where roundness reads most strongly. * * The proportion is Bootstrap's own 0.8x / 1x / 1.2x, preserved at target. */ --radius-md-sm: 3.2px; /* .btn-sm, .form-control-sm — 0.2rem */ --radius-md: 4px; /* .btn, .form-control, .dropdown-menu, .rounded */ --radius-md-lg: 4.8px; /* .btn-lg, .form-control-lg — 0.3rem */ /* * Containers. Bootstrap says 0.25rem for .card but BOTH theme1.css and * theme2.css override it to 5px, so 5px is what actually renders in light * and dark alike. There is no light/dark radius inconsistency despite the * raw Bootstrap value suggesting one. * * .modal-content is 0.3rem (4.8px) today and adopts this token under * MPCRM-2106 — a 0.2px change, the one place the "no visual change" claim * is approximate rather than exact. Modals and cards should share a radius * in the end state, so the alternative (a separate token, permanently * 0.2px out of step) is worse. */ --radius-lg: 5px; /* Shape primitives. Not part of the ramp; they have no target. */ --radius-pill: 50rem; --radius-circle: 50%; /* * The vendor enroll buttons (Connecture, SunFire, HealthSherpa, Silverpath) * are hardcoded at 15px inline today — ABOVE the 8px target, so they ramp * downward and finish last. Separate token so they descend independently * rather than snapping to --radius-md when MPCRM-2107 converts them. */ --radius-enroll: 15px; /* * ELEVATION * * Today's values, same as the radius tokens above — declared so nothing * moves, then ramped. The three slots do not map cleanly onto one existing * value each, because the app has never had a coherent elevation scale: * sm and lg take Bootstrap's utility values, md takes the .card shadow * (the dominant one at 9 uses). * * MPCRM-2111 repointed the unambiguous literals onto these tokens at * identical values — the .card shadow in light (9 declarations across * .card, .boxShadow and .orgDiv:hover) plus .shadow-sm and .shadow-lg. * That is what makes these tokens live; ramping them now moves real pixels. * * What it deliberately did NOT touch, because each is a design decision * rather than a repoint — all of it is MPCRM-2339: * - .shadow (base, 16 uses) has no token; it would have to change value * to join this scale * - 34 bespoke one-off shadows, which will drift out of step as the ramp * progresses, exactly like the third-party widgets in MPCRM-2110 * - theme2's three stray light-grey halos: --shadow-md is `none` in dark, * so repointing them would have deleted them outright * - the 900px-spread overlay, 14 uses across both themes * * Target — two layers, slate-tinted rather than neutral grey: * --shadow-sm 0 1px 2px rgba(15,23,42,.06), 0 1px 3px rgba(15,23,42,.08) * --shadow-md 0 2px 4px rgba(15,23,42,.05), 0 6px 16px rgba(15,23,42,.10) * --shadow-lg 0 4px 8px rgba(15,23,42,.05), 0 16px 32px rgba(15,23,42,.12) * * A single layer always reads as a sticker on the page: real objects cast * both a tight contact shadow and a wide ambient one. Slate rather than * #999 because a neutral shadow goes muddy against the #ebeff2 page. * * Note this ramps MORE smoothly than radius, not less. Radius is quantised * — 1px is the smallest step there is, and it sits right at the edge of * perceptible. Opacity, blur and hue are continuous, so a shadow step can * be arbitrarily small. Introduce the second layer at 0 opacity and even * that discontinuity smooths out. */ --shadow-sm: 0 0.125rem 0.25rem rgba(0, 0, 0, 0.075); /* Bootstrap .shadow-sm */ --shadow-md: 0px 2px 4px 0px rgba(153, 153, 153, 0.2); /* the .card shadow */ --shadow-lg: 0 1rem 3rem rgba(0, 0, 0, 0.175); /* Bootstrap .shadow-lg */ } /* * theme2 (dark) — elevation is the one place the themes genuinely differ, and * it needs a different model rather than the light values darkened. * * Today: .card in dark mode has `border: none` and no shadow at all, so cards * are entirely flat and separated only by a #303e47-on-#253138 surface delta * that is barely perceptible. theme2.css also still carries the light-grey * rgba(153,153,153,.2) shadow in three places — on a #253138 ground that reads * as a faint halo, not as depth. Both are addressed by MPCRM-2339. * * Target: shadows barely register on a dark ground, so the work is done by an * inset top edge — a 4-6% white hairline catching implied light from above. * That single line is most of why good dark UI looks layered rather than flat. * * --shadow-sm 0 1px 2px rgba(0,0,0,.30), inset 0 1px 0 rgba(255,255,255,.04) * --shadow-md 0 4px 12px rgba(0,0,0,.35), inset 0 1px 0 rgba(255,255,255,.05) * --shadow-lg 0 12px 32px rgba(0,0,0,.45), inset 0 1px 0 rgba(255,255,255,.06) */ :root[data-theme="theme2"] { --shadow-md: none; } /* * Third-party widgets (datepicker, chosen, fileinput, TinyMCE, hopscotch) carry * their own hardcoded radii and will NOT follow these tokens on their own. Left * alone they drift visibly out of step as the ramp progresses — a date popup at * 4px hanging off an input at 8px. MPCRM-2110 brings them onto these tokens. * Their CSS loads before ours, so plain overrides win without forking the CDN * files. */ /* * Every RADIUS token renders identically in both themes, so only elevation * appears in the theme2 block above. Add a radius override there only if one * genuinely needs to differ between light and dark. */