The Popover API (previously Popup)

[mfreed7]

Wotcher TAG!

I'm requesting a TAG review of the Popup API. This is a third attempt at a TAG review for this feature; see #599 for the first, and #680 for the second.

A very common UI pattern on the Web, for which there is no native API, is "popup UI" or "popups". Popups are a general class of UI that have three common behaviors:

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

We are proposing a set of APIs to make this type of UI easy to build.

• Explainer: https://open-ui.org/components/popup.research.explainer
• WHATWG HTML Spec PR: Add popover attribute whatwg/html#8221
• User research: https://open-ui.org/components/popup.research
• Security and Privacy self-review²: See inline below.
• GitHub repo (if you prefer feedback filed there): https://github.com/openui/open-ui/issues (please use the Popup label)
• Primary contacts (and their relationship to the specification):
  • Mason Freed (@mfreed7), Google
• Organization/project driving the design: Google and Microsoft
• External status/issue trackers for this feature: https://chromestatus.com/feature/5463833265045504

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): https://open-ui.org/
• The group where standardization of this work is intended to be done ("unknown" if not known): WHATWG mostly
• Existing major pieces of multi-stakeholder review or discussion of this design: https://github.com/openui/open-ui/issues?q=is%3Aissue+label%3Apopup
• Major unresolved issues with or opposition to this design: No major unresolved issues or opposition that I'm aware of. There are several details still under active discussion.
• This work is being funded by: Google and Microsoft

You should also know that...

This is a third attempt at a TAG review for this feature. The first attempt was closed due to the lack of an Anchor Positioning proposal. That has now been proposed, and there's a draft spec. The second attempt was closed because we changed directions from a <popup> element to a popup content attribute. This third TAG review is for that new content-attribute-based approach.

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue and @-notify @mfreed7

---

Security and Privacy questionnaire for TAG

2.1. What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?
None. This feature does not expose any extra information to sites.

2.2. Do features in your specification expose the minimum amount of information necessary to enable their intended uses?
Yes - no new information.

2.3. How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?
N/A - no PII.

2.4. How do the features in your specification deal with sensitive information?
N/A - no sensitive information.

2.5. Do the features in your specification introduce new state for an origin that persists across browsing sessions?
No.

2.6. Do the features in your specification expose information about the underlying platform to origins?
No.

2.7. Does this specification allow an origin to send data to the underlying platform?
No.

2.8. Do features in this specification enable access to device sensors?
No.

2.9. Do features in this specification enable new script execution/loading mechanisms?
No.

2.10. Do features in this specification allow an origin to access other devices?
No.

2.11. Do features in this specification allow an origin some measure of control over a user agent’s native UI?
No. While pop-ups are shown in the top-layer, they cannot escape the frame bounds, and cannot be shown over the top of a UA's native UI.

2.12. What temporary identifiers do the features in this specification create or expose to the web?
None.

2.13. How does this specification distinguish between behavior in first-party and third-party contexts?
It does not distinguish. Pop-ups are isolated to their frame, for both 1st and 3rd party frames.

2.14. How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?
Just fine. No exposure of private browsing state.

2.15. Does this specification have both "Security Considerations" and "Privacy Considerations" sections?
There are no known security impacts of the features in this specification.

2.16. Do features in your specification enable origins to downgrade default security protections?
No.

2.17. How does your feature handle non-"fully active" documents?
N/A

2.18. What should this questionnaire have asked?
N/A

[torgo]

Hi @mfreed7 sorry we should have caught this earlier but can you provide answers to the security & privacy questionnaire? Thanks!

[mfreed7]

Hi @mfreed7 sorry we should have caught this earlier but can you provide answers to the security & privacy questionnaire? Thanks!

Sorry about that - I just edited the OP to include the questionnaire. While I was there, I also linked to the in-progress spec PR.

[torgo]

Hi @mfreed7 thanks for that! Do you have any additional info on feedback/support from additional stakeholders (implementers)? Some additional TAG feedback incoming from our session today.

[LeaVerou]

