Declarative popovers with the Interest Invoker API

Declarative popovers have moved from “nice idea” to practical reality on the web. With the Popover API now baseline across major engines and the emerging Interest Invoker API providing a standard way to open popovers on hover, focus, and long‑press, teams can ship hovercards and tooltips that work with much less JavaScript and far better accessibility. This article explains how Interest Invokers relate to popovers, their current status, and how to use them effectively.

We’ll look at what the interestfor attribute does, why its naming changed from interesttarget, how it integrates with the Popover API (including the new popover=”hint” mode), and the ecosystem context around standards, browser support, accessibility, and future‑proofing. You’ll leave with concrete markup patterns, migration guidance, and realistic expectations for shipping today.

What Interest Invokers are and why they matter

Interest Invokers are a proposed HTML attribute, finalized under the name interestfor, that lets an element declare a relationship to a target such that when the user “shows interest” in the invoker, by hovering with a mouse, focusing via keyboard, or long‑pressing on touch, the browser can take a default action for that target. For popovers, that default action is to show or hide the popover without you writing any JavaScript.

The idea originated in the Open UI community, which surveyed popular sites and found that over 94% include hover‑triggered UI like tooltips or hovercards, often with inconsistent accessibility for keyboard and touch users. Interest Invokers aim to standardize those patterns so that hover, focus, and long‑press behaviors are both predictable and accessible by default.

Practically, you author one attribute on the invoker and a popover attribute on the target. The browser detects interest transitions and dispatches InterestEvent events, interest and loseinterest, on the target, with built‑in show/hide behavior when the target is a popover. This shifts a common class of “tiny JS” into reliable platform behavior.

Naming, status, and standardization in late 2025

Early experiments and documentation used the attribute name interesttarget. In 2025, the HTML specification work and later Chromium intents converged on interestfor as the finalized name. If you see both names referenced, interestfor is the one tracking through the standards process.

Chrome ran origin trials in versions 135 and 137 across desktop, Android, and WebView, extending the trial as the feature evolved. In September 2025 the Chromium team posted an Intent to Ship for interestfor, signaling readiness to graduate from experiment toward stable availability.

On the spec side, a WHATWG HTML pull request tracks the addition of the interestfor attribute, while Open UI maintains the public explainer. There are ecosystem signals beyond Chromium: Mozilla synced Web Platform Tests related to interesttarget’s UI treatment (such as outlines), indicating cross‑vendor test coverage, and WebKit filed a tracking bug for an “Implementation bug for the interestfor attribute” in Nightly. Those are not shipping signals for Firefox or Safari yet, but they demonstrate active multi‑vendor discussion.

Popover API: the building block Interest Invokers control

The Popover API reached Baseline “Newly available” on January 27, 2025, and is supported across Chrome 116+, Safari 17+, and Firefox 125+. This means the foundational behavior, top‑layer rendering, light‑dismiss, Escape‑to‑close, focus management, and the :popover-open state, is broadly interoperable.

Firefox 125 shipped the Popover API including attributes like popovertarget, the popoverTargetElement IDL, focus handling, :popover-open styling hooks, and ::backdrop for popovers. Interop 2025 highlighted Popover as one of the features that’s now interoperable, allowing teams to replace ad‑hoc tooltip and menu code with standards‑based markup.

When you relate an invoker and a popover, browsers implicitly set ARIA (e.g., aria-expanded and aria-details when appropriate), adjust keyboard focus order, and create an implicit anchor relationship usable by CSS Anchor Positioning. That anchor enables precise placement relative to the invoker using properties like position-anchor and position-area.

How declarative wiring works with Interest Invokers

The basic pattern is: add popover to the target element, and reference it from the invoker using interestfor. The user agent detects hover, focus, and long‑press on the invoker and fires InterestEvent events, interest and loseinterest, on the target. For popover targets, these events have default actions to open and close the popover.

For example, a button or link can declare interestfor=”card” while the target element uses popover. The result is a hovercard that opens on hover or focus, closes on mouseout or blur, and long‑presses on touch. This requires no click handler or custom timers, avoids “hover only” traps, and works with the keyboard by design.

If you’ve used the Popover API’s popovertarget and popovertargetaction attributes, think of interestfor as complementary: popovertarget wires click/tap actions (show/hide/toggle), while interestfor layers in non‑click “interest” behaviors. Together they allow you to support both intentional activation and passive preview patterns.

Code patterns you can ship today

