-
Notifications
You must be signed in to change notification settings - Fork 218
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Popup] Feedback from the perspective of HTML Standard editor #455
Comments
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 Re: consistency with
Thanks for this feedback, we went back and forth on whether it would be better for developer ergonomics to create symmetry between
Certainly in favor of doing this, we can call that out somewhere.
SGTM!
Sounds good, same comments as the show vs. hide discussion.
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. |
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 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. |
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:
<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: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 thattype="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...<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.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>
, andanchor=""
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:
Stay consistent on the naming of the methods,
show()
andclose()
. 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.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 likedelegatesfocus=""
andautofocus=""
could be added to<dialog>
, and gain the same behavior. (Whereas, probablyanchor=""
is<popup>
-specific.)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 thatopen=""
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.Be sure to match the events sequence that dialog has, including
cancel
andclose
; I see your current proposal useshide
.<dialog>
that they need the ability to prevent closing it (by canceling thecancel
event). But maybe this is a legitimate difference between<dialog>
and<popup>
. Maybe in that case thecancel
event could be omitted and you could just haveclose
.The text was updated successfully, but these errors were encountered: