New feature proposal: <popup> element #6349
Description
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.