[popup] Should light dismiss happen on mousedown or mouseup?

[mfreed7]

In the Chromium prototype, and in the explainer, light dismiss happens on mousedown. I implemented and wrote it that way based on a quick survey of both native and web popup implementations - all seem to dismiss on mousedown. Additionally, using mousedown instead of mouseup allows someone to mousedown on the popup and drag off of the popup before mouseup, for example when selecting text. Because the mousedown was on the popup, no light dismiss happens. In a local prototype, it was fairly jarring when implemented on mouseup, when trying to select text on the popup: it would close inadvertently fairly often.

However, @scottaohara pointed out that this might be less accessible, for example for someone with motor disabilities who accidentally clicks outside a popup and needs the opportunity to return the mouse to the popup before mouseup to avoid dismissing it.

What do folks think?

[mfreed7]

Any comments here? I'm inclined to just close this and keep the default/common behavior of triggering on mousedown. Any objections?

[aardrian]

I tend to agree with Scott.

I have worked with and watched users with mobility impairments mis-click aplenty (never mind whenever I am on a train), and sometimes holding the mouse button down is a lifeline to prevent an even more burdensome set of steps just to restore their task.

Generally, the more 'destructive' an action to the current state, the more I want to err on allowing it be aborted. Changing context, removing content, etc. are arguably destructive.

Looking to existing native patterns might be insightful. which you said you did. Since I do not know what you reviewed, I am making a quick list between meetings (all tested only on Windows because time):

• clicking a link (which is a change of context) fires on mouse up;
• clicking the "Comment" <button> on this issue fires on mouse up;
• clicking a native <details>/<summary> fires on mouse up;
• clicking outside the <dialog> as implemented in the example for Google fires on mouse up;
• clicking an option from an <input>s associated <datalist> fires on mouse up;
• clicking an <option> from a <select> fires on mouse up.

There may be more, but I have a call starting.

[mfreed7]

Thanks for the comment! So on your examples:

• clicking a link (which is a change of context) fires on mouse up;
• clicking the "Comment" <button> on this issue fires on mouse up;
• clicking a native <details>/<summary> fires on mouse up;

None of these three are a "light dismiss" type interaction. All of these are "activate" actions. I do think there's a behavioral difference between activating a link/button and light dismissing content.

• clicking outside the <dialog> as implemented in the example for Google fires on mouse up;

This is a light dismiss example, but it is not exactly a widely-used platform or site. However, I do agree it light dismisses on mouseup.

• clicking an option from an <input>s associated <datalist> fires on mouse up;

I'm not sure which browser/OS you tried this one on. For me, on Chrome with either Mac or Windows, the example below both a) opens the datalist and more importantly b) light dismisses it on mousedown, not mouseup:

data:text/html,<input type=text list=foo><datalist id=foo><option>foo<option>bar</datalist>

Is that different from what you're seeing?

• clicking an <option> from a <select> fires on mouse up.

Again here, on Chrome with both Mac and Windows, I see the select menu a) open and b) light dismiss on mousedown, not mouseup:

data:text/html,<select><option>foo<option>bar</select>

Is that different from what you're seeing?

Additionally:

• my native MacOS 11 system will light dismiss a popup (e.g. the Apple menu at the top) on mouse down, not mouse up.
• my Windows 10 system will light dismiss a popup (e.g. the popup you get when clicking in the "Search" box at the lower left) on mouse down, not mouse up.
• my Linux system is currently refusing to boot up - perhaps someone can test on their system?
• because websites have to implement this manually each time, some (like Github) light dismiss popups on mouse up, and others (like www.google.com) light dismiss on mouse down. In the past, we've favored modeling behavior after OS conventions, since they typically spend more time/research on UX patterns like this.

My main concern is just avoiding inventing a new way of doing this that differs from other major platforms, without a good reason to do so. Not just because it might be "wrong", but also because for a11y users who are accustomed to this behavior, changing it could cause confusion.

[aardrian]

None of these three are a "light dismiss" type interaction. All of these are "activate" actions. I do think there's a behavioral difference between activating a link/button and light dismissing content.

Fair point.

• clicking outside the as implemented in the example for Google fires on mouse up;

This is a light dismiss example, but it is not exactly a widely-used platform or site. However, I do agree it light dismisses on mouseup.

I don't understand. Which is not the widely used platform/site? Native support for <dialog> relatively new, and Google has this post showing it off.

• clicking an option from an <input>s associated <datalist> fires on mouse up;

