Compressed viewports after the keyboard appears need relayout, not a simple push
Aliases: keyboard inset · viewport compression · visualViewport
What it is
Once the keyboard is up, the region that can actually paint UI is shorter. The right response is to reflow against that new visible height: shrink the scroll container, decide which sticky header or footer stays, and place the current field in what remains. Translating the whole page upward while height is still computed as full screen is a simple push—the field may peek out, while the title, a progress bar, or bottom navigation is shoved off-screen, or the field shows and the button remains behind the keyboard.
Why it happens
The system exposes an inset: the layout viewport may stay put while the visual viewport shrinks. A push is a translation on the root; document height and sticky containing blocks are not updated, so three layers misalign—the fixed header rides along or vanishes, a position: fixed footer still hugs the covered bottom, and the scroll range still includes the empty strip under the keyboard. Relayout treats remaining height as a new containing block: the main scroller’s client height drops, the footer docks to the keyboard’s top edge, and an oversized card scrolls internally. Multi-field forms especially cannot use one translation: pushing to reveal the third field drops the first field’s label and the step indicator. After compression, information priority must be recomputed; the original layout cannot simply be moved.
Studying it
Compare three strategies: do nothing, translate the page, reflow to the visual viewport. Record field visibility, primary-button visibility, whether header/progress remain, and whether other fields can be scrolled to. Independent variables include field count, sticky chrome, and keyboard-height changes (candidate bar expanding); dependent measures include the set of visible critical controls and erroneous rubber-band overscroll. Resizing a simulator window does not share timing with a real inset; capture a mid-animation frame and a settled frame on device.
Where it stops holding
A short page with one or two fields and no sticky chrome can survive a push. Desktop window resize is not a keyboard inset; this reflow does not apply there. A floating or draggable iPad keyboard has no stable bottom edge, so the reflow anchor chatters and it may be better not to reflow and let the user drag the keyboard aside. On the web, vh often still tracks the layout viewport; reflow must read the visual viewport, not 100vh.
Applying it
- Listen to the visual viewport or the system inset. Resize the main scroller and dock the fixed footer to the keyboard’s top edge; do not add a
translateYto the page. - After compression, keep task progress or the step title; if space is short, drop a secondary footer before dropping the current field’s label.
- Capture frames at keyboard up, candidate bar expanded, and rotate. Check the visible combination of header, current field, and primary button—not only whether the field peeked out at the moment of rising.