The Popover API is now Baseline Newly available

Published: February 7, 2025

In April 2024, a post on this site announced that the Popover API was Baseline Newly available. However, we got it wrong, and popover enters Baseline as of January 27, 2025. This post explains why we got it wrong, and what has changed since to make these mistakes less likely to happen.

What's the Popover API?

The Popover API provides a built-in way to create various types of popover used in web applications. Previously, these required you to use JavaScript, and take great care to implement them in an accessible manner. The API brings all of this to the browser, and a simple popover can be created declaratively in HTML.

<button popovertarget="my-popover">Open Popover</button>

<div id="my-popover" popover>
  <p>I am a popover with more information. Hit <kbd>esc</kbd> or click away to close me.</p>
</div>
A basic example of using the popover attribute.

Why wasn't it Baseline in April 2024?

When Firefox shipped their implementation of popover in April 2024, we hadn't yet discovered that there was a significant issue on iOS and iPadOS. On these mobile browsers, clicking outside of the popover didn't close it, a feature known as light dismiss. This is a problem that would prevent most developers from being happy to use popover. This meant that it shouldn't have been included as Baseline back in April, and needed to wait until the bug was fixed in Safari 18.3.

Why did we get it wrong?

Baseline relies on the web-features work to calculate when features are in or out of Baseline. If you take a look at an individual feature file in that project, such as the file for popover, you'll see the individual features from the Mozilla Browser Compat Data listed. One web-feature typically contains a number of these inclusions. This is because a feature on the web isn't just a single property or method, it needs a number of component parts to work. Nor is a feature an entire specification. CSS specifications, for example, often include sub-features that have never been implemented, or are only used in a specific context. The web-features work uses a combination of existing availability data and human input to work out what constitutes a web platform feature, and crucially, whether a partial implementation is serious enough to keep it out of Baseline.

Back in February, the web-features work was a long way from complete. Therefore, to help show how Baseline would work, we were trying to figure out key features that would be part of Baseline 2024 without all the data we needed to do so. On paper, or rather in the browser compat data which wasn't updated until September when the issue was spotted, popover appeared to be included. However, due to the bug on iOS being severe enough to prevent popover being used, it wasn't ready.

There was also a lack of test infrastructure for mobile. The Web Platform Tests project gives us a way to test that web platform features are working across all browsers. Had this light-dismiss issue happened in a desktop browser, we'd have seen that tests were failing, this wasn't the case for mobile.

How do we avoid this in the future?

We're already in a much better place with the data. The web-features data is almost complete, and so we can have a greater degree of confidence with any of the features that we're declaring Baseline.

In particular with this issue, part of the problem was identifying an issue only happening on mobile, in iOS. There's a few things happening that should make identifying interoperability issues on mobile easier in future. Work is ongoing to improve mobile testing in Web Platform Tests, so we should be able to better identify when a mobile browser has issues, separately from desktop. We're also intending to expose this data on the webstatus.dev dashboard this year. If a problem like this happens in the future, we should get more rapid indications that it has happened, hopefully before we include the feature in Baseline.

We always knew that mapping the entire web platform as a set of features wouldn't be easy! However the discussions we're having about partial implementations, bugs, and what actually makes up a feature are incredibly valuable. It's helping us to identify what really matters to you, giving us better signals to use when planning efforts such as Interop 2025.