20 CSS Popovers

Two attributes and no JavaScript. Put popover on the element you want to float and popovertarget="its-id" on the button that opens it — that is the whole setup. The browser then hands you four behaviours for free that people used to write libraries for: the panel is promoted to the top layer, so it escapes any ancestor with overflow: hidden and ignores z-index entirely; clicking outside closes it; Escape closes it; and focus returns to the trigger on close. The top-layer behaviour is the one that changes how you build. A dropdown inside a scrolling table or a transformed card used to require portalling the panel to the end of the body to stop it being clipped — with popover the element stays where it belongs in your markup and still renders above everything. Pair it with popovertargetaction="show" or "hide" when you want a dedicated open or close control rather than a toggle.

popover="auto" (the default, so bare popover means the same thing) is dismissive: clicking outside closes it, Escape closes it, and opening a second auto popover force-closes the first unless they are nested. That is what you want for a menu, a tooltip or a profile flyout — the user should be able to click away and carry on. popover="manual" opts out of all of it. Nothing closes it except an explicit popovertargetaction="hide" button or a hidePopover() call, and several manual popovers can sit open at once. Reach for manual when closing would lose work: a filter menu the user is ticking several boxes in, a persistent panel, an inline editor. The mistake is choosing manual because auto felt unpredictable — if a menu keeps vanishing when you open another, that is nesting being declared wrongly rather than a reason to abandon the light-dismiss behaviour you actually want.

CSS Anchor Positioning, which is a separate feature that composes with popover. Give the trigger anchor-name: --my-anchor, give the panel position-anchor: --my-anchor, then place it with position-area — a nine-cell grid around the anchor, so position-area: block-end puts the panel below and block-start inline-end puts it above and to the right. This is what replaces the measure-on-scroll-and-resize loop that Popper and Floating UI exist to run. Two things to know. Anchor names are global, so scope them per component or two instances of the same widget will fight over the same name. And support for anchor positioning lags support for popover itself — a browser can have one without the other, so gate them with separate @supports checks and let the panel fall back to a plain absolutely-positioned element rather than assuming both arrived together.

Because a popover moves between display: none and the top layer, and neither transitions by default. The recipe has three parts and missing any one of them silently breaks it. First, @starting-style declares the values the element animates FROM on first paint — without it there is no starting point and the panel just appears. Second, transition-behavior: allow-discrete lets discrete properties like display participate in the transition instead of flipping instantly. Third — and this is the one almost everyone misses — you must include overlay in the transition property list, because overlay is what keeps the element in the top layer; without it the panel drops out of the top layer the moment closing starts and the exit animation plays behind everything else on the page. One ordering trap: the @starting-style rule has to come after the open-state rule it refers to, or it loses the cascade and does nothing.

position-try-fallbacks. Declare the alternatives you will accept — flip-block, flip-inline, or both — and the browser tries the preferred position-area first, then each fallback in order until one fits the viewport. For finer control, write a named @position-try block with its own placement and margins and reference it by name. Two details make it work in practice. The fallback only fires when the panel would genuinely overflow, so test it with the anchor pushed close to an edge rather than in the middle of a comfortable layout. And anything visually tied to the anchor — a tooltip arrow especially — has to be positioned against the anchor rather than the panel, or it stays pointing the original direction after the panel flips and ends up detached, which looks worse than no arrow at all.

The question is whether the user is allowed to ignore it. Use <dialog> with showModal() when they must deal with it first: focus is trapped inside, the rest of the page goes inert, and the backdrop blocks interaction. That is right for a destructive confirmation, a required form, a blocking flow. Use popover when they can look at it and carry on: menus, tooltips, flyouts, filter panels, notifications. Focus is not trapped, the page stays interactive, and clicking elsewhere dismisses it. The common error is reaching for a modal because it is the pattern you know, and trapping a user inside a dropdown they only wanted to glance at. The features do overlap — a <dialog> can carry a popover attribute for non-modal use — but treat modality as the deciding question and the choice is usually obvious.

Partly, and knowing the gap is the point. The browser gives you keyboard dismissal with Escape, focus returning to the trigger on close, and correct top-layer rendering. It does not give the panel a role, an accessible name, or any relationship to its trigger — a popover is a generic element until you say otherwise. So you own three things. Put aria-expanded on the trigger and keep it in sync, because nothing does that for you and a screen reader user otherwise has no idea whether the panel is open. Give the panel the role its content deserves: menu with menuitem children for a menu, listbox with option children for a select. And if the panel is a hint describing the trigger, wire aria-describedby rather than using role="tooltip" on something click-triggered, which contradicts what a tooltip is. Keyboard navigation inside the panel — arrow keys, typeahead, roving tabindex — is still yours to implement.

Better than most CSS, because the API is declarative and lives in markup rather than state. The seventeen pure-CSS demos need no JavaScript in any framework: popover and popovertarget are plain attributes, so they pass straight through JSX and templates. React needs one accommodation — attribute casing. Write popover="auto" and popoverTarget in JSX, and note that React versions before 19 did not pass unknown attributes through cleanly, so on older versions you may need ref plus setAttribute. Where you do call the imperative methods, guard them: showPopover() and hidePopover() throw if the element is not in the document or not currently in the required state, so wrap them in try/catch or check matches(':popover-open') first. In Next or Nuxt, feature detection must run in an effect rather than the component body, since HTMLElement does not exist during the server pass. For Tailwind the panel is a short utility chain plus the open: and starting: variants.