` on the site the fixed nav twice and landed hash jumps and scrollIntoView calls a full chrome-height past their heading. Sections need nothing here: html{scroll-padding-top} in app.css already clears them. */ /* The two sticky quick-jump rails both hard-coded `top: 62px`. Pin them to the measured chrome instead so they sit flush under it rather than overlapping it or floating clear of it. */ .el-jump, .mandate-jump { top: calc(var(--pdx-chrome, 7.125rem) + 5px); } /* ── 7d · Stop the sticky chrome repainting the page behind it, per frame ── `backdrop-filter: blur(…)` on a full-width fixed/sticky bar forces the compositor to re-sample and re-blur everything underneath it on EVERY scroll frame. On mid-range phones that is the single most expensive thing on the page and it reads as stuttering, unstable scrolling. The bars are already ~80–92% opaque, so on phones we drop the blur and top the background up to fully opaque: near-identical appearance, none of the per-frame cost. Desktop keeps the blur untouched. */ @media (max-width: 640px) { nav.nav-blur { -webkit-backdrop-filter: none; backdrop-filter: none; background-color: #0a0f1e; } .el-jump, .mandate-jump { -webkit-backdrop-filter: none; backdrop-filter: none; } /* The profile overlay blurs a page that is already hidden. #modal-overlay is bg-black/85 AND backdrop-blur-md: at 85% opacity the blur is all but invisible, and it costs a full-viewport rasterisation on every profile open and every close — the two gestures a reader makes most. Dropped on phones only; the tablet and desktop rule is untouched. */ #modal-overlay { -webkit-backdrop-filter: none; backdrop-filter: none; } } /* ── 7e · Hush the huge decorative blur loops on phones ─────────────────── The hero and several section backgrounds stack 900px-wide radial glows behind a `blur(120–160px)` filter and animate them on infinite loops. Each frame re-rasterises a very large blurred layer, which competes with scrolling on exactly the devices that can least afford it. On phones the glows stay — they are part of the look — but they stop animating, so they rasterise once. Desktop is untouched. */ @media (max-width: 640px) { .animate-pulse2, .animate-float { animation: none !important; } } /* ── 7f · Async-loaded sections must not collapse to zero ───────────────── #say-vs-do, #issue-front-door and #hr1-showcase ship as empty, `hidden` stubs and are filled in later by their feature modules; #local-issues and the admin sections toggle `display` from JS. Each of those transitions moves everything below it. pdx-stability.js absorbs the shift on engines without native scroll anchoring; this reserves a floor for the fade-in so the growth that remains is a small settle rather than a jump from nothing. Scoped to phones and to the populated state — an empty stub still takes no space, so a self-gating section that has no data to show never leaves a blank band. */ @media (max-width: 640px) { #say-vs-do:not(:empty):not([hidden]), #issue-front-door:not(:empty):not([hidden]), #hr1-showcase:not(:empty):not([hidden]) { min-height: 320px; } } /* ── 7g · The donate card owns its own scroll on a phone ────────────────── THE REPORT: on a 390×844 screen the Support card was "jumpy, laggy, and stops scrolling." Three separate causes, all of them in this one card: 1. IT WAS THE TALLEST CARD ON THE HOMEPAGE AND HAD NO SCROLLER OF ITS OWN. Badge, heading, paragraph, a 210px QR block and four more lines of copy run past 844px of glass once the browser toolbar is showing, so the reader's only way through it was the document scroller — and the document scroller is the one the toolbar's own show/hide gesture competes with. The fix is the scroll contract this pass applies everywhere: the panel hosting Support owns `overflow-y: auto` and a height bounded in `dvh` minus the measured fixed chrome, so the CARD is what scrolls under the finger and the page behind it is not asked to move at the same time. `--pdx-chrome` (§7c) is the measured nav depth, so this is the visible viewport minus the bar that covers it, minus a margin so the card visibly ends inside the screen rather than exactly at its edge. `dvh`, not `vh`: §7c and the bottom-chrome doctrine both say it, and a `vh`-bounded box is precisely the bug being fixed on the Your File panel in the same pass. THE FALLBACK IS 7.125rem BECAUSE THAT IS THE ONE LITERAL. index.html declares `--pdx-chrome: 7.125rem` on :root for the frames before the measurer runs, and scripts/test-top-chrome.mjs pins every `var(--pdx-chrome, …)` fallback in every sheet to that same value — "one offset". A second number here, however reasonable on its own, is first paint disagreeing with the second frame about where the page starts. 2. `overscroll-behavior-y: contain` STOPS THE HANDOFF. Without it, a flick that reaches the end of the card's range chains straight into the document and the toolbar — which is the "jumpy" half: the reader lifts a finger and the whole page lurches. Contained, the card's range simply ends. 3. `animation: venmoGlow 6s infinite` ON THE QR FRAME WAS THE LAG. It repaints a 300%×300% five-stop gradient on a shadowed, rounded box, every frame, forever, whether or not the card is on screen — sitting behind two 256px circles under a `blur(64px)` filter. That is three large composited layers of permanent work for a decorative shimmer nobody is looking at while they scroll. On phones the frame keeps its gradient, pinned at one position, and stops animating; the blur circles fade to a flat tint. The appearance barely changes. Desktop keeps all of it. Scoped to ≤640px and to touch, because none of the three is a problem on a desktop viewport that fits the card whole and has the headroom to paint it. Nothing here adds a number, a percentage, a party read or a count — the card publishes no total and this rule does not give it one. */ @media (max-width: 640px) { .pdx-donate .pdx-donate-scroll { max-height: calc(100dvh - var(--pdx-chrome, 7.125rem) - 40px); overflow-y: auto; overscroll-behavior-y: contain; touch-action: pan-y; -webkit-overflow-scrolling: touch; /* The card's own padding already inset the content; this only keeps the scrollbar (where one is drawn) off the last character of a line. */ padding-right: 2px; } /* The sweep stands down. The gradient stays — it is the card's frame — it just holds still at the position the animation started from. */ .pdx-donate .venmo-qr-frame { animation: none !important; background-position: 0% 50%; } /* Two 256px circles under a 64px blur, for a tint. Same tint, no blur. */ .pdx-donate .pdx-donate-glow { -webkit-filter: none; filter: none; opacity: 0.5; } /* The button is full-bleed inside the card at phone width: it is the action the card exists for, and a centred 22rem control on a 390px screen leaves dead margin on both sides of the only thing worth tapping. */ .pdx-donate .pdx-donate-btn { max-width: 100%; min-height: 52px; } } /* A reader who has asked for less motion gets the still card at every width, not just on a phone. §6 already hushes the decorative loops; the QR frame was never in that list because its animation is a `background-position` sweep rather than one of the named keyframes. */ @media (prefers-reduced-motion: reduce) { .venmo-qr-frame { animation: none !important; background-position: 0% 50%; } } /* ── 7h · The donate card stands still at EVERY width ───────────────────── THE REPORT: "the donate hash is still hitchy on phone and a bit on desktop." §7g above stood the card's two permanent compositor jobs down at ≤640px and §6's reduced-motion block stood them down for a reader who had asked for less motion. That left one case uncovered — a desktop reader who has not asked — and it is the case the report calls "a bit on desktop." THE TWO JOBS, and why neither survives being asked to prove itself: 1. `animation: venmoGlow 6s ease-in-out infinite` repaints a 300%×300% five-stop gradient on a shadowed, rounded box every frame, forever, on screen or not. A background-position sweep is not a compositor-only animation: `background-position` is not a transform or an opacity, so it cannot be handed to the compositor — every frame is a paint of the element on the main thread, which is the same thread the arrival scroll and the card's layout are on. That is the fight. 2. The two `.pdx-donate-glow` circles are `w-64 h-64` (256px) under Tailwind's `blur-3xl` — a 64px Gaussian. A blur filter promotes its element to its own layer and expands that layer well past its own box, so the card carries two ~380px composited surfaces whose only job is a tint. The claim in the brief was "stand them down unless you can prove 0 extra layer": a `filter` other than `none` is, by the spec's own definition, a stacking context and a new layer. It cannot be proven free because it is not free. The same tint is reachable with no layer at all — the circles are already a flat radial colour at 50% opacity behind a backdrop-blurred card, so `filter: none` with the opacity held at the value §7g uses is visually the same card. WHAT IS NOT CHANGED. app.css keeps `@keyframes venmoGlow` and keeps declaring it on `.venmo-qr-frame`: the keyframes are the card's identity and scripts/test-mobile-body-lock.mjs pins that declaration deliberately, so this stand-down is ADDITIVE and scoped to `.pdx-donate` — the one place the frame ships. A QR frame used anywhere else, now or later, is untouched. And nothing here is a layout change: no size, no position, no flow. The card publishes no total, goal or progress bar before this rule and none after it, and the Venmo address is the one address it already had. */ .pdx-donate .venmo-qr-frame { animation: none !important; /* Pinned where the sweep began, so the frame keeps its gradient. */ background-position: 0% 50%; } .pdx-donate .pdx-donate-glow { -webkit-filter: none; filter: none; opacity: 0.5; }