Popover

There used to be two ways to show a user something more, and both were extremes: send them to a new page, or darken everything and float a window on top. Either one takes away whatever they were looking at.

Changing the sharing setting on one document out of a list was the classic case. A window covering the background hides the list, and after closing it the user has to find which document they were editing. Clicking an avatar to reach the account menu and getting an entirely new page was just as common. A five-second task cost the loss of context every single time, and nobody filed it as a bug, because each individual case looked like the price of doing business.

What was missing sat between the two extremes: a layer that opens small right next to what was clicked, leaves the screen behind it alone, and simply closes when you click elsewhere. That's the slot a popover fills. Its character comes from being tied in position to the element that opened it — the anchor. The user knows the thing they just clicked and the thing that just appeared belong together, from position alone, with nothing having to say so.

It opens below or beside the element that was clicked and moves with it. Five things have to hold.

1. Attach it to the anchor. Four to eight pixels from the button or avatar is typical, and when the list behind it scrolls, the layer either follows its anchor or closes. A layer that appears in the middle of the screen gives no clue what it belongs to.
2. Open on click or tap only. Opening on hover leaves no way in at all on a screen used with fingers. This layer holds things to press, so the gesture that opens it should be a press too.
3. Flip direction when there's no room. If the anchor sits low on the screen with no space beneath it, the layer opens upward. Skip that and the last item in any list gets a clipped layer. Most component libraries handle the flip for you; hand-built ones usually don't.
4. Give three ways to close it: click outside, press Escape, click the anchor again. A close button on its own eats space in a small layer, and a layer that ignores an outside click leaves the user feeling stuck.
5. Move the selection point inside when it opens. The state of being selected by keyboard is focus, and if focus stays on the page behind, anyone relying on keyboard navigation — operating the product without a mouse — can't reach the layer that just appeared.

Not blocking the background is both the value and the limit of this layer. Context survives because the screen behind stays visible, but one stray click outside closes it. Which is why irreversible decisions and multi-field forms don't belong here.

Use it for work that stays in context and finishes quickly. The account menu behind an avatar, a filter panel above a list, changing the sharing scope on one item, picking a color, picking a date. What they share is that they take somewhere between five and fifteen seconds, and the result lands visibly on the screen behind.

There's a limit on how much it can hold: under a third of the screen height, with no scrolling inside. A scrollbar appearing inside is the signal that the content doesn't fit this layer, and at that point it moves to a drawer sliding in from the edge, or to a page of its own. The scrollbar is a more reliable signal than counting items, since the same list runs long on one screen size and short on another.

On small screens the pattern barely stands up. There's no space left beside the anchor, so the layer ends up covering half the display, and once it does, the advantage of not blocking the background is gone. The usual answer is shipping the same content as a sheet that rises from the bottom. Item sizes get revisited too: the minimum area reserved for a finger to press is the touch target, and a 24-pixel row designed for a mouse lands on its neighbor when a thumb tries it.

"A modal here hides the list behind it. Let's anchor a popover instead."

The judgment that the item being edited has to stay visible during the edit.

"There's a scrollbar inside the popover. That means the content doesn't fit this slot."

The size limit has been crossed, so it should move to another layer.

"There's nowhere to anchor it on mobile, so we moved it to a bottom sheet."

The same content ships in a different form on a small screen.

Noa moved the sharing settings on the Pagedeck document list into a popover. Before that it was a window covering the background, and in usability testing three of five people re-scanned the list after closing it to confirm which document they had just changed.

One problem survived the move. Theo implemented it so an outside click closes the layer, and a user editing a link expiry date clicked just outside the date field and lost the value being typed. Noa pulled the expiry setting out into a screen of its own and left only one-click items in the popover.

The most common mistake is treating it as the same thing as a tooltip. Both are small layers that appear next to an element, so nothing distinguishes them at a glance. What differs is the gesture that opens them and what they hold. A popover opens on a press and contains things to press; a tooltip appears on hover and contains an explanation. Mix the two and it breaks in both directions. Put a button inside a layer that opens on hover and the layer vanishes while the pointer travels toward it. Put nothing but an explanation inside a layer that opens on a click and the user reads it as nothing having happened.

The other frequent view is that anything can go inside, since the background isn't blocked. It opens lightly and closes lightly, so it feels low-stakes. But closing lightly means closing when the user didn't want it to. Fill in three fields, click somewhere on the page, lose the lot, and on the second attempt that person avoids the feature entirely. Multi-field input and delete confirmations move up to a layer that blocks.