3 ms·

The mouse event thing is a bit misleading. Mouse interactions have (at least) 5 different events: hover, down, up, click and double click. The interactions you

The mouse event thing is a bit misleading. Mouse interactions have (at least) 5 different events: hover, down, up, click and double click. The interactions you describe all happen “onclick”, which requires a down and up event to happen consecutively. I get your point, that small delays add up, but mouse events aren’t a great example, IMO. Each of the events have a purpose and you want to make sure that a button is only activated with an onclick, not just an ondown.

ssl-3 2y ago
I appreciate the clarity in nomenclature. > Each of the events have a purpose and you want to make sure that a button is only activated with an onclick, not just an ondown. That's stated as if it is a rule, but why is that a rule? And if if is a rule, then why does Chrome -- for example -- handle this inconsistently? Clicking on a different Chrome tab sure seems to happen with ondown, but clicking on the "reply" button below the text box I'm typing into works with onclick.
- mixmastamyk 2y ago
  I occasionally click a button only to change my mind mid-click. So I can move the mouse pointer off it and then let go of the button, in effect avoiding the operation. This ability to back out is a good for command-like events. Changing tabs not so much perhaps but probably traditionally done for consistency. X window was the odd one out in the old days that would show a context menu on mouse down. Made it feel a bit unrefined.
- rawling 2y ago
  Doesn't Windows do the same when clicking a window titlebar? Maybe it's so if you're going to start dragging the window/tab you can see what is in it.
  - ssl-3 2y ago
    Clicking anywhere in a background window (including the titlebar) in Windows 10 responds by immediately raising and focusing the clicked-on window when the mouse button is first pushed down. The inconsistency is bizarre, since some here say that clicking-and-releasing before a resultant thing is allowed to happen is a hard-and-fast rule of GUI implementation that has been in place for decades, but that just doesn't seem to be the case at all.
    - mbreese 2y ago
      There are no hard and fast rules, only conventions that are context dependent. Buttons normally only respond to the “on click” event. This lets you move off the button if you change your mind mid-click. Window focus could be (I haven’t tested) an “on down” event because you might want to see what’s behind it while doing something else before you release the button (like drag it around). But focus used to be “on hover”, where just moving your mouse over a window brought it to the foreground. “On up” wouldn’t make sense because if you wanted to do something like move the window around, you couldn’t as you’ve now released the mouse. It all depends on what you’re trying to do and the OS. Each OS has a design language that “tries” to bring some consistency to event handling. But ultimately, it’s up to the application to handle many things.

ssl-3 2y ago

I appreciate the clarity in nomenclature. > Each of the events have a purpose and you want to make sure that a button is only activated with an onclick, not just an ondown. That's stated as if it is a rule, but why is that a rule? And if if is a rule, then why does Chrome -- for example -- handle this inconsistently? Clicking on a different Chrome tab sure seems to happen with ondown, but clicking on the "reply" button below the text box I'm typing into works with onclick.

mixmastamyk 2y ago
I occasionally click a button only to change my mind mid-click. So I can move the mouse pointer off it and then let go of the button, in effect avoiding the operation. This ability to back out is a good for command-like events. Changing tabs not so much perhaps but probably traditionally done for consistency. X window was the odd one out in the old days that would show a context menu on mouse down. Made it feel a bit unrefined.
rawling 2y ago
Doesn't Windows do the same when clicking a window titlebar? Maybe it's so if you're going to start dragging the window/tab you can see what is in it.
- ssl-3 2y ago
  Clicking anywhere in a background window (including the titlebar) in Windows 10 responds by immediately raising and focusing the clicked-on window when the mouse button is first pushed down. The inconsistency is bizarre, since some here say that clicking-and-releasing before a resultant thing is allowed to happen is a hard-and-fast rule of GUI implementation that has been in place for decades, but that just doesn't seem to be the case at all.
  - mbreese 2y ago
    There are no hard and fast rules, only conventions that are context dependent. Buttons normally only respond to the “on click” event. This lets you move off the button if you change your mind mid-click. Window focus could be (I haven’t tested) an “on down” event because you might want to see what’s behind it while doing something else before you release the button (like drag it around). But focus used to be “on hover”, where just moving your mouse over a window brought it to the foreground. “On up” wouldn’t make sense because if you wanted to do something like move the window around, you couldn’t as you’ve now released the mouse. It all depends on what you’re trying to do and the OS. Each OS has a design language that “tries” to bring some consistency to event handling. But ultimately, it’s up to the application to handle many things.