Already-interactive regions must not be reflowed by late content
Aliases: freeze hittable region · post-interactive reflow · lock input geometry
What it is
Once a region can take clicks, focus, or gestures, the user is already planning motion against its current geometry. If late content reflows that region afterward, the spatial model is void. Do not reflow an already-interactive region means: freeze that region’s position and size in flow once it is hittable, and let late nodes grow somewhere else. The rule is “don’t move UI that is already in use,” not first-paint shift in general, and not the hit-test mechanics of a misclick.
Why it happens
Interactivity turns pixels into an input surface. The user holds short-term spatial memory of that surface: where the button is, how long the form is, which passage the scroll offset maps to. Late content that changes the surface’s used box or its viewport position breaks the match. Unlike blank time before frame one, the user is already operating. Unlike “any late node can push painted nodes,” the constraint here attaches only to the cluster that has opened for input, not to every node on the page.
In engineering terms: an interaction cluster (primary nav, checkout bar, the form being filled) must keep a stable containing-block height and a stable flow prefix once it is hittable. Ads or recs that still need to appear go outside that cluster, into regions that are not yet input surfaces, or into a layer that does not push the cluster.
Where it stops holding
Reflow the user caused (opening filters, a keyboard pushing the visual viewport) is a consequence of the action, not late content. Virtual keyboards and system chrome may scroll the page to keep a focused field in view; that is platform behavior. Object motion inside a game, canvas, or map is not document reflow. If a blocking overlay covers the page until it is ready, there is no interactive region yet and this rule has not started. Read-only signage with no input has nothing whose geometry to freeze.
Applying it
- Mark nav, submit bars, and in-progress forms as interaction clusters: async modules inside them need reserved size; no new in-flow block above the cluster.
- Content that arrives after the first screen is hittable appends below the cluster or into a sidebar, not into the cluster’s flow prefix.
- On checkout, send, and pay, lock the height of the header and the form prefix once a field is focused.
- Verify by injecting a top bar or ad while the form is already editable; the focused field’s viewport coordinates and the submit button’s hit rect should match before and after.
Related
- Same group: R3.05.1 Late-arriving content pushes already laid-out nodes · R3.05.2 Displacement causes misclicks · R3.05.3 Dynamic content needs reserved space · R3.05.4 Render-blocking resources determine the first visible moment · R3.05.6 Async inserts should occupy positions that do not interrupt reading
- Adjacent: R3.15 First-paint metrics and interaction readiness · I2.07 Perceived performance
- Search terms:
interactive region·reflow·layout shift
Cards in the same group
- R3.05.1Late-arriving content pushes already laid-out nodes
- R3.05.2A control that moves after render steals the tap meant for it
- R3.05.3Dynamic content needs reserved space
- R3.05.4Render-blocking resources determine the first visible moment
- R3.05.6Async inserts should occupy positions that do not interrupt reading