The keyboard occupies the lower half and rewrites every spatial relation
Aliases: IME inset · keyboard reflow · visual viewport
What it is
Focus a field and the system keyboard grows from the bottom, often taking more than forty percent of the height. Yesterday’s “bottom” is now the top of the keyboard. Tab bars, floating buttons, flush submits, the last rows of a list — all of them have new neighbours. A keyboard viewport rewrite is not “the keyboard is large”. It is a replacement map: what is on screen, what sits against what, where the thumb zone is, all have to be recalculated on the post-keyboard picture.
Decisions made on the pre-keyboard layout — primary flush to the bottom, errors under the field, empty states centred — can all fail at once after the keyboard is up.
Why it happens
Touch systems implement the keyboard as an opaque system layer; the height the app is given shrinks abruptly. If the app still lays out at the old height, lower controls are covered. If it compresses the whole page to the new height, the old vertical rhythm (top bar, content, bottom bar) is crushed into two stumps. Either way, pre-keyboard coordinates are unusable. IMEs with a candidate bar (Chinese among them) eat more than a “standard keyboard” screenshot; an inset measured on an English keyboard will be short by that bar.
Keyboard height also moves with device and mode: floating, split, landscape — each is a new map. Measuring one mode is not measuring.
Where it stops holding
An external keyboard or a desktop has no such system layer; the viewport is not rewritten. Password managers and one-time-code autofill bars eat a thinner strip that still rewrites neighbours. Voice input swaps the keyboard for a mic bar of a different height; an inset hard-coded to the keyboard leaves a hole or still covers. In split view the keyboard may belong to the other pane, the app’s own half-height unchanged, and this rewrite does not occur.
Applying it
- Treat “keyboard up” as a layout state of its own, not a cover on the old layout. Tab bars, FABs and flush submits have to find a new place in this state, or yield to the top of the keyboard.
- Drive the state from the system inset / visual-viewport change. Do not hard-code one keyboard height.
- Measure once each for a Chinese candidate bar, an emoji panel and a voice bar, and confirm no control is still sitting on the old, now-covered bottom.
- How to check: focus every field that raises a keyboard, shoot before and after. If the relative positions of the primary button, the current field and the error copy on the two shots only make sense on the before-shot, a piece of the after-shot is already gone.