HTMLPopupElement - <popup>

[mfreed7]

HIQaH! QaH! TAG!

I'm requesting a TAG review of the <popup> element.

A new HTML element, <popup>, which can be used to build transient user interface (UI) elements that are displayed on top of all other web app UI. These include user-interactive elements like action menus, form element suggestions, content pickers, and teaching UI. This new element is similar to <dialog>, but has several important differences, including light-dismiss behavior, anchoring, and the lack of a "modal" mode.

• Explainer: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Popup/explainer.md
• Security and Privacy self-review: All questions have a "no risk" answer, with the potential (very small) exception of this one:

Does this specification allow an origin some measure of control over a user agent’s native UI?
--> The <popup> element allows author-provided popup dialogs to be shown to the user. These popups are fully-contained within the owning frame, and do not overlap either parent frames or the browser UI. So there shouldn't be any issue here. But I'm bringing it up for completeness.

• GitHub repo (if you prefer feedback filed there): I'd prefer feedback here on this issue.
• Primary contacts (and their relationship to the specification):
  • Mason Freed (@mfreed7), Google
  • Melanie Richards (@melanierichards, Microsoft
• Organization/project driving the design: Google DOM Team, Microsoft DOM/Editing Team
• External status/issue trackers for this feature: https://chromestatus.com/guide/edit/5463833265045504

Further details:

• I have reviewed the TAG's API Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG
• The group where standardization of this work is intended to be done ("unknown" if not known): WHATWG
• Existing major pieces of multi-stakeholder review or discussion of this design: {coming soon}
• Major unresolved issues with or opposition to this design: "Major" is a strong word, but there is a section of the explainer that discusses open issues and questions. Thoughts on those issues would definitely be appreciated from TAG.
• This work is being funded by: Google and Microsoft

You should also know that...

I like 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 and @melanierichards

[LeaVerou]

Firstly, this is addressing a very real gap in the Web Platform and I'm happy to see work in that direction.

If my understanding is correct, this proposal introduces a <popup> element with the following features:

• An anchor attribute anchors this to another element, both in terms of styling, as well as other behaviors.
• Can "spill out of" containers, ignoring overflow: hidden
• It comes with some light behavior baked in, such as light dismiss
• It includes show() and hide() methods
• autofocus is handled specially when the popup is shown
• There is a delegatefocus attribute to focus the first focusable descendant when the popup is focused

Here are some thoughts.

Positioning

It seems to me that the primary problems this is trying to solve are styling problems:

• positioning a positioned element based on another element.
• allowing an element to "spill out" of overflow: hidden ancestors.

I think these are problems we should solve in CSS, rather than by introducing new "magic" that cannot be described fully in the UA stylesheet. Not only for separation of concerns, but also because this is more broadly useful and we wouldn't want people to have to wrap everything in a <popup> every time they need to position an element based on another element. The <popup> element can then just use that CSS as part of its UA stylesheet rules.

There are a few CSSWG threads on this, though there's definitely room for new proposals in this space:
w3c/csswg-drafts#5304
w3c/csswg-drafts#5699

Anchoring

I would suggest re-using the for attribute instead of introducing a new anchor attribute. This seems consistent with <label for> and <output for> usage.

It would be useful to have a default anchor, just like <label> elements default to form descendants when they do not have a for attribute. For example, the previous sibling and/or the parent element might be a good default. It also means that there is a more useful default than just displaying the popup at the top left corner, which is almost never desirable.

It is unclear to me if anchor affects tabbing order, but I think it should. There are many cases where the popup cannot be placed inside or next to the element it's anchored to, due to content model limitations or CSS inheritance. Authors should be able to continue the current practice of placing the popup as a child of <body>, without the current accessibility problems wrt tabbing order.

The hierarchy affects the event propagation path.

This could either be very useful, or very confusing, and I'm not sure which one it is.
I suppose there is precedent, with form elements receiving input events when their associated label receives these events.

Focus

On autofocus:

To move focus to the popup itself when show is called—without the need to explicitly call popupElement.focus()—place the attribute directly on the popup:

Are there use cases of showing the popup but not focusing it?

On delegatefocus:

Some authors may need to automatically focus the popup's first focusable descendent, and may not wish to write script to determine at runtime which element that is.

I wonder if that is the actual gap here: it should be easier to determine what the first focusable descendant is. But I definitely see the point about exposing this via HTML so that authors don't have to write script. But is this something specific to <popup> or a more generally useful behavior? I have definitely needed this before with arbitrary focusable elements (e.g. collection items).

Show and hide

I would recommend adding an open attribute, just like <dialog> so that authors can a) open the popup declaratively and b) target opened popups with an attribute selector.