I'm not sure which browser/OS you tried this one on. For me, on Chrome with either Mac or Windows,

I noted Windows, but specifically I was hitting those with Firefox first, then Chrome.

the example below both a) opens the datalist and more importantly b) light dismisses it on mousedown, not mouseup:

data:text/html,<input type=text list=foo><datalist id=foo><option>foo<option>bar</datalist>

Is that different from what you're seeing?

I said "fires" when I should have said "selects". The menu itself dismisses on mouse down. I was looking at things that can change the meaning or interaction of a page, which is why I went there. I explained that poorly.

Additionally:
[...]

No time to fire up my *nix VMs, and not bothering with my Mac because I don't doubt what you are seeing.

However, my broader goal here is not to look to the OS patterns, but to look to native patterns. For example, on my OS I cannot select any text from many dialogs. On the web, I can. Not only that, on the web, dialogs are more likely to have more content, more interactivity, and less purpose than OS dialogs.

There was/is a great example of this in the WHAT HTML PR to advise putting focus on the dialog by default instead of the first focusable item. Accessibility practitioners, AT users, UX folks all agreed that was the right approach. The WHATWG editors have steadfastly refused because that's not how Windows works. Never mind the context and use are completely different.

4 years it has sat open, blocked by effectively one person.

APG for years has pitched using menu roles, meant to mimic native operating system menus, for site navigation. As above, folks in the know have said no.

5 years it has sat open, blocked by effectively one person.

I want to be very careful the Windows95-ification of the web does not continue without good reason.

The use cases for dialogs on the web are different enough, IMO, to be more cautious in how we allow users to dismiss them, particularly given how content can be hard to restore, devs often dump field values, just trying to zoom the page to read could cause a light dismiss, and so on.

Also, the durn Apple and MDN examples don't even dismiss, else I would have included them.

My main concern is just avoiding inventing a new way of doing this that differs from other major platforms, without a good reason to do so. Not just because it might be "wrong", but also because for a11y users who are accustomed to this behavior, changing it could cause confusion.

Minor point here — there is no such thing as a11y users. There are users, some with different abilities, some in different contexts, some with different needs. This is long-form writing, so let's not use the numeronym a11y, and let's definitely not reduce people to accessibility users. Yes, I am grumpy about this. It has been a long day of dealing with "ADA users" and "those people" and "edge cases" for clients that serve to dehumanize and minimize people just trying to live their life against a technology backdrop of zero consideration (not saying that is the case here, but my hackles are raised to level 11 today).

Ok, late for my next meeting.

[mfreed7]

• clicking outside the as implemented in the example for Google fires on mouse up;
  This is a light dismiss example, but it is not exactly a widely-used platform or site. However, I do agree it light dismisses on mouseup.

I don't understand. Which is not the widely used platform/site? Native support for <dialog> relatively new, and Google has this post showing it off.

The site you posted is a demo site that has custom JS to implement light dismiss. The <dialog> element does not do light dismiss at all - you have to call dialog.close() in JS, and you have to decide when to do that. This particular demo site chose to use mouseup or more likely click. This is one of the main (hard) things that we're trying to make better with the pop-up API, so that there can be a consistent interaction pattern for this type of UI.

• clicking an option from an <input>s associated <datalist> fires on mouse up;

I'm not sure which browser/OS you tried this one on. For me, on Chrome with either Mac or Windows,

I noted Windows, but specifically I was hitting those with Firefox first, then Chrome.

I just tried Firefox on both Windows and Mac, and both of them light dismiss the datalist pop-up on mouse down. Are you not seeing the same thing? I can get more specific about versions and things, if you see a light dismiss on one of these platforms on mouse up.

I said "fires" when I should have said "selects". The menu itself dismisses on mouse down. I was looking at things that can change the meaning or interaction of a page, which is why I went there. I explained that poorly.

I do think it's important to look at equivalent UX actions, and in this case, we're definitely talking about light dismiss of pop-up UI. I agree many other patterns use different triggers. Activating a button, link, or option uses mouse up, picking a date or color from a color picker frequently uses hover, etc. But let's focus on light dismiss.

However, my broader goal here is not to look to the OS patterns, but to look to native patterns. For example, on my OS I cannot select any text from many dialogs. On the web, I can. Not only that, on the web, dialogs are more likely to have more content, more interactivity, and less purpose than OS dialogs.

This is a fair point.

... skipping a chunk of your comment, because it's counterproductive ...

