Popover Light Dismiss, Nesting and Stacking
The HTML popover attribute gives overlays a lot of behaviour for free: they render in the top layer above everything, open and close from buttons without script, and close when the user clicks elsewhere or presses Escape. Most tutorials stop at a single popover. Real interfaces have several: a menu with a submenu, a tooltip inside a menu, a toast that should survive a click elsewhere, a settings panel that must not close when a date picker opens inside it. How popovers interact — which ones close when another opens, what order they stack in, where focus goes — is governed by a small set of rules. This page lays them out and shows how to build nested and coexisting overlays that behave predictably. It belongs to Anchor Positioning & Overlays in the Mastering Container Queries & Responsive Layouts guide.
Why popovers need rules for each other
A single dropdown is simple: open it, click outside, it closes. Two dropdowns raise questions. Opening the second should usually close the first — two open menus at once is confusing. But a submenu opening from inside a menu must not close its parent. A notification must not vanish because the user clicked a menu. And whichever is open most recently should be on top.
Before the popover API, every overlay library answered these questions differently, and mixing libraries produced overlays that fought: a date picker inside a modal closing the modal, two dropdowns open at once, a tooltip stranded behind a menu. The popover API standardises the answers so native overlays from different sources cooperate.
The three popover types
auto(the default) is for overlays the user opens deliberately and expects to close by clicking away: menus, pickers, disclosures in the top layer. Opening an auto popover closes other auto popovers that are not its ancestors.hintis for transient, supplementary overlays such as tooltips. A hint closes other hints when it opens but does not close auto popovers, so a tooltip can appear inside an open menu without destroying it.manualis for overlays that manage their own lifetime: toasts, persistent panels, coach marks. They ignore light dismiss and never close others.
The complete implementation: a menu with a submenu
The page below has a menu whose "Share" item opens a submenu. The submenu stays open while the user works in it, and clicking outside closes both.
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Nested popovers</title>
<style>
body { font: 15px/1.5 system-ui, sans-serif; margin: 2rem; }
[popover] {
margin: 0;
padding: 0.35rem;
border: 1px solid #cbd5e1;
border-radius: 10px;
background: #ffffff;
box-shadow: 0 10px 30px rgb(15 23 42 / 0.15);
}
[popover] button {
display: block;
inline-size: 100%;
min-inline-size: 10rem;
padding: 0.45rem 0.7rem;
border: 0;
border-radius: 6px;
background: transparent;
font: inherit;
text-align: start;
}
[popover] button:hover, [popover] button:focus-visible { background: #eef2ff; outline: none; }
.trigger:focus-visible { outline: 2px solid #4338ca; outline-offset: 2px; }
/* Anchor each popover to its own trigger. */
.trigger { anchor-name: --file; }
#file-menu { position-anchor: --file; position-area: block-end span-inline-end; }
.share-trigger { anchor-name: --share; }
#share-menu {
position-anchor: --share;
position-area: inline-end span-block-end; /* beside the item */
position-try-fallbacks: flip-inline;
}
</style>
</head>
<body>
<button class="trigger" type="button" popovertarget="file-menu">File ▾</button>
<div id="file-menu" popover>
<button type="button">New</button>
<button type="button">Open…</button>
<!-- Because this trigger is INSIDE #file-menu, #share-menu becomes its
child in the popover stack: opening it keeps #file-menu open. -->
<button class="share-trigger" type="button" popovertarget="share-menu">Share ▸</button>
</div>
<div id="share-menu" popover>
<button type="button">Copy link</button>
<button type="button">Email</button>
</div>
</body>
</html>
The submenu's popovertarget button sits inside the parent popover. That DOM relationship is what makes the browser treat the submenu as a child in the popover stack. Without it — if the "Share" trigger lived elsewhere — opening the submenu would close the file menu, because it would be an unrelated auto popover.
The key technique: the popover stack
Open auto popovers form a stack. When a new auto popover opens, the browser looks at its invoker — the button that opened it — and checks whether that invoker is inside a popover already in the stack. If so, the new popover is pushed as that popover's child and the ancestors stay open. If not, every open auto popover that is not an ancestor is closed first.
Escape closes only the topmost popover, so a user in a submenu presses Escape once to return to the parent menu and again to close it, which matches desktop menu conventions. Light dismiss — a click outside — closes every popover above the point clicked; a click inside the parent menu but outside the submenu closes only the submenu.
Painting order follows the stack too. Every element in the top layer paints above the page, and later additions to the top layer paint above earlier ones, so the submenu is always drawn over its parent without any z-index. That is also why z-index has no effect on top-layer elements relative to each other: their order is the order they were shown.
Mixing types: a tooltip inside a menu
A tooltip explaining a menu item should appear without closing the menu, and a new tooltip should replace the old one. That is exactly the hint behaviour. Where hint is not supported it falls back to manual, which never light-dismisses; either way the menu survives.
<div id="file-menu" popover>
<button type="button" popovertarget="export-hint" popovertargetaction="toggle"
aria-describedby="export-hint">Export…</button>
</div>
<div id="export-hint" popover="hint" role="tooltip">Saves a copy in another format.</div>
For tooltips shown on hover and focus rather than on click, the anchoring and timing techniques are covered in Anchor-Positioned Tooltips and Hover Intent Delays With transition-delay. Toasts should be manual, so a user clicking a menu does not accidentally dismiss a message they have not read.
Popovers inside dialogs, and dialogs above popovers
Modal dialogs also live in the top layer, and they interact with popovers in two useful ways. A popover opened from a button inside a modal dialog appears above the dialog, because it was added to the top layer later, and it light-dismisses normally within the dialog — so date pickers, menus and comboboxes inside a modal just work. Opening a modal dialog while auto popovers are open closes those popovers, since the dialog makes the rest of the page inert and a menu left floating over an inert page would be unusable.
Two practical consequences follow. First, a settings panel built as a modal <dialog> can host any number of popover-based controls without special handling. Second, a "confirm" dialog launched from a menu item does not need script to close the menu first — the browser does it. The animations for both layers, including keeping the closing menu visible for its exit transition, are covered in Animating dialog Open and Close.
Focus and accessibility
Popovers are not modal: the rest of the page remains interactive and in the tab order. When a popover opened by a popovertarget button closes via Escape or light dismiss and focus was inside it, browsers return focus to the invoking button, which keeps keyboard users oriented. The invoking button also receives the correct aria-expanded state automatically.
What the popover API does not provide is menu semantics or arrow-key navigation. A popover of buttons is announced as a group of buttons, which is acceptable for simple action menus; for application-style menus following the ARIA menu pattern, add role="menu", role="menuitem" and arrow-key handling with script. Keep every item reachable by Tab in the meantime, so the menu is operable even without the enhanced keyboard support.
Browser support
The popover attribute with auto and manual is supported in Chrome and Edge 114+, Firefox 125+ and Safari 17+, including the nested popover stack and light dismiss. popover="hint" is newer and supported in current Chromium releases; elsewhere it behaves as manual. Anchor positioning, used to place the menus, is supported in Chrome and Edge 125+, Firefox 147+ and Safari 26+; without it, popovers appear centred in the viewport but keep their stacking and dismissal behaviour.
FAQ
What is light dismiss?
Closing a popover when the user clicks or taps outside it or presses Escape. Popovers with popover="auto" get light dismiss automatically; popover="manual" popovers do not and stay open until closed explicitly.
How do nested popover menus stay open? An auto popover opened from a trigger inside another auto popover becomes its child in the popover stack. Opening the child does not close the parent, and clicking inside the child does not light-dismiss the parent. Clicking outside both closes the whole chain.
What is the difference between auto, manual and hint popovers?auto popovers light-dismiss and close other unrelated auto popovers when opened. manual popovers never light-dismiss and do not affect others. hint popovers, intended for tooltips, close other hints but leave open auto popovers alone.
Where does focus go when a popover closes?
When a popover opened by a popovertarget button is closed with Escape or light dismiss, focus returns to the button if focus was inside the popover. Test this in each browser you support, since top-layer focus handling has been refined across releases.
Related
- Anchor Positioning & Overlays — the parent guide.
- Popover Attribute and CSS Styling — styling states of a single popover.
- anchor-size(): Overlays That Match Triggers — sizing the menus in this stack.
- Dialog & Popover Animations — animating each layer as it opens and closes.
Related articles
More pages in the same section.