Hello there,
We reviewed this today in a breakout, and we are quite concerned with the amount of attributes and methods this is adding on every single element. We believe this would add a lot of additional complexity (e.g. what happens when <body> is a popup? Or when table elements are popups? Or when form elements are popups? Or replaced elements?) that is not actually required for addressing the use cases that popup is meant to address. Furthermore, this makes the API itself clunkier and more verbose, as now names need to be distinct from any other global name, not just names on the same element. It is also inconsistent with the rest of HTML, which typically defines new elements for things like that (e.g. we didn't add a dialog attribute to HTMLElement, we added a <dialog> element). We understand that this design enables some possibilities that having a separate element does not, but on balance, we don’t think the tradeoff is worth it.
We would prefer to see the popup functionality as one or more separate element(s). Any attributes specified on the popup trigger (popuptoggletarget) could be global attributes.

[mfreed7]

Thanks for the review!

So in OpenUI we discussed this alternative (a <popup> element) at length, over roughly a year and with 10+ meetings dedicated to this specific topic. What would your solution be to the accessibility and semantic issues with that approach? (Our eventual conclusion was that there wasn’t a good solution, and the attribute approach was therefore superior. It also happens to be more powerful.) Also recall that the TAG closed my design review for <popup> based on these concerns, which is when we went in the global attribute direction.

I think we’d agree that this adds several new attributes, but only one (popup) truly confers new behavior on any element. The other two (anchor and defaultopen) simply modify that behavior. There are certainly precedents for global attributes that modify the behavior of any element, e.g. contenteditable or tabindex or even the aria-* attributes, right? Can you help me understand why this is different?

As for limiting the list of elements, we could definitely do that. However, should we restrict that list just because we don’t have a specific use case in mind right now for <input popup> or even <table popup> or <body popup>? Web developers are amazingly creative people. Of course, if there is some sort of incompatibility or reason not to support the attribute on an element, a restriction would be in order. We had such a discussion about <dialog> on openui/open-ui#520, and decided that even there it makes sense to allow the popup attribute. How would you go about deciding which elements deserve popup support and which don’t?

Thanks again for your review! Besides the attribute vs element issue, were there any other comments on the behaviors it confers?

Hi @mfreed7 thanks for that! Do you have any additional info on feedback/support from additional stakeholders (implementers)? Some additional TAG feedback incoming from our session today.

The Gecko folks have been involved in our OpenUI discussions of the feature, and have offered some great feedback which we’ve incorporated. I wouldn’t say we have official support just yet from other implementers though.

[mfreed7]

Just to add a bit more detail to the answer above, I've updated the explainer with a summary section detailing "why an attribute instead of an element":

https://open-ui.org/components/popup.research.explainer#why-a-content-attribute

Here is the summary paragraph of that section:

By having popup be a content attribute that purely confers behavior upon an existing element, the above problems are nicely resolved. Semantics are provided by elements, and behaviors are confered on those elements via attributes. This situation is exactly analogous to contenteditable or tabindex, which confer specific behaviors on any element. Imagine a Web in which those two attributes were instead elements: <contenteditable> and <tabindex index=0>. In that Web, many common patterns would either be very convoluted or simply not possible.

Hopefully this helps.

[plinss]

I still have concerns about an active popover being automatically placed in the top layer, I feel this is something that should be controlled by CSS and can happen by default via the UA stylesheet.

@chrishtr I also have strong concerns that while top layer may be well defined, I don't believe that it's being defined in the right place. The full screen spec is monkey-patching CSS. The top layer design should be brought to the CSSWG and discussed there. The resulting design should be folded into a CSS spec and referenced from full screen.

[nt1m]

I feel this is something that should be controlled by CSS

I'm not involved in the popover API, but again I strongly oppose this idea for the reasons stated in #743 (comment)

In a CSS-controlled top layer, what controls the z-order within the top layer of the elements? It's going to be completely arbitrary. It will pretty much behave the same as z-index: MAX_VALUE and have the same problems.

For consistency with other things in the top layer at the moment, perhaps a better way is a JS call that doesn't push to the top layer.

[annevk]

@plinss that's been brought up repeatedly, but nobody picked it up thus far:

• [css-position-4] Define "top layer" positioning scheme w3c/csswg-drafts#4998
• [fullscreen] Details on how top layer elements interact with their ancestors w3c/csswg-drafts#6939
• [css-pseudo] Define ::backdrop w3c/csswg-drafts#7845
• [selectors] :visited and ::backdrop w3c/csswg-drafts#8240

I've been asking for the CSS WG to take that over since I started working on Fullscreen a decade ago or so. Not exactly my area of expertise.

[mfreed7]

I feel this is something that should be controlled by CSS

I'm not involved in the popover API, but again I strongly oppose this idea for the reasons stated in #743 (comment)

In a CSS-controlled top layer, what controls the z-order within the top layer of the elements? It's going to be completely arbitrary. It will pretty much behave the same as z-index: MAX_VALUE and have the same problems.

+1. The top layer is an ordered set, so it depends on the order that things are placed there. I'm not sure you'll be able to re-define top-layer as a feature determined by CSS, because it won't play nicely with existing things like dialog and fullscreen. (See this issue for ways to animate top layer status via CSS.)

[mfreed7]

Quick followup on this TAG review: the spec has landed in WHATWG with multiple implementer support. https://html.spec.whatwg.org/multipage/popover.html

I'm going to close this design review. Thanks for all of the comments!

[torgo]

Hi - there seems to be a bit of confusion here. just because it's in WHATWG it doesn't mean the review should be closed. In general TAG should be closing issues with our own process. We're going to go ahead and re-open and leave some additional feedback. We remain concerned about the toplayer spec itself which this is based on. We recognize that this isn't an issue with this spec itself. We would like to suggest that you help us work through these issues in the CSS working group (see the links from Anne above).

[mfreed7]

Oops, sorry about that! Github gave me a shiny "close this issue" button, so I pressed it. I won't do that in the future. And yes, I'll participate in the top layer discussions as needed.

[atanassov]

Thank you @mfreed7. Ideally we can talk about it this Wednesday during the csswg vf2f.