Chip wrapping causes layout jump
Aliases: chip wrapping · layout shift · row-height jump
What it is
When chips will not fit the container they wrap to the next line, the selection region grows, and fields, buttons, or lists below are pushed. That layout shift often lands in the instant someone was aiming at the next target: the coordinates have moved, so they hit the wrong thing or think the UI jumped on its own. Wrapping is a legal result of too little space; what is not acceptable is height lurching up and down during add/remove while clickable neighbours are not held still.
The chips themselves are not what jumps; everything they shove is.
Why it happens
Pointing pre-aims a screen coordinate. Wrapping changes the selection’s bounding box, so every element “under it” moves with it. The pre-aim fails, and the finger or pointer lands on a newly wrapped chip or on a submit button that has risen. Adding one chip may take the region from one row to two; removing one collapses it again, so coordinates jitter inside a single task.
If animation plays the chip’s appearance without a planned yield from content below, the whole page appears to bounce. Forbidding wrap to prevent shift merely overflows or shrinks chips until they cannot be read — trading shift for truncation, moving the problem from layout to recognition.
Where it stops holding
A chip region that scrolls internally (horizontal, or a fixed-height vertical) can contain the shift inside the control, at the cost of no longer seeing the whole selected set at once. Shift hurts most when chips sit directly above a footer action, because submit is a high-cost target. Growing while the user is still looking at the chips is cheaper than growing after they have already moved toward the footer. A virtual keyboard lifting the viewport stacks with wrap; mobile shift is often underestimated. Print and read-only echoes are not pointing tasks, so shift does not cause mis-taps, but it still breaks reading rhythm.
Applying it
- Reserve a stable height of at least two chip rows, or scroll inside the control, so the first wrap does not shove the whole form.
- Keep submit and other costly actions a safe distance from the chip region, not in the path of the first extra row.
- If height must change, let content below yield smoothly; do not let a button slide under a finger on the frame it lands.
- How to check: on the narrowest width, grow from zero chips to wrapping, and record the footer button’s y-coordinate. If it jumps while a finger is in motion, that is the shift to fix.