Popover API — A Field Guide

For most of the web's history, if you wanted a dropdown menu, a tooltip, or a "click to reveal more" panel that had to render above everything else on the page, you reached for a JS library — or you hand-rolled a fixed-position div and fought z-index and outside-click detection yourself. The popover attribute closes that gap. It's a native HTML feature, not a framework component, and it handles the three hardest parts of building a popup: stacking above the rest of the page reliably, dismissing itself when the user clicks away or hits Escape, and wiring open/close/toggle behaviour to a button without a line of JavaScript.

What the popover attribute actually does

Add popover to any element and the browser takes it out of normal flow and renders it in the top layer — the same rendering layer native dialogs and fullscreen video use. That matters because top-layer elements are never clipped by an ancestor's overflow: hidden, and they never lose a z-index fight with anything that isn't also in the top layer. Every popup library exists partly to work around exactly that class of stacking bug; with a native popover, the browser has already solved it for you.

A popover starts hidden. You show it either by calling .showPopover() in JavaScript, or — more often — by pointing a button at it declaratively:

<button popovertarget="user-menu" popovertargetaction="toggle">
  Account
</button>

<div id="user-menu" popover="auto">
  <ul>
    <li><a href="/settings">Settings</a></li>
    <li><a href="/logout">Log out</a></li>
  </ul>
</div>

No click listener, no outside-click detector, no Escape-key handler. popovertarget links the button to the popover's id, and popovertargetaction says whether the button should show, hide, or toggle it — toggle is the default if you omit the attribute.

popover="auto" vs popover="manual"

This is the one distinction that actually matters when choosing how a given popover should behave. popover="auto" is light-dismiss: the browser closes it automatically when the user clicks outside it, presses Escape, or opens another auto popover. That's what you want for menus, comboboxes, and typeahead suggestions — the same behaviour you'd have spent an afternoon implementing with a `mousedown` listener on `document`. Auto popovers also close each other: opening a second auto popover closes the first, which is exactly how OS-level menus behave.

popover="manual" opts out of light-dismiss entirely. Nothing closes it except you calling .hidePopover() or a button with popovertargetaction="hide". Use manual for things the user shouldn't be able to dismiss by fat-fingering a click nearby — a multi-step inline editor, a persistent "toast" notification stack, or a widget where an accidental outside click losing all the user's input would be actively hostile.

Styling the dimmed background with ::backdrop

Popovers get their own ::backdrop pseudo-element, the same mechanism <dialog> uses for its modal overlay. You can style it to dim the rest of the page, which is useful for popovers that function like lightweight modals even though they're not `<dialog>` elements:

[popover] {
  border: 1px solid #e2e8f0;
  border-radius: 8px;
  padding: 1rem;
  inset: unset;
  top: anchor(bottom);
  left: anchor(left);
}

[popover]::backdrop {
  background: rgb(0 0 0 / 0.35);
}

[popover] {
  opacity: 0;
  transform: scale(0.96);
  transition: opacity 0.15s, transform 0.15s, overlay 0.15s allow-discrete,
    display 0.15s allow-discrete;
}

[popover]:popover-open {
  opacity: 1;
  transform: scale(1);
}

The allow-discrete transition trick lets you animate an element in and out of the top layer instead of having it snap into existence — the same pattern that's now standard for animating display: none transitions in modern CSS.

Hooking in with JavaScript when you actually need it

Most popovers need zero JavaScript. When you do need to react to state — closing a menu after a selection, lazily loading content the first time a popover opens, or syncing some other UI to the popover's state — there are two events: beforetoggle, which fires before the state changes and lets you inspect (but not cancel) the transition, and toggle, which fires after. Both carry an oldState/newState pair of "open"/"closed".

const menu = document.getElementById('user-menu');

menu.addEventListener('toggle', (event) => {
  if (event.newState === 'open') {
    // e.g. focus the first menu item, fetch fresh data, etc.
  }
});

Browser support and when to reach for it

The popover attribute is baseline supported in current versions of Chromium-based browsers, Firefox, and Safari — it's no longer an experimental feature gated behind a flag, and it's safe to use as your default for new dropdown, tooltip, and menu components. If you have a hard requirement to support noticeably older browser versions, check your actual analytics rather than assuming; for most consumer and internal web apps in 2026, the feature is well within reach. If you do need a fallback, a popover with no support at all simply doesn't render as a popup, so pair it with a `@supports selector(:popover-open)` check if graceful degradation matters for your audience.

Wrapping up

The popover attribute doesn't replace every UI library use case — it doesn't give you positioning logic as sophisticated as Floating UI, and it won't handle complex nested-menu accessibility trees for you. But for the plain dropdown, tooltip, and simple modal-adjacent panel that make up most of what teams pull in a library for, it removes the dependency entirely: no z-index debugging, no outside-click listener, no Escape-key handler, and a declarative `popovertarget` wire-up that reads clearly in the markup itself. If your popup logic is more plumbing than product, this is the plumbing the browser now does for you.