/* ============================================================================ payco.css — canonical Payco design system. Single source of truth for every page. Tokens extracted from index.html (the luxury marketing front) so the app behind it matches the brand instead of feeling like a separate product. ========================================================================== */ /* ---------- page transitions ---------- Cross-document view transitions: the browser snapshots the outgoing page, snapshots the incoming one, and animates between them. No SPA router, no framework, no hydration — the navigation is still a plain link and a plain document. Named elements are pulled OUT of the root cross-fade and animated on their own, so the header does not fade out and back in on every click: it simply stays, and the segmented control's thumb glides from the old section to the new one because the browser sees the same-named element in two places and tweens it. That is the whole trick — the highlight isn't "animated to the next page", it's the same object. Everything here is progressive enhancement. A browser without view transitions (Firefox today, older Safari) ignores all of it and navigates exactly as before. */ @view-transition { navigation: auto; } /* Same colour as body, deliberately. These were #f5f7fb and #fbfcfe, and on any page whose content is shorter than the viewport the difference paints as a hard horizontal seam right across the page where the body ends. Measured at 1600x950: operations.html body 566px, crm.html 465px, analytics.html 792px, messages.html 874px — a visible two-tone page on all four. html carries the colour so the view-transition snapshot has a background too. */ html{background:var(--paper,#fbfcfe)} /* snappy: old page snaps out, new page lands in ~1 frame-feel — no quarter-second dissolve */ ::view-transition-old(root){animation-duration:.06s} ::view-transition-new(root){animation-duration:.11s} .pc-header{view-transition-name:pc-header} .pc-viewbar{view-transition-name:pc-viewbar} /* Thumb names are assigned per group in payco-nav.js — a view-transition-name must be unique in a document, and there are three controls on screen. */ /* The body cross-fade. Short, and with a whisper of upward travel: long enough to read as motion, far too short to wait on. Apple's own page changes sit around 200ms. */ ::view-transition-old(root){animation:pcFadeOut .16s cubic-bezier(.4,0,1,1) both} ::view-transition-new(root){animation:pcFadeIn .22s cubic-bezier(0,0,.2,1) both} @keyframes pcFadeOut{to{opacity:0;transform:translateY(-3px)}} @keyframes pcFadeIn{from{opacity:0;transform:translateY(6px)}} /* The header holds still while the body changes underneath it. */ ::view-transition-group(pc-header),::view-transition-group(pc-viewbar){animation-duration:.22s} ::view-transition-old(pc-header),::view-transition-new(pc-header), ::view-transition-old(pc-viewbar),::view-transition-new(pc-viewbar){animation:none;mix-blend-mode:normal} @media(prefers-reduced-motion:reduce){ ::view-transition-group(*),::view-transition-old(*),::view-transition-new(*){animation-duration:.01ms !important} } /* ---------- the fallback that does the actual work ---------- Everything above is Chrome-and-friends only, and it is invisible when unsupported — which means "smooth" cannot be built on it. So the incoming content fades up on its own, in every browser, with no JS and no cost: a page that appears is softer than a page that snaps, and 200ms is under the threshold where waiting registers. payco-nav.js marks from the pagereveal event when a real view transition IS running, and this stands down — the browser is already doing it. Opacity only, deliberately. A transform here would make these elements the containing block for their position:fixed descendants (the rank switcher, the assist widget) and quietly break them. Opacity creates a stacking context and nothing worse. */ /* The incoming content fades up as ONE compositor layer. Without the layer promotion the container's children paint at slightly different times — the card background lands first (white), then its 3px gradient accent bar streams in a frame later, which read as a "white then blue" flicker on the KPI cards. will-change:opacity forces the whole subtree onto one layer so it composites in a single pass, and the accent is there from frame one. Ends on opacity:1 (no 'both' holding a 0 frame). */ @keyframes pcSoftIn{from{opacity:0}to{opacity:1}} html:not(.pc-vt) main, html:not(.pc-vt) .shell, html:not(.pc-vt) .pc-wrap, html:not(.pc-vt) .wrap{animation:pcSoftIn .2s cubic-bezier(0,0,.2,1) forwards;will-change:opacity} @media(prefers-reduced-motion:reduce){ html:not(.pc-vt) main,html:not(.pc-vt) .shell,html:not(.pc-vt) .pc-wrap,html:not(.pc-vt) .wrap{animation:none;will-change:auto} } :root{ /* ink / paper */ --ink:#0a1628; --ink-soft:#2a3a5c; --ink-mute:#5a6885; --paper:#fbfcfe; --paper-warm:#f4f6fb; --white:#fff; --line:#dce3f0; --line-soft:#eaeff7; /* brand */ --blue:#1a4dd6; --blue-deep:#0b2a8a; --blue-electric:#3b82ff; --blue-cyan:#6dd5fa; --gradient:linear-gradient(135deg,#0b2a8a 0%,#1a4dd6 35%,#3b82ff 70%,#6dd5fa 100%); /* --gradient is a BACKGROUND ramp: it runs to #6dd5fa, which is correct behind white button text and unreadable AS text — 1.67:1 on white. It was nevertheless used as a text fill via background-clip on 13 pages, so every glyph painted from the last third of the ramp faded into the page; the worst case was index.html's hero headline, whose third line measured 2.75:1 against the photo behind it. Text fills use this ramp instead: same brand move, light end capped at #2a63d8 (5.42:1 on white, 4.6:1 on the palest hero sky). If you are filling GLYPHS, reach for this one — never --gradient. */ --gradient-text:linear-gradient(135deg,#0b2a8a 0%,#1a4dd6 45%,#2a63d8 100%); --gradient-text-flow:linear-gradient(90deg,#0b2a8a,#1a4dd6,#2158cf,#2a63d8,#2158cf,#1a4dd6,#0b2a8a); --gradient-soft:linear-gradient(135deg,rgba(11,42,138,.04) 0%,rgba(109,213,250,.06) 100%); /* semantic */ --ok:#0e7a4e; --ok-bg:#e7f5ee; --warn:#b3401f; --warn-bg:#fdece8; /* --amber was #9a6b00, which failed AA in the two places it is actually used: 4.26:1 on its own --amber-bg (integrations' "Confirm" status label) and 4.37:1 on the --bg page background. #8f6300 is the same hue two steps darker and clears 4.5:1 on amber-bg, white and --bg alike. */ --amber:#8f6300; --amber-bg:#fdf3e0; --info:#1a4dd6; --info-bg:#eaf1ff; /* elevation */ --shadow-sm:0 1px 2px rgba(10,22,40,.04),0 1px 1px rgba(10,22,40,.06); --shadow-md:0 4px 24px rgba(11,42,138,.08),0 1px 2px rgba(10,22,40,.04); --shadow-lg:0 20px 60px rgba(11,42,138,.12),0 4px 12px rgba(10,22,40,.06); /* geometry */ --radius-sm:10px; --radius:16px; --radius-lg:28px; --maxw:1240px; /* the sliver — see the section below */ --sliver:linear-gradient(90deg,#0b2a8a,#1a4dd6,#3b82ff,#6dd5fa); --sliver-warn:linear-gradient(90deg,#6e150c,#9a2018,#b3401f,#e0663f); --sliver-h:3px; --sliver-h-hover:4px; --sliver-ease:.18s cubic-bezier(.4,0,.2,1); /* type */ --font:'Inter',-apple-system,BlinkMacSystemFont,'Segoe UI',sans-serif; --mono:'SF Mono','JetBrains Mono',ui-monospace,monospace; /* ---- legacy aliases ---- These five names came from agents.css, which no page has loaded for a long time. That made every `var(--electric)` and `var(--mut)` written against it invalid at computed-value time: the declaration is dropped, so `background` fell back to transparent and `color` fell back to the inherited ink. It is silent — nothing errors, the rule just stops existing — which is why it survived. Two of the casualties were in this very file (.pc-drop-menu a::before and .pc-burger-sec a::before), so the nav's leading accent bar animated and painted nothing on every page on the site. Aliased here rather than rewritten at ~16 call sites: one definition, no behavioural diff to review, and pages that still say --electric keep working. --mut now ALIASES --ink-mute rather than keeping agents.css's own #5b6474. It was held apart because #5b6474 is the darker grey and aliasing to the old --ink-mute (#6b7a99, 4.31:1) would have lightened working text under AA. That reason expired when --ink-mute became #5a6885 (5.59:1 on white, 5.17:1 on --paper-warm — its worst case still clears AA), so the two greys no longer need to differ, and one muted grey means "muted" cannot drift between two pages. The ~30 call sites that wrote var(--mut,#5b6474) rendered that value via the fallback; they now resolve through this alias instead, so the fallback is dead weight rather than a second source of truth. Do not re-fork them: a page that redeclares --mut in its own :root silently opts out of every future contrast fix made here. */ --electric:var(--blue); --navy:var(--blue-deep); --cyan:var(--blue-cyan); --mut:#5a6885; --bg:#f5f7fb; /* ── THE VIEWPORT LAW ───────────────────────────────────────────────────────────────────── FOUR REGIONS, AND NOTHING ELSE MAY RESERVE SPACE. │ header — full bleed, nothing narrows it │ │ left rail │ gap │ centre │ gap │ right rail │ Everything below is that sentence written as arithmetic. There are exactly two numbers — the rail's width and the gutter — and every position on the page is derived from them, so a console cannot acquire a private opinion about where the middle of the window is. WHAT THIS REPLACES, AND WHY. The block that stood here reserved a FLYOUT LANE on the right: 380px of panel + 12px + 8px, opened at and above 1440px, on top of the rail. It was reserved whether or not a flyout was open — which is what pushed every console leftward and left the dead white strip the operator reported. MEASURED at 403ba53, admin.html, both rails up: width left gutter right gutter centre off viewport centre 1280 28px 28px 0px (below the old 1440 line) 1440 28px 400px -186px 1920 28px 400px -186px 2560 38px 410px -186px and on the seven other consoles sampled the right gutter ran to 592px and the centre sat 386px left of the window's own centre. A flyout is an OVERLAY now (§ .pc-hud-panel-anchored, css/payco-hud.css) and reserves nothing, so the lane is deleted rather than retuned. --pc-rail READS THE LEFT RAIL'S OWN TOKEN. `--rail-w` is css/payco-system.css:154 and it is what `.pc-sidenav` is actually sized with, so retuning it retunes the right rail, both gutters and the centre together and the two rails cannot drift apart. The 246px literal is the FALLBACK and never the value: twenty-three console pages — admin.html and operations.html among them — do not link that sheet and have no --rail-w to read. --pc-gap IS DECLARED HERE, ONCE, AND NOWHERE ELSE. css/payco-hud.css used to declare it as a flat 14px for its own panel packing; that token is `--pc-pack` now and this name belongs to the law. clamp(16,1.25vw,24) is 16px at 1280, 18px at 1440, 24px at 1920 and stays 24px above — the gutter grows with the desk and then stops, because past 1920 more air on the sides is width taken off the work. THE SWITCH IS THE OCCUPANCY, NOT A SELECTOR, and that is unchanged and still load-bearing: payco-hud.js publishes --pc-hud-right-open from a zero-height metric box inside the rail, so it is the rail's OPEN width in every state and 0px whenever the rail is not drawn — absent, hidden, refused by the nav's no-grant sweep, or released below the collapse line. Multiplying it by 100 turns it into a switch: min() clamps the reservation to the law's number whenever there is any rail at all, and to zero exactly when there is none. `:has()` was tried first and is the wrong question — it matches an element that is in the DOM, and a refused rail is in the DOM with display:none. outbox-console.html under a fully refused API took the whole gutter for a taskbar that was not drawn. AND THE SIZE FOLLOWS THE COLLAPSE AGAIN (F2, W3D). THIS REVERSES THE PARAGRAPH THAT STOOD HERE, and the reversal is the point rather than an oversight, so the old text is restated before it is withdrawn: the reservation was --pc-rail, a constant, so that toggling either rail changed the centre by zero pixels, because an earlier block had reserved the LIVE inset and the column jumped 164px under the reader's hands on every toggle. WHAT THAT CONSTANT ACTUALLY BOUGHT, MEASURED. It holds the centre still across a toggle, and it does so by paying a 246px rail on a page that is drawing an 82px strip. The skew the merge note at :731 defines — (host.x - bandL) - (bandR - host.right), with the band taken from the rails' OWN boxes — is therefore 0 only in the state the constant was named for. At 1440 on a console with the dock shut: bandR is 1358 (the strip's left edge), the column still ends at 1176, and the skew is 18 - 182 = -164. The constant did not centre the page in both states. It centred it in one and hid the other behind a reservation nothing was drawing. SO THE WIDTH TERM IS THE LIVE INSET AND THE SWITCH IS UNCHANGED. --pc-hud-right is what payco-hud.js publishes for the rail it actually drew — 246 open, 82 shut, 0 absent — so the band's right edge is the dock's rendered left edge at every moment, which is the same edge the skew is measured from and the same edge tests/viewportlaw.mjs now reads. --pc-lane-on still carries the OCCUPANCY SWITCH off --pc-hud-right-open, and it has to stay that way: -open is 0 exactly when no rail is drawn, while -right is 82 on a shut rail that is very much there, so a switch built on -right could not tell `shut` from `absent`. THE FALLBACK IS --pc-rail AND IT IS VERY NEARLY DEAD CODE. Before payco-hud.js publishes, --pc-lane-on is 0 and the min() takes the switch, so this arm is unreachable at cold load; it is kept at the constant so that a rail which publishes -open without -right reserves the wide number rather than none. THE TOGGLE NOW MOVES THE COLUMN BY DESIGN, which is what F2 asks for and what the `moves the centre by zero pixels` assertions were written to forbid. See the arming block at the padding below for the half of this that is NOT safe to do naively. */ --pc-rail:var(--rail-w,246px); --pc-gap:clamp(16px,1.25vw,24px); --pc-lane-left:calc(var(--pc-rail) + var(--pc-gap)); --pc-lane-on:calc(var(--pc-hud-right-open,var(--pc-hud-right,0px)) * 100); --pc-lane-right:min(var(--pc-lane-on),calc(var(--pc-hud-right,var(--pc-rail)) + var(--pc-gap))); /* AND THE LEFT BAND IS THE GAP, CARRYING THE RIGHT RAIL'S OWN SWITCH. Written as a min() for exactly the reason --pc-lane-right is written as one: one declaration covers a page that draws the right rail and a page that does not, with no selector to keep the two in step. --pc-lane-on is 0px until payco-hud.js publishes a rail box and a very large number after it does, so this resolves to 0px on the marketing tier and to --pc-gap on a console. IT IS THE GAP AND NOT rail + gap, AND THAT DIFFERENCE IS THE WHOLE OF THE DEFECT LANE U WAS SENT AT. What this pays for on the left of a page that is not `.pc-hasside` is the air beside the content column; there is no left rail under it to clear — that is what the class means — so the band owed there is one gap. --pc-lane-right is rail + gap because it has a 246px rail to clear, and spending it on this side reserved a rail that was never drawn. */ --pc-lane-gutter:min(var(--pc-lane-on),var(--pc-gap)); /* ── THE PANEL, AND THERE IS ONE OF IT ──────────────────────────────────────────────────── "Panels: full center width, ONE radius token, ONE padding token, ONE inter-panel gap." MEASURED FIRST, at 1440 on all twenty-nine consoles, every visible box carrying one of the site's panel classes, keyed on its computed radius and padding — EIGHT distinct shapes: 35 boxes 16px / 20px the plurality, and the one below 12 boxes 18px / 18px 6 boxes 16px / 18px 16px 1 each 14px/18px·16px · 16px/28px 22px · 28px/37.44px · 16px/0 · 0/0 A reader moving between two consoles was reading two different components, and none of the eight was wrong anywhere — each was a page's own taste, stated in its own