When a popover's preferred placement would run off the screen edge, how should a design system's placement rules decide where it goes?

## What collision-aware placement means A **popover** or **tooltip** is anchored to a trigger and drawn beside it. Its **preferred placement** — which side of the trigger and how it aligns — is a design decision in the component's spec. **Collision-aware placement** is the set of rules that decides what happens when the preferred placement would push the panel outside the visible area: off the screen edge, under a system bar, behind the on-screen keyboard. Without such rules, panels near an edge are clipped, and a bank's fee explanation beside the right-hand balance column simply loses its last words. ## The resolution order Most systems resolve placement in a fixed order, so the outcome is predictable: 1. **Preferred placement.** For example, below the trigger, aligned to its start edge, with a small offset. 2. **Flip.** If the panel overflows on its main axis, try the opposite side: below becomes above. 3. **Shift.** If it now fits vertically but overflows sideways, slide it along the edge until it sits inside a safe margin. 4. **Move the arrow.** After a shift, the arrow moves along the panel's edge so it still points at the trigger. 5. **Constrain.** If no side has room, cap the panel's size to the available space and let its content scroll. 6. **Switch presentation.** On very small screens, many systems present the same content as a bottom sheet instead of a floating panel. ## Rules that keep it predictable - **Do not cover the trigger.** A panel that hides its own trigger confuses the user about what opened it, and content that obscures other content must be dismissible under WCAG 2.2 1.4.13 Content on Hover or Focus when it appears on hover or focus. - **Logical, not physical, sides.** Specify 'start' and 'end' rather than left and right, so a right-to-left locale mirrors placement automatically. - **Safe areas count as edges.** Rounded screen corners, camera cut-outs, system bars and the on-screen keyboard reduce the usable area on phones. - **Recompute when things move.** Scrolling, resizing, rotating the device and the keyboard appearing all change the available space. - **Close or hide when the trigger leaves.** If the trigger scrolls out of view, a panel floating over unrelated content is worse than no panel. - **Keep the offset constant.** The gap between trigger and panel stays the same whichever side wins, so flipped panels look intentional — and a hover-opened panel stays close enough to be hoverable. - **Keep the arrow off the corners.** When a shift pushes the arrow toward a corner of the panel, stop it a small distance from the corner so it still reads as attached. - **Do not animate the flip.** A panel that visibly jumps from one side to the other when space changes draws attention to the mechanism rather than the content; recompute and redraw it in place. ## Placement options at a glance | Situation | Result of the rules | |---|---| | Room on the preferred side | Preferred placement, arrow centred on the trigger | | Trigger near the bottom edge | Flip above | | Trigger near a side edge | Shift inward, arrow moves toward the edge | | Little room anywhere, large content | Constrained height with internal scrolling | | Narrow phone screen, rich content | Bottom sheet instead of a floating panel | ## Example: the bank app's account list In a retail bank's mobile app, each account row has an info icon at its right end, and its popover prefers to open below, aligned to the icon's end. For the last row on screen, 'below' would sit behind the tab bar, so the popover flips above. On a narrow phone the panel is wider than the space left of the icon's end, so it shifts inward, and its arrow slides right to keep pointing at the icon. When the user turns the phone to landscape, the placement is recomputed; when they scroll the list and the row leaves the screen, the popover closes. ## Where the mechanics live The design system's job is the **rule set** above, written once in the overlay specification and implemented once in a shared positioning utility that every tooltip, popover and menu uses. How each platform computes it differs — anchor positioning or a positioning library on the web, the platform's own popover presentation on native mobile — but the fallback order, the arrow behaviour and the safe-area rules should read the same on both, so a user moving between the bank's web and mobile apps sees the same behaviour.