Start with Popover API markup using popovertarget for click/tap activation. This is fully supported in modern engines and gives you accessible menus, tooltips, and hovercards that you can open or close programmatically as needed. Use :popover-open for styling, and consider ::backdrop for blocking interaction when appropriate.

To add hover/focus/long‑press behavior, layer in interestfor when available. During the Chrome origin trials, teams enrolled by registering and serving an origin‑trial token via meta or HTTP er. If you still want to experiment behind feature flags or in internal apps, a community polyfill for interestfor exists on npm, allowing you to simulate the attribute and events for prototypes.

For hovercards, explore popover=”hint” in Chromium‑based browsers (Chrome/Edge 133+). Hint popovers are designed for transient UI; opening a hint popover does not close existing auto popovers, avoiding disruptive UI collapses. Note that hint mode has limited availability today (not yet in Firefox or Safari) and low measured usage, so gate it and provide a fallback to regular popover where needed.

Accessibility and ergonomics benefits

Declarative popovers come with a bundle of accessibility improvements: top‑layer rendering ensures they appear above other content; Escape closes them; focus returns to the invoker when they dismiss; and browsers set appropriate ARIA relationships and manage keyboard order when you relate a popover to its control. These defaults address many common a11y pitfalls found in custom tooltip and menu code.

Interest Invokers further reduce gaps by treating focus and long‑press as first‑class “interest” signals alongside hover, so keyboard and touch users get equivalent behavior. By removing bespoke mouseenter/mouseleave logic and timer juggling, you also avoid race conditions and flicker that degrade usability.

Finally, implicit anchor creation between invoker and popover unlocks clean positioning with CSS Anchor Positioning. Rather than hard‑coded pixel math, you can describe desired placement declaratively, improving maintainability and LTR/RTL adaptability.

Migration notes: interesttarget to interestfor, and interop realities

If you prototyped with interesttarget in early Chrome trials or docs, plan to rename to interestfor. The HTML PR series and Chromium’s later intents use interestfor, and the Open UI discussions aligned on it in 2025. Code using the old attribute may need an attribute alias or migration path if you used a polyfill.

Expect staggered availability. Chromium led the experiments and intent to ship; Mozilla has test syncing activity but no shipping signal; WebKit is discussing implementation issues in Nightly. For production, keep a resilient baseline using Popover API features and progressive enhancement for Interest Invokers.

Also review recent Popover quality‑of‑life changes: Chromium fixed an issue where a popover nested inside its invoker could re‑invoke itself when clicked, improving nested UI reliability. Such polish matters when you have menus, sub‑menus, and hovercards interacting.

Working with events, commands, and future‑proofing

Interest Invokers dispatch InterestEvent events, interest when a user shows interest, loseinterest when it lapses. Even when you rely on default show/hide for popovers, you can listen for these events to perform secondary updates like analytics, lazy loading content, or prefetching resources for smoother UX.

Consider the Invoker Commands API as a complementary tool. It generalizes declarative control via commandfor/command, letting you wire invokers to openable elements like popovers and dialogs without ad‑hoc JS. Using Commands alongside Interest Invokers provides a consistent mental model for both intentional activation and passive interest behaviors.

From the standards side, Open UI minutes in early 2025 resolved to scope default actions to popovers, always fire interest/loseinterest events, and drop a separate interestaction attribute. There’s discussion of future “openable” support beyond popovers, hinting at a coherent, extensible model.

Putting it together: hovercards, menus, and tooltips

A pragmatic rollout strategy looks like this: ship Popover‑based menus and tooltips with popovertarget today, benefiting from baseline support and accessibility defaults. Use anchor positioning for placement and :popover-open for transitions and visibility control.

Then, progressively enhance hovercards by adding interestfor to invokers. In Chromium, pair it with popover=”hint” so hovercards don’t collapse other UI. In non‑Chromium engines without hint mode, fall back to regular popovers; the experience remains functional and accessible.

Guard enhancements with feature detection. You can check for the presence of HTMLInterestEvents or attribute support; when absent, rely on your click/tap activations. If you experimented via Chrome’s origin trial, remove tokens as the feature ships and keep an eye on release notes for any attribute or event refinements.

Declarative popovers with Interest Invokers give the platform‑level ergonomics developers have long relied on libraries to provide. With the Popover API now baseline and interestfor moving toward shipping, the path is clear for robust, accessible hover‑driven UI that works across input modalities.

Adopt the Popover API first to get immediate value and interop. Then layer in Interest Invokers and, where available, the hint popover mode for top‑tier hovercard experiences. Keep your implementation progressive and standards‑aligned, and you’ll be well positioned as browser support broadens.