Layering

Are rendered on top of all other content in the host web application

Even over <dialog>?

[mfreed7]

Firstly, this is addressing a very real gap in the Web Platform and I'm happy to see work in that direction.

@LeaVerou thanks for the great set of initial feedback here. I'm glad you think this is a useful addition. Responses below...

If my understanding is correct, this proposal introduces a <popup> element with the following features:

• An anchor attribute anchors this to another element, both in terms of styling, as well as other behaviors.
• Can "spill out of" containers, ignoring overflow: hidden
• It comes with some light behavior baked in, such as light dismiss
• It includes show() and hide() methods
• autofocus is handled specially when the popup is shown
• There is a delegatefocus attribute to focus the first focusable descendant when the popup is focused

The only thing I want to clarify here, which ties to the comments below, is that the positioning of the popup has been delegated to a separate platform proposal, for "anchored positioning". This has not been put forth yet, but the current <popup> proposal should be read in the context of a forthcoming proposal on positioning. I do understand the confusion here.

Positioning

It seems to me that the primary problems this is trying to solve are styling problems:

• positioning a positioned element based on another element.
• allowing an element to "spill out" of overflow: hidden ancestors.

I think these are problems we should solve in CSS, rather than by introducing new "magic" that cannot be described fully in the UA stylesheet. Not only for separation of concerns, but also because this is more broadly useful and we wouldn't want people to have to wrap everything in a <popup> every time they need to position an element based on another element. The <popup> element can then just use that CSS as part of its UA stylesheet rules.

See above. Really, I think the primary low-level problem that <popup> solves is access to the "top layer". I.e. the ability to position a popup over the top of everything else, regardless of position in the DOM tree or how many 9's you use in z-index:999999. The "magic" that isn't specified in this proposal is a way to anchor-position one element (the <popup> in this case) relative to the position of another element (e.g. the <popup>'s "anchor" element). As I mentioned, I believe a proposal is forthcoming. @melanierichards, @ipopescu93

Anchoring

I would suggest re-using the for attribute instead of introducing a new anchor attribute. This seems consistent with <label for> and <output for> usage.

Thanks for the feedback here. Consistency is important, but so is clarity. There is a discussion see this comment about naming, anchor positioning, and automatic (declarative) invokation. Those might require two separate attributes (e.g. "anchor" and "invokedby") that might need more verbose attribute names than just "for". Let's discuss further on the issue.

It would be useful to have a default anchor, just like <label> elements default to form descendants when they do not have a for attribute. For example, the previous sibling and/or the parent element might be a good default. It also means that there is a more useful default than just displaying the popup at the top left corner, which is almost never desirable.

I definitely agree with this point. We need to figure out the mechanics of this, since theoretically any element could be an anchor. The <label> spec is easier to implement because there's only one type of element to look for. Here, we might need to "stop" on an attribute or something, e.g.

<button im-the-anchor>
  <div id=not-the-anchor>
    <popup></popup>
  </div>
</button>

Suggestions appreciated here.

It is unclear to me if anchor affects tabbing order, but I think it should. There are many cases where the popup cannot be placed inside or next to the element it's anchored to, due to content model limitations or CSS inheritance. Authors should be able to continue the current practice of placing the popup as a child of <body>, without the current accessibility problems wrt tabbing order.

Hmm that's a very good point, which I don't think we've considered in the explainer. I would agree that since the <popup> can be placed anywhere, but will (usually) be visually next to the anchor element, it might make sense to modify tab order to account for this. @melanierichards thoughts?

The hierarchy affects the event propagation path.

This could either be very useful, or very confusing, and I'm not sure which one it is.
I suppose there is precedent, with form elements receiving input events when their associated label receives these events.

I agree that it might be confusing. As I've been implementing the prototype in Chromium, wrapping my head around this part has been tricky at times. Again, suggestions appreciated for ways to make it less confusing in practice.

Focus

On autofocus:

To move focus to the popup itself when show is called—without the need to explicitly call popupElement.focus()—place the attribute directly on the popup:

Are there use cases of showing the popup but not focusing it?

@melanierichards for better examples here. But I think one is likely a "teaching bubble" that pops up on hover of some other control, but you wouldn't want focus to move to the bubble in that case.

On delegatefocus:

Some authors may need to automatically focus the popup's first focusable descendent, and may not wish to write script to determine at runtime which element that is.

I wonder if that is the actual gap here: it should be easier to determine what the first focusable descendant is. But I definitely see the point about exposing this via HTML so that authors don't have to write script. But is this something specific to <popup> or a more generally useful behavior? I have definitely needed this before with arbitrary focusable elements (e.g. collection items).

One quick first comment is that I think we should call it delegatesfocus (with plural 's') to match the similar concept for ShadowRoot. Perhaps that's also the more generally useful behavior you're looking for?

Show and hide

I would recommend adding an open attribute, just like <dialog> so that authors can a) open the popup declaratively and b) target opened popups with an attribute selector.

