/* THE TOOL PAGE IS A WORKSPACE, AND A WORKSPACE DOES NOT SCROLL (W399). * * Manu, 2026-08-28: "we don't need a side scrolling layer on the right side of * the screen on the pay revision tool or any other tool, because the whole page * is not getting disturbed for revealing the footer now. Only the internal * components are shifting and they have their own scrollers. So remove the * scroller for the entire layout, which is also blocking the tool header and * the website header." * * He is right, and the second half is the part that matters. The document * scrollbar did not merely look untidy: scrolling it carried the site header * and the tool's own sub-bar off the top of the screen, so the two bars a * reader needs at all times went away whenever they looked at the bottom of a * long output. That is the identical fault the reference tables had (W331) and * the fix is the identical one. * * WHY IT WAS BUILT THAT WAY, AND WHY THAT REASON IS GONE. `01-tokens.css` says * it plainly — "document-flow: the page scrolls; the footer sits at the true * bottom". The page had to be able to scroll because that was the only way to * reach the footer. W396 made the footer auto-hide on these pages, so it is * reachable without moving anything, and the last reason for a document * scrollbar went with it. * * NOTHING IS LOST. The input column already scrolls itself (`.input-scroll`), * and the output column gets the same treatment here. Both are what were * actually moving; the shell around them never needed to. * * DESKTOP ONLY. Below 980px each tool stacks its two columns and the page IS * the scroller — `04-app.css` says so — and a phone with a fixed-height shell * would trap its content. The guard is the tools' own breakpoint, not a new * number of mine. */ @media (min-width: 981px) { /* The chain that gives the shell a DEFINITE height. base.html sets `min-height:100vh`, which is not enough: with no definite height there is never negative free space, so `flex:1` children grow to fit their content instead of shrinking into the viewport. `dvh` second, for the mobile browsers whose `vh` lies. (The reference tables state this same chain in their own sheet; it is repeated rather than shared because that file also carries table-only rules, and this must reach the calculators.) */ .hpfas:has(.app) { height: 100vh; height: 100dvh; } .hpfas:has(.app) > main { min-height: 0; display: flex; flex-direction: column; } .hpfas:has(.app) > main > .app { flex: 1; min-height: 0; } /* The mounted Pensionary Benefits tool renders a standalone document, so its `.app` is a child of and there is no `.hpfas` chain to hang off. */ body:has(> .app) { height: 100vh; height: 100dvh; display: flex; flex-direction: column; } body:has(> .app) > .app { flex: 1; min-height: 0; } /* THE TWO-COLUMN WORKSPACE fills what is left, and each column scrolls itself. `align-items: stretch` replaces the tools' `flex-start`: a column that only takes its content's height has nothing definite to scroll within, so `overflow-y` on it would do nothing. */ .app > .body-row { flex: 1; min-height: 0; align-items: stretch; } /* The input column was STICKY at `top:112px` with a hand-computed `calc(100vh - 112px)` — both of which existed only to hold it still while the document scrolled underneath. Nothing scrolls underneath now, so it is an ordinary column again and the two magic numbers retire with it; they had to know the height of both bars and would have gone stale the day either changed. `.input-scroll` inside it keeps its own scroller, untouched. */ .app > .body-row > .input-col { position: static; top: auto; height: auto; align-self: stretch; } /* ...and the output column becomes the scroller it was always acting as through the document. No `overflow` on `.body-row` itself: the date picker and the calculator pad are positioned popups, and a clipping ancestor is how they get cut in half. */ .app > .body-row > .output-col { min-height: 0; overflow-y: auto; } /* STICKY OFFSETS INSIDE THE OUTPUT COLUMN HAVE TO COME DOWN BY THE CHROME. * * This is the one thing moving the scroller breaks, and it broke visibly: * the tab pill dropped into the middle of the page and sat on top of the * "fill in the following" card (Manu's screenshot). * * `position: sticky` measures against its SCROLL CONTAINER. While the * document scrolled, that container was the page and a tab bar had to clear * the 66px site header and the 46px tool sub-bar itself — hence `top: 120px`, * which its own comment explains as "112 chrome + 8 so 8px of banner shows * above the pill". The column is the scroller now, and it already begins * below both bars, so those 112px were being counted twice and the bar * parked 112px too low. * * Written as the tools' own numbers minus the chrome, rather than as 8px and * 52px, so what each rule is doing is legible and a change to either bar's * height is one edit here. The tools are untouched: their files are build * artifacts of the standalone versions, where 120px is still right. */ .app > .body-row > .output-col { --tw-chrome: 112px; } /* 66 header + 46 sub-bar */ .app > .body-row > .output-col .otabs { top: calc(120px - var(--tw-chrome)); } .app > .body-row > .output-col .db-head { top: calc(164px - var(--tw-chrome)); } /* And the database toolbar, which sits below both of those. Missed on the first pass, and it is the one that shows: at 222px it parked over the first rows of the table on Pay Revision AND MR Claim, so the record under it could not be read or clicked. Every `position:sticky` inside this column needs the same correction — if a fourth appears, it belongs here too. */ .app > .body-row > .output-col .dbbar { top: calc(222px - var(--tw-chrome)); } }