fix(website): paint landing code editor scroller on iOS#188
Merged
Conversation
The landing page code editor (#code) and Show-SQL panel (#sqlpanel) use
overflow-x:auto, but were transparent and relied on their parent's
background showing through. On iOS Safari an overflow-x:auto element gets
its own compositing layer; a transparent one paints the scrolled-in
(off-screen) region black instead of the ancestor background, so code
scrolled into view was unreadable.
Give each horizontal scroller its own opaque background matching its
container (--panel for #code, --statusbg for #sqlpanel). Both are id
selectors, so they override .storm-home pre{background:transparent} by
specificity; desktop appearance is unchanged.
zantvoort
added a commit
that referenced
this pull request
Jul 6, 2026
Follow-up to #188, which gave the horizontal scrollers opaque backgrounds but did not fix the symptom on iOS: scenes rendering with the first ~13 characters of every line cut off. The actual cause is a retained scroll offset, not paint. Any touch pan on the code block (including an accidental diagonal swipe while scrolling the page) leaves #code scrolled right. Desktop self-heals on the next scene: the near-empty first render collapses scrollWidth and the browser clamps scrollLeft back to 0. iOS Safari does not clamp the offset of a composited scroller when its content shrinks, so the stale offset survives every innerHTML replacement and each new scene types into a shifted viewport. Reset scrollLeft explicitly when a scene starts typing, when the finished snippet is rendered, and when the Show-SQL panel content is replaced.
zantvoort
added a commit
that referenced
this pull request
Jul 6, 2026
…#190) * fix(website): wrap landing editor code on phones instead of scrolling Third pass at the iOS landing editor bug, replacing the mechanism instead of nudging it. #188 (opaque scroller backgrounds) and #189 (explicit scrollLeft resets) are both live and neither cured it: on an iPhone the typed code still renders shifted left by a uniform number of characters, and panning repaints only part of the content. iOS Safari desyncs the painted tiles of a composited overflow-x scroller whose DOM is replaced every frame by the typewriter, so no scroll-position or background fix can reach it. Below 760px the editor now wraps long lines (pre-wrap) instead of scrolling them, with a slightly smaller font to limit wrapping. With no horizontal scroller there is no composited scroll layer to go stale. The gutter is hidden there too: line numbers cannot align once a logical line spans several visual rows. The Show-SQL panel gets the same treatment. Desktop and tablet widths are unchanged. * docs(blog): quote the closing line as the why-we-built-storm abstract Replace the dek with the post's own closing line, set as a quote.
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 iOS, scrolling the landing-page code editor horizontally (to reach code that runs off-screen) reveals a black region instead of the code — the off-screen columns are unreadable.
Cause
The code editor's
#code<pre>and the "Show SQL" panel#sqlpaneluseoverflow-x:autofor horizontal scrolling on narrow screens. Both were transparent and relied on their parent's background (.codeareagradient /.sqlconsole) showing through.iOS Safari puts an
overflow-x:autoelement on its own compositing layer. When that layer has no background of its own, Safari does not paint the ancestor's background into the scrolled-in region — it composites black backing store instead. That's the black area users see when scrolling to off-screen code.Fix
Give each horizontal scroller its own opaque background matching its container:
#code→var(--panel)(the codearea gradient's top stop, so the seam is imperceptible)#sqlpanel→var(--statusbg)(exactly matches.sqlconsole, no visual change)Both are
idselectors, so they override.storm-home pre{background:transparent}by specificity. Desktop appearance is effectively unchanged; the difference only matters on the iOS scroll layer.Verification
Note: I could not test on a physical iOS device. This opaque-background approach is the standard remedy for this iOS symptom and is low-risk. If any black region somehow persists, the fallback would be a compositing hint (
transform:translateZ(0)) on#code, deliberately avoided here to keep the change minimal.