What is the semantic role for <popup>?

[mfreed7]

This is a question raised by @domenic on the TAG review for the <popup>, here. Copying the relevant part from that comment:

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>.

Should we be proposing several "flavors" of popup instead as separate elements, e.g. <tooltip>, <listbox>, etc.?

[chrisdholt]

I think the difficult thing we'll get into when proposing different flavors is that only some of them are consistently directly related to "popup". So elements like <dialog> and <tooltip> would both benefit from popup and have semantic meaning, but not every <listbox> is a <popup>. You could compose the select's listbox using popup, but a listbox element could also just render as a block level element in my application and not need any of that popup code. My understanding of <popup> has been that by default it is primarily functional and behavioral to enable it being used across a variety of scenarios with different semantics. While I think popup can enable those scenarios functionally, I'm not sure that requiring it to have semantic meaning by default is the best course of action. Totally up for discussion and a good thing to officially resolve, but I think if we add semantics to popup by default we're may end up needing to add additional requirements that could make it harder to reuse across a broader spectrum of elements.

[mfreed7]

I think the difficult thing we'll get into when proposing different flavors is that only some of them are consistently directly related to "popup". So elements like <dialog> and <tooltip> would both benefit from popup and have semantic meaning, but not every <listbox> is a <popup>. You could compose the select's listbox using popup, but a listbox element could also just render as a block level element in my application and not need any of that popup code. My understanding of <popup> has been that by default it is primarily functional and behavioral to enable it being used across a variety of scenarios with different semantics. While I think popup can enable those scenarios functionally, I'm not sure that requiring it to have semantic meaning by default is the best course of action. Totally up for discussion and a good thing to officially resolve, but I think if we add semantics to popup by default we're may end up needing to add additional requirements that could make it harder to reuse across a broader spectrum of elements.

Thanks for the comment. This was my take also - we're adding a functional component called <popup> that can be used to build several different kinds of UI. Kind of like <dialog> really. As such, the element itself has less specific semantic meaning. I do think that the idea has always been to keep going with new elements, e.g. <tooltip>, and those might use a <popup> for functionality. Or <selectmenu>'s listbox, as you mentioned. But those will be the elements/uses that have more direct semantic meaning. And <popup> can represent the more generic concept of a "thing that pops up", which I guess is role=dialog with aria-modal=false.

[mfreed7]

By the way, this issue relates directly to #329.

[domenic]

Role=dialog with aria-modal=false is the dialog element, so if that's the desired semantic this proposal should be morphed into an update or extension of the dialog element.

I disagree strongly with the idea that dialog is a "functional component", or that such a concept is even something the HTML language contains. HTML elements provide specific semantics; if you're using them to express functionality divorced from semantics, then HTML is not the right language to implement the API in.

[chrisdholt]

Role=dialog with aria-modal=false is the dialog element, so if that's the desired semantic this proposal should be morphed into an update or extension of the dialog element.

To be clear here, the desired semantic is none for popup. The intent of the element is functional; it could be used to build semantic elements such as the positioning, focus delegation, etc of dialog, but we are looking at usage well beyond dialog and with quite varying semantics (listbox of select menu).

[domenic]

Yeah, as I said in my edit, "the desired semantic is functional" is a contradiction in terms. It sounds like maybe this API is best done through JavaScript, not HTML---e.g. some JS function that lets you give an arbitrary element light dismiss behavior, or put it in the top layer. Then the semantics can be provided by HTML, and the functionality is done through JavaScript, in congruence with web platform design principles.

[chrisdholt]

Yeah, as I said in my edit, "the desired semantic is functional" is a contradiction in terms. It sounds like maybe this API is best done through JavaScript, not HTML---e.g. some JS function that lets you give an arbitrary element light dismiss behavior, or put it in the top layer. Then the semantics can be provided by HTML, and the functionality is done through JavaScript, in congruence with web platform design principles.

