The Popover API is now Baseline Newly available  |  Blog  |  web.dev

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>

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.