HTMLPopupElement

[mfreed7]

Braw mornin' TAG! (That's a new one for me 😄 )

I'm requesting a TAG review of the <popup> element. This is effectively a re-opening of the previously requested TAG review for this feature.

That review was closed, waiting for the proposed "Anchor Positioning" feature to be available for review. Please see this comment on the old review, linking to the explainer for Anchor Positioning, plus some additional context. Essentially, the Anchor Positioning feature now has an explainer and a significant amount of brainstorming is happening around the shape of the API. From those links you should be able to get a sense for what will be possible, positioning-wise, for <popup>. And hopefully that's enough to re-open and continue the TAG review for <popup>. In the time since the last TAG review, a draft specification has been written and reviewed by editors of the WHATWG HTML spec. And a prototype implementation in Chromium is basically complete. Several of the comments on the prior TAG review lead to changes that have been made in the spec and implementation, e.g. the addition of an initiallyopen attribute to declaratively open the popup.

• Explainer¹: https://open-ui.org/components/popup.research.explainer
• Specification URL: https://open-ui.org/components/popup
• Tests: https://wpt.fyi/results/html/semantics/interactive-elements/the-popup-element
• User research: https://open-ui.org/components/popup.research
• Security and Privacy self-review²:
• GitHub repo (if you prefer feedback filed there):
• Primary contacts (and their relationship to the specification):
  • Mason Freed (@mfreed7), Google (current feature champion)
  • Melanie Richards (@melanierichards), Netlify, previously Microsoft (previous champion, wrote spec draft)
• Organization(s)/project(s) driving the specification: OpenUI, Google, Microsoft
• Key pieces of existing multi-stakeholder review or discussion of this specification: Prior TAG review
• External status/issue trackers for this specification: https://github.com/openui/open-ui/issues?q=is%3Aissue+is%3Aopen+label%3Apopup

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: None
• The group where the work on this specification is currently being done: OpenUI
• The group where standardization of this work is intended to be done: WHATWG HTML/DOM
• Major unresolved issues with or opposition to this specification: None that I know of
• This work is being funded by: Google & Microsoft

You should also know that...

I appreciate the TAG. 👍

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

[domenic]

Major unresolved issues with or opposition to this specification: None that I know of

The lack of clarity about what this element is, semantically, remains. That is, is this for tooltips, menus, toasts? All of them? I've raised this a number of times but the only open issue I can find in https://github.com/openui/open-ui/labels/popup on it is maybe openui/open-ui#329 .

The fact that the draft specification uses role="menu" in an example is an illustration of this big issue. We can't introduce new elements which require ARIA to function; the first rule of ARIA is that ARIA should not be necessary for features available natively in HTML.

Apart from that major issue, I worry that there are 31 open issues in https://github.com/openui/open-ui/labels/popup ... some triage would help give a more accurate picture of how mature the proposal and spec is, I think.

[mfreed7]

@domenic thanks for the comments.

Major unresolved issues with or opposition to this specification: None that I know of

The lack of clarity about what this element is, semantically, remains. That is, is this for tooltips, menus, toasts? All of them? I've raised this a number of times but the only open issue I can find in https://github.com/openui/open-ui/labels/popup on it is maybe openui/open-ui#329 .

So the explainer talks about this in the first few paragraphs, but let me try to consisely answer your question:

A <popup> is something that has these qualities:

1. It is painted on top of everything else (top layer).
2. It is ephemeral, and gets "light-dismissed" via several actions such as clicking outside the <popup>, scrolling the page, hitting ESC, etc.
3. Only one <popup>* can be visible at a time. (* nested popups are the exception to the one-at-a-time rule.)

So that does not include several of the UI elements you listed. See this section of the explainer, which explicitly lists several such controls such as toasts.

The fact that the draft specification uses role="menu" in an example is an illustration of this big issue. We can't introduce new elements which require ARIA to function; the first rule of ARIA is that ARIA should not be necessary for features available natively in HTML.

