• Component: select aka. dropdown
  • Platform/system: web, non-touch device (laptop with trackpad or desktop with a mouse)

Is there a guideline, convention, or some studies done which can help developers/designers decide when to open the select list exactly? On mousedown or on click?

enter image description here

Some custom third-party select implementations open the list first on click (mousedown+mouseup on the same element), whereas other implementations - especially the native ones - open it already on mousedown. Try, for example, the native HTML <select> element in your browser.

In my observation (using a Windows machine), all browsers opened the native select list consistently on mousedown, so there must be some guideline or convention when to open the <select> list with reasons behind it.

Personally, I'd also prefer opening the list on mousedown to improve perceived performance as well as consistency with the native behavior. But instead of personal opinion, I'd like to know what the general recommendation is (if there is any) and why with some numbers.

  • PS: to be clear, I'm not starting from scratch. There is an existing open-source implementation of a select control (made by a huge company) which I'm considering to use, but it feels slow. I'd like to contribute to their source code to change its behavior to improve its perceived performance by opening the list on mousedown already, but before doing that, I need to make sure if it really does, and not just for me. Commented Dec 12, 2019 at 18:16

3 Answers 3


From an accessibility point of view, It is recommended that the event should be fired on mouse up rather than on mouse down.

This will be helpful for users with dexterity/motor disabilities, Who might accidentally click on the list without the intention to do so. So when the event is fired on mouse up, that will give these users a chance to cancel the action by moving away from the target holding the mouse down.

By following this method the application can be complaint with Success Criterion 2.5.2 (Pointer cancellation) of WCAG 2.1

you can read more about it here: https://www.w3.org/WAI/WCAG21/Understanding/pointer-cancellation.html

  • Thanks for the insight (+1). That makes me wonder though, why browser vendors, no matter which platform (Win/Mac), collectively decided to ignore the WCAG spec and implemented only the <select> in a way that it opens the list already on mousedown..? Commented Dec 12, 2019 at 19:05
  • Not just these vendors, but even big enterprises even deliberately or by ignorance don't follow these guidelines.and that often result in hefty lawsuits. And WCAG 2.1 is an update to the WCAG 2.0 which is currently being followed by all the companies who just want to be compliant for the sake of the law. Let's hope they soon implement this.
    – Sooraj MV
    Commented Dec 13, 2019 at 4:06
  • Just filed an issue on Chromium: bugs.chromium.org/p/chromium/issues/detail?id=1034352 Commented Dec 16, 2019 at 13:16
  • I checked the interactive HTML demo you mentioned in the issue, One thing I noticed that it is actually compliant with the SC 2.5.2 by providing the 'Up Reversal' mechanism. which means, when I click and hold on the dropdown list and release the mouse after a few seconds it closes the list and has effectively canceled the operation which the down event triggered. So technically this is not a bug.
    – Sooraj MV
    Commented Dec 16, 2019 at 16:45
  • I double-checked the SC again. About the closing behavior after releasing the mouse on the list: Yes, it closes the list but I don't see it as a "canceling" or "reversing" action. The list closes because the user ultimately chose something. There was no reversing action. A reversing action would be closing the list without selecting something new. Commented Dec 16, 2019 at 16:58

Sooraj MV is correct that actions are recommended to only be executed on mouse up, however simply opening the Select Input is an action that can be reversed and recovered from, by moving the mouse away and releasing.*

Looking at the success criteria of the WCAG guideline, it states that one or more of the following have to be satisfied:

No Down-Event

  • The down-event of the pointer is not used to execute any part of the function.

Abort or Undo

  • Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or to undo the function after completion.

Up Reversal

  • The up-event reverses any outcome of the preceding down-event.


  • Completing the function on the down-event is essential.

I would argue that opening the Select form control on mouse-down and having it close on mouse-up outside the control satisfies 'Abort or Undo' (if completion is defined as the selection of an option, though debatable) and 'Up Reversal' (as the mouse-up reverses the opening of the control's options without forcing selection).

One benefit of it opening on mouse-down is that in the one interaction (mouse down, move, mouse up), you can select an option, as I've visualised here:

Option being selected in one mouse down and up, with mouse down action illustrated

You perceive it to be quicker not only because there's immediate feedback closer to the first part of the interaction (mouse-down), but because it actually is quicker to achieve your goal of making a selection.

I could not find any reference to the 'correct' behaviour. I would have expected it referenced in W3C Forms / Select, or Microsoft Combo Boxes documentation pages.

You may want to factor in whether the application is used by expert users who will become very familiar with the interface and benefit from any potential accelerators (typically business portals, service oriented web apps), or more-so by new users who wouldn't take advantage of that accelerator (typically ecommerce websites).

If the component has everything else going for it, create a basic prototype using it, and see how the difference in interaction design impacts users, if at all.

As an aside, the trouble with web components is that they are often consistent within their design system / component library, but don't adopt the conventions of the ecosystem they exist in (browser / operating system).

* This behaviour is seen on Chrome / Mac, I can't attest as to why different browser and OS combinations may work differently.


Mousedown is indeed faster according to Design, User Experience, and Usability: Users and Interactions: 4th ..., Part 2 edited by Aaron Marcus

"Mouse down based selection tasks were shown to have higher performance than tasks based on mouse up events."

What is known is that when it comes to deciding between click or mouse down action, the factor to consider is error prevention.

For example Google Chrome uses mousedown to switch pages and click to close a page.

enter image description here

While experienced users might not click things by mistake a lot of motor-impaired users can misclick and offering the option to cancel out a gesture is useful but again especially where the action can lead to error.

On a more personal note on Macbook in the Display Settings there is a dropdown for Rotation that is accesed by mousedown. A person with impaired motor skills would easily rotate their screens by 180 degrees.

So I would recommend that you ensure that the changes made by making a selection in the dropdown are not huge, irreversible and that visual cue is provided when making a new selection.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.