New feature proposal: <popup> element

[melanierichards]

Hi all, wanted to share with the WHATWG community an early proposal for a new element, which you can find on the Microsoft Edge explainers repo. We’ve heard from developers that is challenging to support top-layer, transient UI in their web applications (examples include action menus, teaching bubbles, and content picker boxes) because they have to manage styling, positioning, user interaction behaviors, keyboard management, and other elements of accessibility themselves. To take just one example of this developer/user pain, popup UI often gets pushed to the end of the document as a child of the root node. This is in service to top-layer positioning (avoiding clipping from ancestral elements) but causes accessibility issues as the popup is separated from its context.

The <popup> proposal aims to provide a base class element that will make transient, top-layer UI much easier to author. We aim to enable many different types of popups to be built with this element, including the listbox portion of a future customizable <select> (refer to @gregwhitworth's blog post series for research that motivated this customizable controls effort). That said, some top-layer UI may be a better fit for <dialog> or other future purpose-built elements. For example, custom tooltips, which have very specific user interaction and content model requirements, may benefit from a different proposal.

Our thinking is that popups are top-layer elements which:

• Are inherently transient: only one popup can be shown at a time, with an exception for nested popups
• Share “light dismiss” behaviors, which are handled by the user agent: dismiss on ESC key, loss of focus, layout changes
• Are non-modal
• Can support arbitrary contents
• Can be fully style, sized, and positioned to the author’s discretion; top-layer positioning is managed by the user agent.

To get a full sense of goals, non-goals, and detailed proposed solution, please review the explainer.

Request for feedback

As mentioned, this proposal is in its earliest stages and there’s a lot of great discussion happening in Github issues. We have found there is motivation from browser vendors (Microsoft Edge, Chrome) and from web developers (Salesforce and others in the community) to solve this problem. We’d like to further invite the community (browser vendors, developers, and other standards participants) to provide feedback on the explainer. We’d love to know your level of interest in implementing against this proposal and whether it adequately meets your needs for the stated purposes.

If there is sufficient community interest, we imagine this proposal will be incubated in a community group before more formal issues/PRs are submitted to WHATWG. I've opened an issue to track process discussion: #6350.

[domenic]

Thanks Melanie! I'll try to give some "HTML editor hat" feedback over on the GitHub issues. I look forward to the proposal having its own repository so we can have more focused discussion!

[melanierichards]

Thanks @domenic, much appreciated!

[mfreed7]

Quick comment that there is an incubation draft spec for <popup> at openui/open-ui#355. This is still a PR that is under review. But I wanted to link it here, in case there is high-level (or low level!) early feedback from the HTML editors on how it's being tackled. The goal is to make it easy to eventually transition it from OpenUI to an HTML spec PR, once OpenUI has had a chance to review and approve it.

[erictheise]

Perhaps a naive question but what's the thinking on how this <popup> would interact with or be available to the maps, graphs & charts, 3d models, and virtual worlds that are typically implemented via JavaScript libraries?

[past]

Removing the agenda+ label since there don't seem to be any new updates since the last time we discussed this issue. Please add it back if I got it wrong.

[mfreed7]

Given the new popup issue (#7785), I think we should close this <popup>-element-specific issue.