Just to be clear, I denoted “none” rather than functional as the desired semantics. I get your point, but it is an important difference IMO and I’d be curious how “none” is a contradiction as far as implicit role, etc. Is the bar for any new element an applied semantic that maps to ARIA? I’ll let others chime in here, but if the ask is to revisit this as a JavaScript API then it would be great to see that presented as an alternative. Much of this seems to exist in the platform already at some level (putting elements in the top layer), but isn’t exposed to authors. The intent of the element is to allow authors to compose UI without necessarily requiring JS. It seems reasonable to have that as an ask, but I’m certainly open to hearing why that’s not a feasible approach.

[chrisdholt]

@domenic as a quick follow-up, I just was reading up more through your responses in the linked issue. You mention:

No, this isn't correct. The dialog element can only be used for dialogs. Tooltips or toasts should be done using

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 but then override its exposure to accessibility tech using role=something else, the element is being misused.

I think, perhaps too boldly (?), we’re trying to create a scenario where creating these variations of UI doesn’t require a new element for every possible use case. In an attempt to not misuse, we see clear functional behavior that is consistent across a variety of UI with wildly different semantics. I’m personally totally open to a JS API for those, but I think prescribing semantics for just popup is going to lead to a dialog scenario. I think the trouble I’m having is that if the only way to standardize this behavior is through new elements for each, that’s going to be difficult, especially for scenarios like the listbox in select, or a context menu, where we want the functionality of the popup but as you call out, the semantics AND focus management are quite different from dialogs, tooltip, etc.

[domenic]

I’d be curious how “none” is a contradiction as far as implicit role, etc.

Sure. We already have two elements with "none" semantics: div and span. If people want to create elements with none semantics, then they should use div and span. Otherwise, new HTML elements should have new semantics.

Is the bar for any new element an applied semantic that maps to ARIA?

That's a good first approximation, IMO, but I wouldn't call it a hard-and-fast rule. In particular ARIA is mainly focused on roles that give different assistive-tech behavior, and "different semantics" are not 1:1 with "different AT behavior". For example, the <link> element has no ARIA role, but it has pretty clear semantics (linking to, or importing, an external resource). Similarly <input type=date>, <em>, or <br>.

Rather the relationship to ARIA I would promote is the one I alluded to in w3ctag/design-reviews#680 (comment), i.e. an implication of "the first rule of ARIA": we should never introduce a new HTML element which requires ARIA to function. So in particular, we should never introduce a new HTML element which we expect to, as a matter of course instead of as a special exception, be used with ARIA.

but if the ask is to revisit this as a JavaScript API then it would be great to see that presented as an alternative

I agree it would be great to see; that's why I brought up this issue, because we need the proposal proposal authors to investigate other ways of achieving the same goals that are congruent with the web platform design principles.

The intent of the element is to allow authors to compose UI without necessarily requiring JS. It seems reasonable to have that as an ask, but I’m certainly open to hearing why that’s not a feasible approach.

It's not feasible because, aside from div and span, HTML elements are a fundamentally about semantics, not behavior. You define a semantic for an element, and then derive behaviors that support that semantic.

If the goal of a proposal is to bring new behaviors, but no new semantics, then JS is the right manifestation for exposing them, not HTML.