The use cases for dialogs on the web are different enough, IMO, to be more cautious in how we allow users to dismiss them, particularly given how content can be hard to restore, devs often dump field values, just trying to zoom the page to read could cause a light dismiss, and so on.

Also, the durn Apple and MDN examples don't even dismiss, else I would have included them.

Again here, <dialog>, by design, doesn't light dismiss. So demos really shouldn't do it. That's a functionality we're trying to add with the pop-up API.

My main concern is just avoiding inventing a new way of doing this that differs from other major platforms, without a good reason to do so. Not just because it might be "wrong", but also because for a11y users who are accustomed to this behavior, changing it could cause confusion.

Minor point here — there is no such thing as a11y users. There are users, some with different abilities, some in different contexts, some with different needs. This is long-form writing, so let's not use the numeronym a11y, and let's definitely not reduce people to accessibility users. Yes, I am grumpy about this. It has been a long day of dealing with "ADA users" and "those people" and "edge cases" for clients that serve to dehumanize and minimize people just trying to live their life against a technology backdrop of zero consideration (not saying that is the case here, but my hackles are raised to level 11 today).

Sorry, you're right that I should have said "AT Users" rather than "a11y users". I will continue to use a11y to represent "accessibility", since that's a fairly common abbreviation, and like you, I've got a lot to do, so abbreviations help. Sorry your hackles are raised, but I don't believe I've ever said or acted in a way to minimize a11y concerns. In fact, I'm an engineering lead on several projects that are attempting (though it's difficult!) to provide "accessibility by default" to various web technologies. Please re-read my OP for this issue - I'm trying to find the best approach that includes as many people as possible.

---

This discussion is getting off topic. To bring it back to the OP, what is the right trigger for pop-up light dismiss? User confusion and errors can happen either way. Which way (mouse-down or mouse-up) causes the least such confusion? Please reply with data or evidence. The only evidence I have is the current fairly-consistent patterns on major desktop operating systems. I agree that's not the same as the web. However, I don't have data to point me in a different direction.

[scottaohara]

I'm also finding that light dismiss works on mouse down across windows/mac for native select listbox popups, or the datalist popup (mouse down outside of the popup).

Other native popup menus (e.g., a browser's menu, or right-click context menu) also dismiss on mouse down.

I think if we're looking purely at data of existing functionality, a mouse down to dismiss a popup has precedent.

My concern there is that mouse up is more forgiving for people who mis-click, and I would submit that the mouse down behavior - though being long standing, is not user friendly. This is what WCAG 2.5.2 Pointer Cancellation is trying to address. A quick summary from the intent paragraph of the criterion:

The intent of this success criterion is to make it easier for users to prevent accidental or erroneous pointer input. People with various disabilities can inadvertently initiate touch or mouse events with unwanted results. Each of the following subsections roughly aligns with the bullets of this Success Criterion, and outlines a means of allowing users to cancel pointer operations.

Light dismiss could be done on mouse down. It'd fall into the realm of codified OS platform behaviors - but developers who were adhering to wcag and have built their own custom components should have been following the 2.5.2 rule where popups shouldn't have dismissed on mouse down. For instance, the popup menus that Github has in the header area of this web page, those dismiss on mouse up. Those are more forgiving of accidental outside clicks.

[mfreed7]

Ok, thanks for confirming the OS behavior, and also for pointing out the relevant WCAG guidance. Based on that guidance, I’m getting more inclined to agree with your (and @aardrian‘s) desire to change to mouse up.

One thing that this will make more difficult is trying to select text on a popup. If the user mouses down on some text in a popup and then drags off the popup before letting go, the popup will dismiss, along with whatever text they tried to highlight. I suppose we could mitigate that by tracking whether mouse down happened within the popup, and in that case, don’t light dismiss on mouse up no matter where it occurs. Thoughts?

[aardrian]

I stepped back because I was testing things outside the scope of the question, which meant I was adding noise.

However...

If the user mouses down on some text in a popup and then drags off the popup before letting go, the popup will dismiss, along with whatever text they tried to highlight. I suppose we could mitigate that by tracking whether mouse down happened within the popup, and in that case, don’t light dismiss on mouse up no matter where it occurs. Thoughts?

This is indeed infuriating when it happens. My tactic (just mine, not a recommendation) is to hit Ctrl + C while my mouse button is down, and then release. This does not scale to others, particularly if there are mobility impairments. If anything, it is me acknowledging what a pain in the bum that is.

[keithamus]

One interesting interaction that might provide insight is completing actions on an interactive popup element - eg menu actions - within a single mousedown/mouseup combination. On many Operating systems (including Linux and macos, and I believe windows) drop down menus open on a mousedown. With the mouse held down, one can navigate over an item, and release the mouse- the mouseup event will cause a selection of that item.

Now with that behaviour considered, consider how dismissing a menu with a mousedown might work: you’d have to mousedown to open the menu, navigate away from it, mouseup, mousedown, and mouseup again (well this last one isn’t necessary but now you’re stuck holding your mouse down).

On OS menus if you mousedown (to open the menu) mouse move away from the menubar, and then mouseup away from the menu, the menu will be dismissed.

This to me suggests that mouseup to dismiss might be the right behaviour.

[keithamus]

One thing that this will make more difficult is trying to select text on a popup. If the user mouses down on some text in a popup and then drags off the popup before letting go, the popup will dismiss, along with whatever text they tried to highlight. I suppose we could mitigate that by tracking whether mouse down happened within the popup, and in that case, don’t light dismiss on mouse up no matter where it occurs. Thoughts?

In my testing, I’ve found some apps or OSes seem to mitigate this behaviour. I need to do further testing to figure out how but it seems if you select text and mouseup outside of a menu that allows selection, it’ll consider the mouseup end of selection and not a dismissal of the menu.

[hidde]

If the user mouses down on some text in a popup and then drags off the popup before letting go, the popup will dismiss, along with whatever text they tried to highlight. I suppose we could mitigate that by tracking whether mouse down happened within the popup, and in that case, don’t light dismiss on mouse up no matter where it occurs. Thoughts?

If this could be mitigitated in the way you describe, that would be very helpful as I agree with you and others that this would be a nuisance.

[keithamus]

After playing around a bit, the simplest implementation that offers the most "usability" seems to be:

• A popup can open on mousedown
• Interactive children (e.g menu items) are engaged with mouseup
• Dismissing the popup is engaged with mousedown outside the popup

This allows for:

• Selecting a menu item within a single click (mousedown, cursor to menu item, mouseup)
• Text selection works "for free" inside a popup, and moving your pointer outside of the popup during a selection will not dismiss the popup (mousedown to select, cursor to outside, mouseup and the popup won't trigger dismissal)
• Full discrete click events still work (a full click to invoke a popup, followed by a full click to either dismiss or choose a menu item)

Having read through https://www.w3.org/WAI/WCAG21/Understanding/pointer-cancellation.html, I believe the intent here is to avoid users accidentally engaging actions which might be potentially destructive. In the case of opening or dismissing a popup, it feels as though neither of these actions are destructive. I do agree that no menu item should be invoked from a mousedown as these can often be non-idempotent actions (e.g close, quit, reload, save) but invoking or dismissing a popup is very likely to be idempotent and non-destructive (unless you have a very bad design). Invoking menu items on mouseup addresses the concerns & (I believe) intent of the WCAG document.

As such I think mousedown is the correct conclusion for dismissing a popup.

[scottaohara]

A popup can open on mousedown

i disagree that this would be universally acceptable. native select elements work this way, yes. In contrast, recommended APG custom select-only comboboxes and even Github's popup menus/disclosure widgets, for example, are displayed on mouse up. This is preferrable.

re:

I believe the intent here is to avoid users accidentally engaging actions which might be potentially destructive.

That is one of the goals, yes. But the intent is also simply introduced as:

The intent of this success criterion is to make it easier for users to prevent accidental or erroneous pointer input.

Followed later by:

The most accessible way to incorporate pointer cancellation is to make activation occur on the up-event.

with the stipulation:

Completing the function on the down-event is only permitted when it is essential that the up-event not be used.

So, if it's necessary to dismiss a popup on mousedown for some specific reason, then sure, that makes sense. But regarding:

Text selection works "for free" inside a popup, and moving your pointer outside of the popup during a selection will not dismiss the popup (mousedown to select, cursor to outside, mouseup and the popup won't trigger dismissal)

This seems like the main reason? I too am curious if this is an actual blocker though? For instance, I've seen many custom popups with outside mouseup clicks to dismiss not dismiss if I were to select text and drag my mouse outside the boundaries of the popup, and then let go of the mouse click. Again, Github's popups (being they are so readily available to test) behave like this. That said, I very much would like to understand the issues around why this might be difficult to implement at the platform level, but is what people seem to be able to do with custom popups now?

[keithamus]

I don't want to derail or otherwise spend a lot of time attempting to challenge guidelines that people have already deliberated over. If there's reasonable justification for using mouseup more than simply existing precedent then let's go with mouseup.

Github's popup menus/disclosure widgets
Again, Github's popups (being they are so readily available to test) behave like this.

GitHub has a variety of popups enacted in different ways. The UI is a little inconsistent (something we're hoping to solve by unifying the design & behaviours, and why we're interested in this proposal). We currently have no guidelines recommending one way or another, and so engineers generally reach for click as an event handler.

The click handler is not a mouseup. mouseup would allow the user to start with a mousedown outside of the elements bounding box, and move the cursor over the elements bounding box then mouseup. A click requires both the mousedown and mouseup events to occur inside the elements bounding box, which means click events that have mousedown/mouseup on different targets tend to emit a click event on a parent container instead, usually the <body>.

why this might be difficult to implement at the platform level

I don't think difficulty in solving this is necessarily a concern, than is more having sensible defaults. If we pick something that developers won't prefer then we're back to square one where they will re-implement behaviours themselves.

[mfreed7]

Ok, it sounds like maybe we're starting to come to a consensus that mouseup should be the light dismiss trigger, for accessibility reasons (particularly based on WCAG 2.5.2 Pointer Cancellation). This is different from the platform convention, but there appear to be good reasons to depart from that convention. It does sound like we need to be a bit more nuanced to allow for the "highlighting text on a pop-up" use case, by avoiding light-dismiss when the mousedown is inside the pop-up, and mouseup is outside it. Would folks agree with this general direction?

One interesting interaction that might provide insight is completing actions on an interactive popup element - eg menu actions - within a single mousedown/mouseup combination. On many Operating systems (including Linux and macos, and I believe windows) drop down menus open on a mousedown. With the mouse held down, one can navigate over an item, and release the mouse- the mouseup event will cause a selection of that item.

This is an interesting case. The existing Chromium prototype activates the <selectmenu> on click, which precludes this behavior. @dandclark it'd be interesting to see whether it would be easy to convert <selectmenu> to activate on mousedown, and allow single-action selection this way. I think it'd be perfectly compatible with the behavior I describe for pop-up in the first paragraph of this comment. A mousedown on the <selectmenu> followed by a mouseup outside the pop-up would light-dismiss the <selectmenu> pop-up without picking anything. Which seems correct.

[css-meeting-bot]

The Open UI Community Group just discussed [popup] Should light dismiss happen on mousedown or mouseup? #529, and agreed to the following:

• RESOLVED: light dismiss should happen on mouseup. The pop-up should not be light-dismissed if the mousedown happened within the pop-up (to allow text selection).

The full IRC log of that discussion

<gregwhitworth> Topic: [popup] Should light dismiss happen on mousedown or mouseup? #529
<gregwhitworth> github: https://github.com//issues/529
<hdv> masonf: this is about the specific mouse action that light dismisses a popup
<hdv> masonf: from an accessibility point of view it sounds like it should be mouseup, the current behavior in most operating system and in current Chromium prototype is mousedown
<hdv> masonf: is there any objection to moving forward with mouseup?
<hdv> gregwhitworth: why, given it is in all the OSes… if it was a major accessibility concern, what is making the web different from those scenarios?
<hdv> masonf: TLDR I think is that there is more recent guidance as to how to do this and we have the opportunity to get it right now
<hdv> scotto: yes, this is a newer WCAG rule… it is particularly about people with mobility issues… WCAG for long was web content authoring guidance, and for things that are basically rendering on the OS level, they were usually not taken into considerations
<hdv> scotto: but now that more people are building their own things like popups, it would be better usability… it was never considered before because the web was different when these guidelines came in
<hdv> scotto: it seems like it would make sense the OS would change
<hdv> gregwhitworth: yeah my thinking was that that would make sense
<hdv> scotto: I'm not sure if there is a reason why we shouldn't got this way…I am open to that, but haven't heard any
<masonf> Proposed resolution: light dismiss should happen on mouseup. The pop-up should not be light-dismissed if the mousedown happened within the pop-up (to allow text selection).
<hdv> +1!
<masonf> RESOLVED: light dismiss should happen on mouseup. The pop-up should not be light-dismissed if the mousedown happened within the pop-up (to allow text selection).

[mfreed7]

Based on the resolution, I'm going to close this issue. I'll get this changed in the Chromium prototype.

@josepharhar FYI for the spec PR.