The Popover API Is Officially Baseline
The Popover API is an HTML feature that allows developers to create overlay elements like menus, toasts, and pickers without writing custom JavaScript, avoiding the tricky accessibility pitfalls that come with hand-rolled implementations. In April 2024, we incorrectly declared this API as Baseline Newly available. The API officially reached Baseline status on January 27, 2025. Here’s what went wrong and what’s being done to prevent future premature declarations.
A basic popover can be created with simple declarative markup using the popover attribute and the <popovertarget> button attribute:
Why the original Baseline declaration was wrong
Our April 2024 announcement was based on the fact that Firefox had shipped its implementation of the Popover API. However, a major problem existed that we hadn’t yet caught: on iOS and iPadOS Safari, the light dismiss behavior wasn’t working. Users of these mobile browsers could not close a popover by clicking or tapping outside of it — a core interaction that most developers would consider essential. The bug was ultimately tracked in an existing WebKit issue and wasn’t fixed until the release of Safari 18.3, which is why the API couldn’t truly be considered Baseline until late January 2025.
Because of this light-dismiss failure, the API failed to meet the Baseline requirement of being both broadly available and reliable enough to use without performance or user-experience penalties. It needed to be held back until the bug was resolved.
How the wrong call was made
Baseline calculations are built on the web-features project, which stitches together the available implementation data for individual browser features. For a web feature like popover, several underlying technologies from the Mozilla Browser Compat Data need to work together. The web-features effort uses a blend of automated availability data and human judgment to decide whether a feature should be considered a single coherent whole — and critically, whether partial implementations in key environments should exclude it from Baseline.
Early in the project’s lifecycle, that critical human judgment lacked sufficient context, partly because the feature definition data was still far from comprehensive and browser compatibility data hadn’t flagged the issue until September. This allowed an outdated pass-at-any-rate state of the data to make an API look broadly compatible when, in fact, a significant portion of its user base on one major mobile platform was blocked by a severe bug.
A contributing factor is our limited mobile testing infrastructure. If this issue had surfaced on a desktop browser, the Web Platform Tests suite would have shown immediate failures across supported operations. But because mobile browser behavior and interactions aren’t anywhere near as well-covered, this iOS-specific bug was able to slip through entirely unnoticed.
What’s changing for future Baseline decisions
Since making this mistake, the web-features database has been brought near to completion. This new level of data coverage significantly increases our confidence in future feature declarations.
For this specific case, a larger part of the problem was detecting an issue isolated to mobile Safari. Actions are underway to improve that blind spot:
- Ongoing work to boost mobile browser support in the Web Platform Tests infrastructure, allowing issues in mobile browsers to pop up independently of their desktop counterparts.
- Plans to surface this more granular compatibility data within the webstatus.dev dashboard later this year, with the aim of catching such anomalies more quickly — before they become an unexpected impediment to a new feature’s baseline candidacy.
Mapping the entire web platform is never going to be a straightforward exercise, but the ongoing process is surfacing exactly the kind of discrepancies that define the complicated meeting point between specs, bug fixes, and actual user behavior. Given the rich conversations arising from issues like this, these signals are expected to help better drive future Interop planning and overall platform effort prioritization.