(Ideally, those behaviors are done in a "layered" way (cf https://extensiblewebmanifesto.org/), so that JS already has access to these and the semantic elements just bundle them together into a declarative package with the right semantics. In the past that hasn't happened all that well; e.g., <details> was defined before the foundational layers (such as shadow DOM) were, and <dialog> is still defined without any other way of accessing the top layer (leading to the abuses of it that @mfreed7 mentions in w3ctag/design-reviews#680 (comment)). I don't think this kind of strict layering is required for all new elements, but it sure makes things nicer for authors in my experience.)

I think the trouble I’m having is that if the only way to standardize this behavior is through new elements for each, that’s going to be difficult, especially for scenarios like the listbox in select, or a context menu, where we want the functionality of the popup but as you call out, the semantics AND focus management are quite different from dialogs, tooltip, etc.

Yes, I think doing the right thing is hard :). But it's better than trying to ship popup, and over-claiming its applicability out of the box as something that works for menus, listboxes, tooltips, teaching UIs, content pickers, and form element suggestions. If in fact popup doesn't supply enough for those, but is only a building block, then I'd see two good paths:

• Do the extra work to create proper elements for those, reusing elements of the popup proposal + whatever additions or changes are necessary for each case.
• Try to move forward with a version of the popup proposal that is a behavior-only JS API, which can be applied to things like <div role="tooltip"> or <div role="menu"> while admitting that we haven't yet done the work to create full elements that embody the desired semantics and behaviors for tooltips/menus/etc.

[chrisdholt]

Thanks for the follow-up @domenic. Given this feedback @mfreed7, @gregwhitworth, @melanierichards we should probably prioritize this discussion at our next telecon.

I think many would like and prefer elements so that both the behavior AND semantics are available to web authors without having to include their own JS. I think that's the long-term ideal. With that said, my own selfish "immediate" needs and wants are the low-level JS API's. Some exist in some capacity already for the platform, but are not available to web authors. If I had to choose between the two today, I would take the JS API's as they'll better enable our building of custom elements with behavior we don't currently have access to today. If we had to "crawl, walk run" here, I'd personally prefer prioritizing the low-level API's and then leverage and reference those as part of specific custom-element proposals.

[yinonov]

Can such 👆 low level APIs integrate within built-in elements?
Should such "interior" component be exposed to web authors?
As mentioned, it doesn't have a semantic meaning on its own

[mfreed7]

So I understand the desire to "decompose" the current <popup> element proposal into lower-level APIs. And if that's possible, I can see the value in doing so. It would make it more straightforward to explain several new (potentially more-specific/semantic) HTML elements in terms of those APIs.

I'm curious about why this would be a Javascript API, though. It would seem more like a CSS primitive to me, since it deals with presentation: being on the top layer. Looking at the three functionalities provided in the original <popup> feature:

1. Presentation on the top layer. This seems like it would best be expressed as a CSS property, no? Something like:

popup {
  position: top-layer;
}

2. Light dismiss. Since putting it in the top layer is presentational, it would seem that taking it out would also be presentational, so another CSS property? Another concern: should it be possible to put something in the top layer without enforcing that it light dismisses? If so, it seems like a vector for abuse, but maybe not. If they are truly separate concerns, then perhaps something like (lots of bikeshed fodder here):

popup {
  light-dismiss: [none | esc | click-outside | scroll | other-top-layer-element | all]+
}

3. One-at-a-time. As I included in #2 above, I think this has to be part of light-dismiss. If the other-top-layer-element value is provided for light-dismiss, then that element is "one-at-a-time". If not, then multiple of them can exist simultaneously in the top layer. That feels a bit magical, since at least for <popup>, there is a stack of popups, created by examining their anchor attributes and/or other elements' popup attributes, and thus allowing multiple nested popups. I don't know how to achieve that in a standalone API. Suggestions welcome.

[domenic]

Oh, sure, CSS is also reasonable; sorry for forgetting that option.

[chrisdholt]

Good point @mfreed7 - I do like the idea of keeping those in the presentation layer. I know a couple additional things which were discussed as well were transitions/animations and focus management. For animations, I think the web animations API would provide the needed support there already. For focus management we do have a proposal out for focusgroup which was already being discussed in coordination w/ <popup>. Regardless of where that ends up, I think the primary point is that the right low-level API's can make creating things which popup much easier on web authors.

Subjectively, I like the idea of exposing the top-layer and light-dismiss behavior via CSS more so than JS. It feels intuitive and I think there is value for not requiring JS to achieve these specific functionalities.

RE: Your question on light dismiss above - my initial reaction is to lean into allowing things at the top layer which do not light dismiss. I'd agree that it's a vector for abuse, but there are existing (and I think legitimate) patterns where a user is asked to make a choice or declaration in order to proceed into the main portion of the UI. I definitely want to be conscious of the ways folks might misuse this, but it seems like a miss if we require light-dismiss for anything in the top layer.