See this related comment from @domenic. It does seem like we should make sure <popup> and <dialog> are as parallel as they can be here.

One (potentially big?) issue with opening the popup declaratively is that only one popup can be open at a time (excepting "nested" popups) so the behavior might be a bit odd if more than one <popup> has an open attribute. That can be fixed, of course, but I'm wondering if it might be better to just remove "open" from <dialog> instead. Also, the use case for <popup> seems to be in "response" to something on the page, which should preclude popups that open themselves immediately on page load. But maybe I'm missing a use case for that.

Layering

Are rendered on top of all other content in the host web application

Even over <dialog>?

<popup>s are rendered on the "top layer", in the order they were added. So if a <dialog> was already open, and a <popup> is shown, it will be rendered on top of the <dialog>. Further, a <dialog> being shown will trigger "light dismiss" behavior on any already-showing <popup>s.

[LeaVerou]

I definitely agree with this point. We need to figure out the mechanics of this, since theoretically any element could be an anchor. The <label> spec is easier to implement because there's only one type of element to look for. Here, we might need to "stop" on an attribute or something, e.g.

<button im-the-anchor>
  <div id=not-the-anchor>
    <popup></popup>
  </div>
</button>

Suggestions appreciated here.

I think the previous sibling or the parent are both reasonable defaults.
Slight preference for previous sibling, as it's less constrained and can work with empty elements as implicit anchors. A downside is that there might not be a previous sibling, but I suppose that is analogous to having a <label> with no for attribute and no form control descendants.

Show and hide

I would recommend adding an open attribute, just like <dialog> so that authors can a) open the popup declaratively and b) target opened popups with an attribute selector.

See this related comment from @domenic. It does seem like we should make sure <popup> and <dialog> are as parallel as they can be here.

One (potentially big?) issue with opening the popup declaratively is that only one popup can be open at a time (excepting "nested" popups) so the behavior might be a bit odd if more than one <popup> has an open attribute. That can be fixed, of course, but I'm wondering if it might be better to just remove "open" from <dialog> instead. Also, the use case for <popup> seems to be in "response" to something on the page, which should preclude popups that open themselves immediately on page load. But maybe I'm missing a use case for that.

Providing declarative HTML-based ways to interact with UI controls has several benefits. Off the top of my head:

• It facilitates experimentation and iteration (much quicker to type open when iterating than to write script)
• It makes it more learnable: there is a baseline uniform API (DOM) that novices can use to interact with the UI control via script, even before learning the more specialized API that might come with each individual control
• It means behaviors can be expressed reactively in libraries supporting such syntax (e.g. open={{expression}}) and be handled by any library handling HTML generically.
• It means UI states can be addressed via established and widely understood attribute selectors, instead of new pseudo-classes
• It makes state inspectable via dev tools which facilitates debugging

Therefore, I think removing open from <dialog> would be a step in the wrong direction. It would be far better to instead of fix its issues so it can be adopted in <popup> as well.

The fact that only one popup can be open at a time is not a blocker; there is already precedent with radio buttons and their checked attribute or <option> elements and their selected attribute. But are you sure there are no use cases of showing multiple popups at once? Nested popups is one use case that is expressly listed as an exception. Could there be more?