Popover

A popover is a small overlay anchored to the control that opened it. It is summoned by a click, can hold content and controls, and leaves the page behind it usable.

It occupies the middle of a family, and most misuse comes from reaching for the neighbour.

The test between a tooltip and a popover: does somebody need to click inside it? If yes, a tooltip will vanish as the pointer travels there. The test between a popover and a modal: must this be answered before anything else can happen? If yes, the popover's dismissibility is the wrong behaviour.

Positioning is most of the work

A popover is anchored, which means it has to cope with being near an edge, inside a scrolling container, or attached to something that moves.

Flip and shift. When there is not room below, open above. When there is not room to the right, shift along until there is. A popover that opens off-screen is the characteristic failure of a hand-rolled implementation.

Escape the clipping container. Anchored inside a scrollable panel, a popover rendered as a child gets clipped by it. Rendering into a portal at the document level, with the position computed against the trigger, is the usual answer.

Follow the trigger. If the page scrolls while it is open, it either follows or closes. Staying put while its anchor moves away is the version that looks broken.

Keep the arrow honest. If the arrow points at the trigger, it has to keep pointing at it after a flip or a shift.

This is enough fiddly geometry that positioning is one of the clearest cases for taking a library and styling it, rather than writing it. See component library.

Focus and dismissal

Focus moves in on open, to the first focusable element or to the popover itself.

Escape closes it, and focus returns to the trigger. Landing at the top of the document instead is disorienting for anybody not using a mouse.

Clicking outside closes it, with one exception: a popover containing unsaved input should confirm rather than discard. This is the same rule modals and drawers follow, for the same reason.

It is not modal. Focus should not be trapped, because the page behind is still usable and that is the point of choosing it.

Where it fits in B2B

Row actions. A menu on a table row, anchored to the row, without covering the list. See data table.

Filter and column pickers. Anchored to the control that opened them, dismissible, leaving the table visible behind — which is exactly what a modal takes away.

Quick detail previews. Hovering or clicking a reference to show enough to decide without leaving the page.

Confirmation for small destructive actions. A popover asking "Delete this row?" anchored to the row is lighter than a centred dialog and keeps the context. For anything larger, a modal is right.

Where it does not belong: forms of any length, anything the person must answer, and anything they will want to return to. Those want a drawer or a page.

In practice

A table has a row menu in a popover. It works in development and generates complaints from customers with long lists.

The cause is the scrolling container. The popover is rendered inside the table's scroll area, so on the last few rows it is clipped by the bottom edge, and the destructive action — always last in the menu — is the item that gets cut off.

Rendering into a portal with flip-and-shift positioning fixes it. The menu on the last row now opens upward, complete.

Nobody had seen it because development data never filled the viewport, which is the same reason most volume problems in this cluster go unnoticed.

Where teams get it wrong

• A tooltip that needs clicking. Gone before the pointer arrives.
• Clipped by a scrolling parent. The last row's menu, cut off.
• No flip near an edge. Content opening off-screen.
• Focus not returning to the trigger. Keyboard users left at the top of the page.
• A long form inside one. A drawer or a page, in the wrong container.
• Discarding input on an outside click. An easy gesture with an expensive result.