Popover auto, manual and hint: What's Actually the Difference? I Built Demos to Find Out

2026/10/09 update: the demos and code now use Invoker Commands (command / commandfor); the original popovertarget approach still works. I also added a section on replacing the trigger JavaScript with interestfor.

--

Up front: these are my own notes from practicing popover="hint". Browser support moves fast, so what's true as I write this may not stay true. If I've gotten something wrong, corrections welcome.

Intro

In my modern CSS & HTML cheat sheet, popover="hint" was one of the boxes I still hadn't ticked.

Reading the docs, I thought I got it. It's "the popover for tooltips," right? But when I tried to explain how it actually differs from auto and manual, I realized I couldn't really say. So I put all three side by side and built a demo for each one. Playing with it once beats reading the spec ten times.

Before we start, here's what your browser supports. The demos below adapt to this result:

How the three values differ

The popover attribute really decides just two things:

1. Whether clicking outside or pressing Escape closes it (light dismiss)
2. Whether opening it closes other popovers

The table is still a bit abstract, so let's go through them one at a time.

auto: the default for menus

Writing popover with no value gives you auto. Only one can be open at a time, and clicking outside or pressing Escape closes it, which makes it a natural fit for menus and dropdown panels.

<button commandfor="menu" command="toggle-popover">Open menu</button>
<div id="menu" popover>…</div>

Try it: open A, then B, and A closes on its own. Click an empty part of the page or press Escape, and B closes too.

The buttons use Invoker Commands: commandfor says what to control and command says what to do. The older way is popovertarget, which still works but can only control popovers; command can also control <dialog>, so I now use command everywhere. In browsers without Invoker Commands, the demos automatically switch back to popovertarget.

The nice part is that none of this needs a single line of JavaScript. "Close when clicking outside" used to mean listening for clicks on the document and checking whether they landed inside the menu. Now it's one attribute.

manual: entirely up to you

A manual popover doesn't close on an outside click or Escape, and it doesn't close others, so several can be open at once. It suits things that should stay on screen, like a toast. The trade-off is that you have to provide the way to close it.

<div id="panel" popover="manual">
  <button commandfor="panel" command="hide-popover">Close</button>
</div>

Try it: open both A and B and they stay open together. Clicking outside or pressing Escape does nothing; only the Close button inside each panel works.

hint: finally, a value for tooltips

Before hint, building a tooltip with popover left you two not-great options:

• Use auto: with a menu open, you hover a menu item to see its tooltip, the tooltip opens, and the menu closes. That's simply unusable.
• Use manual: nothing interferes, but Escape, outside clicks and several tooltips open at once are all yours to handle.

hint fills exactly that gap. It keeps light dismiss, but it ranks below auto: opening one only closes other hint popovers and leaves an open menu alone.

<button aria-describedby="tip-save">Save</button>
<div id="tip-save" popover="hint" role="tooltip">You can also press Ctrl+S</div>

Tooltips usually appear on hover or keyboard focus rather than on click. The demo originally used JavaScript to call showPopover() on pointerenter and focus; now that can be handed to interestfor, and the next section compares the two.

Try it: hover a button or Tab to it and the tooltip appears. Move from Save to Export formats and the first tooltip closes on its own. You can also move the pointer onto the tooltip without it disappearing.

Going further: replacing the trigger JavaScript with interestfor

First, something I mixed up myself at the start: popover="hint" and interestfor aren't alternatives. They work at different levels.

So they're designed to be used together: interestfor handles the trigger, hint handles the behavior.

With a JavaScript trigger, you handle pointer enter and leave, focus and blur, plus the WCAG-driven "wait a moment after leaving the button, and cancel if the pointer moves onto the tooltip" logic. In the demo that came to about 60 lines:

trigger.addEventListener("pointerenter", () => show(tip));
trigger.addEventListener("pointerleave", () => hideSoon(tip));
trigger.addEventListener("focus", () => show(tip));
trigger.addEventListener("blur", () => hideSoon(tip));
tip.addEventListener("pointerenter", () => cancelHide(tip));
tip.addEventListener("pointerleave", () => hideSoon(tip));
// ...plus delay timers and checking whether the pointer is still on the tooltip

With interestfor, it's one attribute:

<button interestfor="tip-save" aria-describedby="tip-save">Save</button>
<div id="tip-save" popover="hint" role="tooltip">You can also press Ctrl+S</div>

Hover, focus, touch long-press, the delays, staying open while the pointer is on the tooltip, and Escape to dismiss are all handled by the browser. You can tune the delays in CSS:

button {
  interest-delay: 0.3s 0.5s; /* start delay, end delay */
}

Against the WCAG 1.4.13 table below, "hoverable," which you used to add yourself, is now built in. The semantics are unchanged, though: I'd still write role="tooltip" and aria-describedby explicitly.

The hint demo above now works exactly like this: browsers with interestfor use it natively, and only browsers without it get the JavaScript fallback. Below the demo it shows which one your browser is using, so try it in both Chrome and Safari to see the difference.

Lab: all three together

Each one makes sense on its own, but you only see why hint exists when they're combined. This lab has an auto menu whose items each have a hint tooltip, plus a manual toast. The event log lists every popover opening and closing as it happens, so you can see exactly what closes what.

Suggested order:

