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.