I'm open to suggestions here. Perhaps a <popup> should use role=dialog. Both <popup>s and <dialog>s are general-purpose top-layer elements, and are perhaps close enough to each other to share a role? In general, the <dialog> element is already in a somewhat similar boat, no? I.e. a <dialog> can be used for a number of UI purposes, such as dialogs, tooltips, toasts, etc. But the platform uses role=dialog and it's up to the developer to specialize further with ARIA attributes if it is being used for a more-specific purpose such as a tooltip.

Apart from that major issue, I worry that there are 31 open issues in https://github.com/openui/open-ui/labels/popup ... some triage would help give a more accurate picture of how mature the proposal and spec is, I think.

Totally valid point. I've been meaning to go through those and address them. Thanks for the ping.

[domenic]

A <popup> is something that has these qualities:

That doesn't really help. Those are behaviors, not semantics or types of controls. (I.e. the things that feed into roles.)

Below you propose that the role should be dialog. That implies that instead of being a new element, this should be some sort of mode of the dialog element, since the dialog element already occupies the semantic space of dialogs. (E.g., <dialog type="light-dismiss"> or dialogEl.showWithLightDismiss().)

In general, the <dialog> element is already in a somewhat similar boat, no? I.e. a <dialog> can be used for a number of UI purposes, such as dialogs, tooltips, toasts, etc. But the platform uses role=dialog and it's up to the developer to specialize further with ARIA attributes if it is being used for a more-specific purpose such as a tooltip.

No, this isn't correct. The dialog element can only be used for dialogs. Tooltips or toasts should be done using <div>s or similar. (Or perhaps a new element, if someone were bold enough to propose one... I seem to recall something of that sort for toasts.) If you use <dialog> but then override its exposure to accessibility tech using role=something else, the element is being misused.

