D1.05.2Hover-induced layout shiftdesignresearch

Hover should not cause layout shift

Aliases: layout shift · pointer instability · hover jitter · interaction stability

What it is

Hover-induced layout shift occurs when pointer entry changes component size, text wrapping, neighboring positions, or page extent, moving a target that had been stable. Hover is meant to support exploration; when it pushes an object away, ejects the pointer from its hit area, or repositions neighbors, it undermines action. Typical cases include bold text causing a wrap, a new border enlarging a card, added explanation pushing a button down, or a menu opening beneath the pointer.

Why it happens

Pointer interaction assumes a target remains spatially stable between approach and click. If entering a state changes the box model or document flow, a person’s motor plan is suddenly outdated. Small shifts are especially costly in dense targets, narrow menus, and high zoom. The worst case is oscillation: a shift ends hover, reset triggers it again, and the area flickers or becomes impossible to enter. Visual motion can draw attention, but when it changes hit regions or surrounding layout it converts a signal into control noise.

Studying it

Use real mice and trackpads for menu browsing, card comparison, and small-target clicks; record pointer exits after entry, retries, wrong clicks, and task time. Observe across zoom, text length, localization, viewport width, and system pointer speed—default-copy recordings often miss wrapping shifts. Layout instrumentation can identify jumps in position and size, but observation must establish whether they occur while a person needs to hold a pointing trajectory rather than treating every animation as a defect.

Where it stops holding

Not every visual change on hover is forbidden. Color, opacity, shadow, overlays, and previews outside document flow can reinforce feedback. An intentionally expanding menu or detail view may alter space if it has predictable entry, forgiving corridors, and does not escape under the pointer. Keyboard-focus and touch-expansion shifts have different risk patterns. The relevant question is whether a change interrupts an ongoing pointing action.

Applying it

  • Use background, inset shadow, transforms, or reserved borders that do not change occupied size; avoid layout-participating text, borders, or content on hover.
  • Give expanding menus, cards, and tooltips stable anchors and forgiving pointer corridors between trigger and layer.
  • Run layout regression with longest localized copy, narrow breakpoints, and high zoom; check whether font weight or explanatory content moves neighbors.
  • Observe rapid scanning of dense targets. In/out jitter, misclicks, or “chasing” an element are hover-design failures.

Related

  • Within the group: D1.05.1 Hover affordance · D1.05.3 A touch alternative for hover information
  • Adjacent: D1.10 Feedback location · D1.14 Feedback duration
  • Search terms: hover-induced layout shift · pointer instability · hover jitter

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/D1.05.2