1. Press Show toast first to open the manual toast.
2. Press File menu to open the auto menu. The toast isn't affected, and both stay open.
3. Hover a menu item or Tab to it. The tooltip appears, and the menu stays open.
4. Move between items. The old tooltip closes, the new one opens, and the menu stays put.
5. Press Escape once to close the tooltip, then again to close the menu. The toast stays until you press its own Close button. (Browsers that use interestfor have an exception; see "One Escape, two layers closed" below.)

If the tooltips on the menu items were auto, step 3 would close the menu as soon as a tooltip opened. That's the whole reason hint exists.

One small gotcha I only noticed while building this: with the menu open, pressing Show toast closes the menu first. That click lands outside the menu, so it triggers the auto light dismiss. It's exactly the right behavior, I just didn't see it coming, which is why the steps say to open the toast first.

A pitfall found later: one Escape, two layers closed

After publishing this post, I retested step 5 in Chrome 154 (Chromium 153 behaves the same) and found the result depends on how the tooltip was opened:

Tracing the event order: a single Escape first triggers interestfor's "lose interest", which closes the tooltip, and then the popover's own Escape handling closes the next layer down, the menu. If you call preventDefault() unconditionally on keydown, that Escape does nothing at all: neither the tooltip nor the menu closes. In my tests in Chromium 153, there are two ways to close only the tooltip: in keydown, call preventDefault() only while the tooltip is open and close it yourself with tip.hidePopover(); or use a CloseWatcher. Both give the same result, and CloseWatcher is cleaner because you don't handle the key yourself.

The first case conflicts with WCAG 1.4.13's "dismissible without moving focus": the user only wanted to close the tooltip, but the whole menu disappears and focus moves. So the demo now creates a CloseWatcher when the tooltip opens, making the first Escape close only the tooltip:

tip.addEventListener("toggle", (event) => {
  if (event.newState !== "open") return;
  const watcher = new CloseWatcher();
  watcher.onclose = () => tip.hidePopover();
  // Clean up the watcher when the tooltip closes
  tip.addEventListener("toggle", () => watcher.destroy(), { once: true });
});

I confirmed it in Chromium 153: removing the CloseWatcher from the demo reproduces "two layers closed", and with it in place the first Escape closes only the tooltip while focus stays on the menu item. This looks more like a Chrome implementation issue. I haven't tested other browsers yet, and I'll update this if anything changes.

One more trap: if you give a popover a display, hide it yourself

I hit this one for real while testing the demo: after closing the menu, I moved the mouse over where the menu used to be, and a tooltip popped up.

The cause was the display: grid I'd given the menu for layout:

.menu {
  display: grid;
}

The browser normally applies display: none to a closed popover, but that rule lives in the browser's built-in stylesheet, which has the lowest priority. As soon as you write your own display, it wins. So the closed menu never actually disappeared. My other styles had only made it transparent, and the elements were still sitting in place:

• Hovering the invisible items still triggered hover, which is why the tooltip appeared.
• Worse, keyboard users could Tab onto those invisible buttons. I confirmed this with an automated test: before the fix, pressing Tab through the page landed focus on each item of the closed menu, one after another. For keyboard and screen reader users, that means interacting with a menu they can't see.

The fix is simple. Put the hiding back yourself:

.menu {
  display: grid;
}

.menu:not(:popover-open) {
  display: none;
}

If you add a fade-out (a transition with display and allow-discrete), the element is still reachable for that brief fade. The demo adds one extra safeguard for that: if a tooltip's trigger sits inside a popover that isn't open, the tooltip doesn't show.

The one-line takeaway: whenever you give a popover a display, add :not(:popover-open) { display: none; } too.

Building tooltips with hint: you still own the accessibility

This is the part I think matters most: popover only handles showing and hiding. It adds no semantics for you.

WCAG 1.4.13 Content on Hover or Focus has three requirements, and hint covers only part of them:

Two more points:

• Add the semantics yourself: give the tooltip role="tooltip" and point to it from the button with aria-describedby, so screen readers announce it as a description.
• Keep interactive elements out of tooltips: once there's a link or button in it, it isn't a tooltip anymore. Make it an auto panel the user opens instead.

What happens without support?

This is different from hidden="until-found", which I looked at earlier, so it needs extra care.

In a browser without support, until-found just falls back to a plain hidden: the content can't be found by search, but nothing breaks. A browser that doesn't recognize a popover value, though, treats it as manual. So in a browser without hint support, your tooltips can't be closed with Escape or an outside click, which fails the "dismissible" requirement above.

Detecting it isn't hard:

const probe = document.createElement("div");
probe.popover = "hint";
const supportsHint = probe.popover === "hint";

Without support, you can fall back to auto, or add Escape handling yourself as the demos here do. hint is supported from Chrome 133; support in other browsers changes quickly, so check caniuse and MDN before shipping.

Conclusion

In short:

• Menus and dropdown panels: use auto.
• Toasts and persistent panels: use manual, and give people a way to close them.
• Tooltips: use hint, but the semantics, hover tolerance and an Escape fallback are still on you.

hint doesn't solve a big problem. It fixes one small thing: tooltips and menus fighting each other. But small things like this are exactly what used to get rushed and then turn into accessibility issues later. Less code and one fewer trap to fall into seems well worth it to me.

That's one more box ticked on my list. How do you build tooltips in your projects? I'd love to hear about it.

Related reading

• Why Can't Ctrl+F Find Collapsed Content? A Look at hidden="until-found"
• Modern CSS & HTML Cheat Sheet: 115 Features, Support & What to Try Next

Related links

• MDN — popover global attribute
• W3C — Understanding WCAG 2.2 SC 1.4.13 Content on Hover or Focus
• Can I use