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