I've grown used to the GUI paradigm of pre-select on mouse-down, action on mouse-up. In fact, I rely on it, sometimes canceling an unwanted action after mouse-down by dragging outside of the click area and then releasing the mouse.

However, this is only an arbitrary standard, and may not be universal. For example, I noticed that in Microsoft Outlook's header pane, category selection occurs on mouse-down (and interrupts attempts to drag).

With the introduction of touch-oriented interfaces, the dividing line is even sharper. iOS automatically "retracts" finger-down events and converts them into drag-view events when the finger moves after finger-down.

What are some situations where it's preferable to take action on mouse-down? What sorts of actions are better this way, rather than waiting for mouse(/finger)-up?

  • 3
    I believe it's absolutely required for Dragging :)
    – Itumac
    Jan 8, 2013 at 1:49
  • @Itumac Sometimes (drawing a line springs to mind) but at other times the action (dropping and saving the new position of an object) actually happens on mouse-up. You could in theory abort the action mid-drag.
    – Matt Obee
    May 14, 2013 at 14:20

4 Answers 4


I think you'll find most selection processes act on mouse button down - choosing items in lists, tables, tab header bars etc. With tabs, most implementations I see at least change the selection in the tab header, but might not necessarily actually switch the content page until the mouse up.

With tabs it's good to get the content switching on mouse down because if the tab is draggable (to its own window or just to reorder tabs), then you get to see the content you are about to drag before you actually start moving the mouse.

Also changing input focus between fields, or changing caret position within text is done on the mouse down as that then allows you to immediately start selecting a block of text. To have to click, release and click again to start selecting text would be annoying.

Clearly, mouse down is a prerequisite to a drag operation and therefore depending on the context, the mouse down sets up the pre-drag conditions - for example starting a selection marquee in a paint or drawing app.

I think it's going to be prevalent in areas of direct manipulation where you interact directly with the content for exactly this reason - setting up and preparing for the drag, and depending on what the drag is going to do, that preparation may require visual feedback or state change on the button down.

I don't think we can do without actions on mouse down - it's a great opportunity to provide immediate feedback about the impending action - whether that's as a result of mouse up or drag or anything else.

  • I think what you're calling 'action on mouse down' I'm calling 'highlight on mouse down'. What I mean by action is something that affects more than just the interface--for example, having a window vanish on mouse-down. Jul 14, 2011 at 15:28
  • 2
    I'm not sure about something that drastic. How about (again under the direct manipulation theme) when you emulate real world movements - say you have spun a spinner or flicked an object across your screen and it's sliding and slowing down, or if you're flicking screens to one side, or zooming in. You would want to press the mouse down and have that stop the process immediately on mouse down as if you were physically applying friction yourself to the object - almost feeling that the harder you press the faster it's going to stop. Only when the movement has stopped would you release the mouse. Jul 14, 2011 at 15:57

TL;DR Stick to mouse up, that is what everyone is doing, user will expect it.

Keep in mind that in the real world, we are far more accurate than on devices.

When we push down a button, there is no turning back, the button is pushed. Whether it reacts on push down or release is not relevant, the button has been pressed.

With mouse cursors, it is different. When the mouse button is pushed down, you still have the liberty to move your cursor, in order to hit another target that you may have missed when pushing down.

From what I have tested, Windows or Mac OS use form controls (buttons, check boxes) that reacts to mouse down but only to display the actual action that will be taken on mouse up. The user has "plenty of time" to detect that the triggered action is not the one he wants and remove its cursors from the target before releasing the button.


I agree with Roger.

In my mind the Mouse Down event has become analogous with the real-world action of touching/coming into contact with something. So in short, I think mouse-down should always show contact with the element in question.


HTML/JavaScript , with existing text already filled in, shifts the text cursor upon mousedown, not on click, and not on mouseup. This is necessary because you could be selecting a range of text, an area, by wiping across it and then releasing the mouse.

There's a fundamental conflict between mousedown to wipe an area to select it, and mousedown to drag an object.

In any case, mousedown should use visual and possibly auditory / tactile feedback.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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