Bendik Aagaard Lynghaug
d7f280e681
Deploy / deploy (push) Successful in 34s
setupCanvas() measured window.innerWidth/innerHeight directly, then a resize listener gated on innerWidth changing (guessing which resize events were "real" vs mobile Safari's address-bar animation). That measurement had nothing to do with .hero-yes's actual CSS height, so the canvas and its box could end up disagreeing - which is what was producing the observed jump in content below the hero on scroll, not the choice of viewport unit on its own. Switched to ResizeObserver on .hero-canvas (which tracks .hero-yes via inset:0), using its contentRect directly. This also drops the innerWidth-gating heuristic entirely: a fixed-height box never fires a ResizeObserver callback during the toolbar animation in the first place, so there's nothing to gate. Also updated the mouse/touch position normalization to use the canvas's own displayWidth/displayHeight instead of window.innerWidth/innerHeight, for the same reason - and fixed the .hero-yes comment, which still described the lvh reasoning from a prior attempt after the height value itself had been changed back to svh directly on origin/main.