The Popover API

[mfreed7]

Request for position on an emerging web specification

• WebKittens who can provide input: @annevk, @heycam, @jensimmons

Information about the spec

• Spec Title: The Popover API
• Spec URL: Add popover attribute whatwg/html#8221
• GitHub repository:
• Issue Tracker (if not the repository's issue tracker):
• Explainer (if not README.md in the repository): https://open-ui.org/components/popover.research.explainer/
• Incubation: OpenUI. See issues discussed/resolved.

Design reviews and vendor positions

• TAG Design Review: The Popover API (previously Popup) w3ctag/design-reviews#743
• Mozilla standards-positions issue: The Popover API mozilla/standards-positions#698

Bugs tracking this feature

• WebKit Bugzilla:
• Radar:

Brief summary of the issue or the subject of the spec.

A very common UI pattern on the Web, for which there is no native API, is "pop up UI" or "pop-ups". Pop-ups are a general class of UI that have three common behaviors:

1. Pop-ups always appear on top of other page content.
2. Pop-ups are ephemeral. When the user "moves on" to another part of the page (e.g. by clicking elsewhere, or hitting ESC), the pop-up hides.
3. Pop-ups (of a particular type) are generally "one at a time" - opening one pop-up closes others.

The Pop-Up API aims to make this type of UI easy to build.

[annevk]

As raised in whatwg/html#7785 (comment) I don't think pop-up (with a hyphen) works.

[mfreed7]

As raised in whatwg/html#7785 (comment) I don't think pop-up (with a hyphen) works.

Thanks for the reply! Let's continue the naming discussion on the PR, and find a good solution.

Would it then be fair to say that once we resolve the naming question, you're supportive of this feature?

[annevk]

No, it's still under discussion.

[mfreed7]

No, it's still under discussion.

Ok, makes sense, thanks! But in that case, I think we should wait to work on the naming question until you've had a chance to more thoroughly review and discuss the feature. Otherwise, we could spend significant time/effort trying to rename the attribute only to find there are other blockers. Or even find that we need to rename it back, based on later findings.

So please feel free to reach out with other questions!

[annevk]

Colleagues and I had another look and we're quite happy with the recent changes:

• Consistent naming of attributes (and renaming to popover).
• No more meddling with the event dispatch algorithm.
• Reduction of scope around anchor and defaultopen (i.e., tackle those separately).

Also thanks to @domenic for helping flush some of that out.

The main thing we're not quite sure about (but unfortunately also don't have a suggestion for at the moment) is the tight integration with Web Animations for hiding. Is that motivated somewhere and why it doesn't similarly apply to other elements with state transitions?

Other than that we're largely positive on this feature now.

[mfreed7]

Colleagues and I had another look and we're quite happy with the recent changes:

• Consistent naming of attributes (and renaming to popover).
• No more meddling with the event dispatch algorithm.
• Reduction of scope around anchor and defaultopen (i.e., tackle those separately).

Also thanks to @domenic for helping flush some of that out.

Awesome, thanks for the feedback! I'm glad you're happy with the changes and the general shape of the API. The feedback we've received via the HTML spec PR have been very helpful in general, and has led to most of these changes.

The main thing we're not quite sure about (but unfortunately also don't have a suggestion for at the moment) is the tight integration with Web Animations for hiding. Is that motivated somewhere and why it doesn't similarly apply to other elements with state transitions?

So the animation behavior (discussed at length here) is definitely a cool feature that developers want, and it's something missing from e.g. <dialog>. It is very common on the web for these types of popovers to get animated in and out, because it helps the user understand that something is coming and going, and is less abrupt than simply disappearing. So I'm very supportive of expanding this capability to other situations where possible. One example is <dialog>: that case was mentioned several times on the OpenUI thread. I think it's possible that the approach taken with the popover API could be ported/adopted to <dialog>, but we need to look.

I'm not sure if your question was about the need to animate, or just the particulars of how it works with Web Animations. In case it's the latter, the technical need is to wait (somehow) for animations to complete before hiding the popover and removing it from the top layer. And it's important to also be able to capture existing animations on the element, to avoid waiting for things that weren't triggered by the show/hide action. The most natural way to do both of these seemed to be via the Web Animations API. If there's a better way to do that, I'd love to hear suggestions!

Other than that we're largely positive on this feature now.

Thanks! 🎉

[mfreed7]

The main thing we're not quite sure about (but unfortunately also don't have a suggestion for at the moment) is the tight integration with Web Animations for hiding. Is that motivated somewhere and why it doesn't similarly apply to other elements with state transitions?

@annevk per my comment just now, we've ripped out the animations stuff from the Popover spec PR. We very much want to support animations for popovers, but we think we can do it a) independently, and b) in a more general way to support things other than popover.

Your comment seemed to indicate that this animations stuff was your last remaining hesitation about this feature. With it gone, would you be willing to officially mark this standards-position as Supportive?

[annevk]

Yeah, although there's still a number of issues with the PR they are relatively minor so I would suggest we label this as "position: support" on December 21.

[hober]

Closing as we've identified our position.