We need to figure out what the similar semantic space, and corresponding role, is for popup. The explainer example seems to give several types of controls: menus, form element suggestions, content pickers, and teaching UI. What is the ARIA role for each of these? Perhaps each should have a separate element, not <popup>, which implements the appropriate semantics (and behaviors?? I can't imagine a teaching UI needs the exact same behaviors as a menu). Or perhaps some of those are better suited for <dialog> instead of <popup>.

I apologize that this is rather fundamental criticism, but I do feel like I've raised it repeatedly since the beginning of this endeavor, without much response. I appreciate getting some concrete engagement at this point.

[mfreed7]

A <popup> is something that has these qualities:

That doesn't really help. Those are behaviors, not semantics or types of controls. (I.e. the things that feed into roles.)

Below you propose that the role should be dialog. That implies that instead of being a new element, this should be some sort of mode of the dialog element, since the dialog element already occupies the semantic space of dialogs. (E.g., <dialog type="light-dismiss"> or dialogEl.showWithLightDismiss().)

In general, the <dialog> element is already in a somewhat similar boat, no? I.e. a <dialog> can be used for a number of UI purposes, such as dialogs, tooltips, toasts, etc. But the platform uses role=dialog and it's up to the developer to specialize further with ARIA attributes if it is being used for a more-specific purpose such as a tooltip.

No, this isn't correct. The dialog element can only be used for dialogs. Tooltips or toasts should be done using <div>s or similar. (Or perhaps a new element, if someone were bold enough to propose one... I seem to recall something of that sort for toasts.) If you use <dialog> but then override its exposure to accessibility tech using role=something else, the element is being misused.

So we both understand that <dialog> can be, and is, used for things other than dialogs. It is the (currently only) platform feature that gives developers access to the top layer. Using a <div> requires gymnastics like re-parenting the <div> to the last child of <body>, and giving it z-index:9999999999. It is also sub-par from an accessibility POV for many reasons, including the aforementioned re-parenting, plus the fact that <div>/<span> soup doesn't get announced at all by AT, right? At least if you build a toast using <dialog>, it'll be announced as a dialog, which isn't terribly far from a toast. Or at least it's closer than a <div>.

Having said that, I'm not disagreeing with the idea that we should make this semantically as clear and accessible as possible. I'm open to concrete proposals about how to do that.

We need to figure out what the similar semantic space, and corresponding role, is for popup. The explainer example seems to give several types of controls: menus, form element suggestions, content pickers, and teaching UI. What is the ARIA role for each of these? Perhaps each should have a separate element, not <popup>, which implements the appropriate semantics (and behaviors?? I can't imagine a teaching UI needs the exact same behaviors as a menu). Or perhaps some of those are better suited for <dialog> instead of <popup>.

I apologize that this is rather fundamental criticism, but I do feel like I've raised it repeatedly since the beginning of this endeavor, without much response. I appreciate getting some concrete engagement at this point.

No problem on the criticism - I'd like to get to a good solution here. I apologize that I don't think I realized this was "fundamental" - it sounds like you'd object to a general purpose <popup> element that fills many roles. So are you saying you'd prefer to see a proposal for many new elements, all with the same basic behavior (the three qualities I mentioned in my last comment), but different accessibility roles and semantic meaning? E.g. <tooltip>, <listbox> (would be useful in <selectmenu>), <menu> (oops), etc.?

I filed openui/open-ui#410 to discuss this issue further. Also happy to continue the discussion here.

[domenic]

So are you saying you'd prefer to see a proposal for many new elements, all with the same basic behavior (the three qualities I mentioned in my last comment), but different accessibility roles and semantic meaning?

Yeah, that would be one approach. Or <popup type="x">, but then you have a defaulting issue...

It's also worth considering how to map accessibility roles to use cases, e.g. the explainer's menus, form element suggestions, content pickers, and teaching UI. It's not clear to me whether a teaching UI is one of the three you listed (tooltip, listbox, menu), for example...

And again I'll reiterate that it's a bit surprising that those three exact behaviors (and no further behaviors) perfectly encapsulate what developers want for menus, listboxes, tooltips, teaching UIs, content pickers, and form element suggestions. E.g. at least on every operating system I'm familiar with menus and tooltips have very different focus behaviors, if nothing else.

[mfreed7]

So are you saying you'd prefer to see a proposal for many new elements, all with the same basic behavior (the three qualities I mentioned in my last comment), but different accessibility roles and semantic meaning?

Yeah, that would be one approach. Or <popup type="x">, but then you have a defaulting issue...

It's also worth considering how to map accessibility roles to use cases, e.g. the explainer's menus, form element suggestions, content pickers, and teaching UI. It's not clear to me whether a teaching UI is one of the three you listed (tooltip, listbox, menu), for example...

And again I'll reiterate that it's a bit surprising that those three exact behaviors (and no further behaviors) perfectly encapsulate what developers want for menus, listboxes, tooltips, teaching UIs, content pickers, and form element suggestions. E.g. at least on every operating system I'm familiar with menus and tooltips have very different focus behaviors, if nothing else.

These are very good points - there will definitely be some behavioral differences among these element types. I wasn't saying all of these elements would behave the same, I was saying that they (might?) all share the three "basic" behaviors with <popup>, in addition to some others. Or perhaps even some tweaks to the three.

Let's continue the discussion within the issue - there will likely be more people who can weigh in.

[mfreed7]

In response to your (very good) point that there are many open issues: I spent some time going through them all and putting them into categories. I will be working my way through them now, but I thought the list might be interesting. In particular, many/most of the “things to figure out” issues might be solved by breaking <popup> down into lower-level APIs, as we've been discussing. Also, many of the open issues are merely things to update/change about the spec text, or things unrelated to <popup> in particular.

• Missing features or things to figure out/resolve
  • What is the semantic meaning of <popup>?
  • Add an imperative API for anchor and popup attributes
  • Define all accessibility mappings
  • Should the popup be “hoisted” to a different location in the AX tree?
  • Allow a non-popup <popup> (remove top layer and light dismiss)
  • Figure out how/whether to control the “modalness” of <popup>
  • Should we allow cancelation of light-dismiss?
  • Should a popup be light dismissed when focus leaves the document?
  • Should scrolling the page be a light dismiss trigger?
  • Should custom elements be allowed to use the “popup” invoking attribute?
• Spec text suggestions / modifications
  • Light dismiss suggestions
  • Autofocus suggestions
  • Popup attribute show/hide behavior suggestions
  • Get the focusable area suggestions
  • Add popup IDL
  • Ensure delegatesfocus (or new name) does not trap focus (OpenUI resolved)
  • Add beforeShow,show,beforeHide,hide events (or new names) (OpenUI resolved)
  • Allow animating open/close for a popup (OpenUI resolved)
  • Make sure autofocus/delegatesfocus behavior is crisply defined
  • Focus should return to “previously focused element” on hide
  • Define the hide event sequence and details
  • Reference “all close signals” in defining light dismiss triggers
  • Make sure it is clear that each document has an independent popup stack
  • Ensure the initiallyopen attribute resolutions are properly described
• Bikeshedding names
  • Name of the <popup> element
  • Rename delegatesfocus to focuscontent or something (OpenUI resolved)
• Unrelated to <popup> specifically
  • Expanding delegatesfocus (or whatever it gets called) to other elements
  • Provide a web platform way to navigate directly to things that need to be opened/shown
  • Extend the primitives introduced with <popup> (e.g. delegatesfocus) to other elements
  • Raise issue with <dialog> to rename close() to hide()
  • Build a polyfill for <popup>

[plinss]

I want to echo @domenic's point about the semantics of <popup>. In general, this feels more like an abstract base class for popup-type elements than a concrete element in itself. (I'm also not a fan of <popup type="...">, I don't think <input> elements set a precedent we want to follow.)

But this leads me to a larger question of what the OpenUI group is trying to achieve. If you're trying to make high-level, semantic elements that can be styled, then <popup> isn't the right approach, you should be focusing on the specific types of popup elements you want. However, if OpenUI is trying to make generic UI building blocks that WC authors can use to compose custom UI elements (or can be used to explain behavior of existing elements), then a set of functional-but-not-semantic elements starts to make sense.

But looking at the set of elements OpenUI is considering, it's not clear that either approach is being deliberately taken. What I don't want to see is a half-and-half ad-hoc approach. Either focus entirely on high-level semantic elements, or deliberately choose a layered approach and create a new class of functional-only elements that are not meant to be used stand-alone, and then create high-level semantic elements that can be explained in terms of the generic building blocks (and polyfilled using them).

[mfreed7]

@plinss thanks for the comments. Have you seen the research page for <popup> on OpenUI? If not, I'd encourage you to take a look. I do think the approach is being fairly well thought-out. Perhaps not satisfyingly, the answer is "both". As you'll see on that page, a <popup> can be defined fairly broadly, and in significant detail, as an element that can be used on its own. It also forms a "base class" for several more-specific types of UI that share the base behaviors of <popup> but add or modify them in various ways. Those sub-class elements have high level semantics that map closely to ARIA roles. The super-class is more generic, and is basically "a lightweight, ephemeral piece of UI content that is displayed on top of page content".

[LeaVerou]

There is precedent in the Web Platform for having an abstract base class that contains shared API, and subclasses that correspond to specific tag names: HTMLMediaElement contains the shared behaviors between <audio> and <video>, whereas the base class does not correspond to a tag name, because it cannot be used directly. I wonder if a similar architecture would be more appropriate here than introducing a new element with no concrete semantics?

[hober]

There is precedent in the Web Platform for having an abstract base class that contains shared API, and subclasses that correspond to specific tag names: HTMLMediaElement contains the shared behaviors between <audio> and <video>, whereas the base class does not correspond to a tag name, because it cannot be used directly. I wonder if a similar architecture would be more appropriate here than introducing a new element with no concrete semantics?

Indeed, and should that base class also be the base class of <dialog>?

[LeaVerou]

Indeed, and should that base class also be the base class of <dialog>?

It's not an either/or, if HTMLDialogElement and HTMLPopupElement share API surface, it may make sense to make them inherit from a shared base class, then have HTMLPopupElement be further inherited by subclasses (e.g. listbox, tooltip, toast etc).

---

There are also certain behaviors here that I wonder if they might be more appropriate as global HTML attributes. E.g. autofocus and delegetesfocus are not only useful in popups (whatever that means).

[hober]

Hi everybody! Thank you for your patience as we've taken a while to get back to you on this one. Special thanks to @domenic for his thorough review of this feature. We're happy to see that there's been a bunch of productive conversation on this here and in various OpenUI issues. It sounds like the direction you expect this to go in is pretty different from what the current documents describe. We'd like to hold off on reviewing until you've updated the documents to match the current understanding. Please let us know when to revisit this!