fix(landing): pin mobile hero stage (inset:auto was clobbering top:0)#51
Merged
Conversation
The mobile .stage rule set `top:0` then `inset:auto`; since `inset` is shorthand for all four offsets, it reset `top` back to `auto`. A sticky element with `top:auto` has no anchor edge, so the hero canvas never pinned and scrolled off the top of the viewport as soon as scrolling began. Reordering to `inset:auto; top:0` restores the intended pin. This was browser-independent (reproduced in Chrome device emulation), not the iOS-Safari canvas-compositing issue originally suspected.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
On mobile, the hero canvas disappeared off the top of the viewport as soon as scrolling began — it never pinned. Originally suspected to be an iOS-Safari
<canvas>-in-stickycompositing bug (handoff from #50), but it reproduces in Chrome device emulation too, so it is browser-independent.Root cause
The mobile
.stagerule declared offsets in the wrong order:insetis shorthand fortop/right/bottom/left, soinset:auto(added to undo the desktopinset:0) resettopback toauto. A sticky element withtop:autohas no anchor edge and behaves like static — it scrolls away with the page.Fix
One line — reorder so the offset reset comes before
top:Verification
Measured via a Chrome DevTools-Protocol harness driving real scrolling at a 393x852 / DPR-3 mobile viewport:
topauto0pxrect.topwhile scrollingStable across 3 runs. Caveat: verified in headless Chrome emulation, not yet on a physical iPhone. The fix is deterministic per the CSS spec, so it will behave the same on iOS Safari, but on-device confirmation is still recommended before closing out the mobile work.
Docs-only change; no version bump required.