[Popup] Feedback from the perspective of HTML Standard editor

[domenic]

Hi Edge folks and community,

I'm excited about the popup proposal in many respects. I see there's lots of good web developer feedback happening already, which is great. I wanted to give some specific feedback from the perspective of a HTML Standard editor, focused on consistency with existing HTML elements and design principles.

The biggest piece of feedback is that the element really should stand on its own without requiring ARIA for its intended usage scenarios. No existing HTML element needs ARIA to become properly functional and accessible. From this perspective, the example code in https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Popup/explainer.md#showing-popups is quite worrying.

From what I can see, this has two sub-problems:

1. <popup> is serving many purposes, which map to different roles. E.g. menu is one role, but there are others. (Do you have an exhaustive list?) This could be solved in a few ways, such as:

   • Adding a type="" attribute. I see you've contemplated this in "Alternate Solutions Considered", and point out that this doesn't solve the whole problem because descendants might also need styling. I think this is solvable, e.g., you could state that type="menu" popups must use <li> children (and then have HTMLAAM make <li> children of <popup type="menu"> get the menuitem role mapping), or you could state that they must use a new element <menuitem> as children. But an alternative is...
   • Stating that <popup> is not meant to cover those cases, e.g., it must not be used for menus. Menus will be addressed by a future proposal which has proper support for modifying descendant roles, or comes with a dedicated <menuitem> element, or similar.

2. Properly hooking up a popup to its triggerer. This seems hard to solve without expanding the scope of the proposal, but I think it's pretty important. You shouldn't need all three of aria-haspopup="" on the <button>, aria-controls="" on the <button>, and anchor="" on the <popup>. You should need just one (non-ARIA) attribute to establish the relationship. And probably, that relationship should come with some default behavior.

Second, consistency with <dialog> is important. HTML as a whole benefits from being a more uniform language, both in terms of shared spec/implementation primitives, and in terms of learnability for developers.

There are a few particular ways I'd suggest converging:

1. Stay consistent on the naming of the methods, show() and close(). There's a long history backing the current naming; see e.g. https://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-December/041799.html and surrounding messages.

2. Port the proposed features from <popup> to <dialog> where they make sense, so that they can have parity. In particular, at first glance it seems like delegatesfocus="" and autofocus="" could be added to <dialog>, and gain the same behavior. (Whereas, probably anchor="" is <popup>-specific.)

3. Consider what to do with the open="" attribute. open="" is weird on <dialog>, but maybe we could fix it? Dialog should be better-behaved on misuse, probably whatwg/html#5802 Then we could have it for both <dialog> and <popup>. That would be ideal, IMO. Second-best would be making the affirmative decision in the HTML and implementer community that open="" on <dialog> was just a mistake, and should never be used; we would then deprecate it (i.e. tell web developers not to use it, even if implementations have to support it), and provide another styling hook for open <dialog>s and <popup>s.

4. Be sure to match the events sequence that dialog has, including cancel and close; I see your current proposal uses hide.

   • I also see that you have user-initiated light dismiss being uncancelable. I'm not sure this is the right decision, as developers seem very vocal for <dialog> that they need the ability to prevent closing it (by canceling the cancel event). But maybe this is a legitimate difference between <dialog> and <popup>. Maybe in that case the cancel event could be omitted and you could just have close.

[melanierichards]

Thanks so much for the feedback, @domenic!

Agreed that we need to move away from needing ARIA as best we can on this one. I think a lot of this can be solved when we come up with a good declarative solution for invoking the popup (e.g. an attribute that basically maps these relationships between popup and invoker under the hood). Regarding intrinsic roles for various subclasses of popups, that is where things get a little more interesting. It would be nice for folks to be able to use <popup> as the basis of various different "flavors" of popups, and then we can pave the cow-paths as needed with purpose-built elements for very common subclasses of popups. I'll follow up here with a list. Basically, we thought this would be best as a phased approach and wanted to avoid flooding the platform with a whole host of new elements (or over-loaded type attr, which doesn't solve the problem of required owned elements). All in balance!

Re: consistency with <dialog>:

Stay consistent on the naming of the methods, show() and close().

Thanks for this feedback, we went back and forth on whether it would be better for developer ergonomics to create symmetry between dialog and popup, or symmetry with show() and close()/hide(). Sounds that the former would be preferred.

Port the proposed features from to where they make sense, so that they can have parity.

Certainly in favor of doing this, we can call that out somewhere.

Consider what to do with the open="" attribute

SGTM!

Be sure to match the events sequence that dialog has, including cancel and close; I see your current proposal uses hide.

Sounds good, same comments as the show vs. hide discussion.

I also see that you have user-initiated light dismiss being uncancelable.

This is another one we went back and forth on; landed on this decision based on potential for abuse. Obviously an author can trap the user in UI using existing web APIs, but we thought it might be best not to build that into a new API.

[melanierichards]

A couple of the items have been addressed and I believe the rest should be captured in these Open UI issues:

openui/open-ui#116
openui/open-ui#321
openui/open-ui#322
openui/open-ui#323

Closing this one as part of the port to Open UI, but please let me know if I missed anything! Thanks again for your review.