4 ms·

> Why are you filtering for screen coordinates in the first place? FTA: > The isInvokedByMouse was checking whether the click event was invoked by a mouse or

> Why are you filtering for screen coordinates in the first place? FTA: > The isInvokedByMouse was checking whether the click event was invoked by a mouse or touch pointer – rather than a keyboard – by checking if the screenX or screenY coordinates were a positive number. They were trying to detect whether it was keyboard or mouse activation, and whoever wrote it assumed that screen coordinates of mouse events would always be positive.

nightpool 2y ago
Right, but the article doesn't explain why they cared whether it was keyboard or mouse activation. The linked WebKit bug goes into more detail, but it's still lacking an explanation of why alternative, more common and widely deployed strategies (like having a capturing keyup event that triggers earlier in the render loop) wouldn't be a better idea instead. Also, if you really want to determine whether a MouseEvent is "real" or "synthetic", and you don't want to worry about when mouse events are triggered relative to keyboard events in the event loop (although it doesn't seem very hard to keep track of), it seems like you can use the current click count (i.e., event.detail). This works on both Chrome and Safari—it's 1 for mouse clicks, and 0 for keyboard "clicks", but the spec text is also a little contradictory and under-specified: the "click" event handler says that "the attribute value MUST be 1 when the user begins this action and increments by 1 for each click" (https://w3c.github.io/uievents/#event-type-click https://w3c.github.io/uievents/#event-type-click) but it also says "This MUST be a non-negative integer indicating the number of consecutive clicks of a pointing device button within a specific time" (https://w3c.github.io/uievents/#current-click-count https://w3c.github.io/uievents/#current-click-count), and the definition of "pointing device button" seems to exclude synthetic keyboard events (since those are handled separately)
echoangle 2y ago
> They were trying to detect whether it was keyboard or mouse activation But the code shown doesn't do different stuff for Keyboard vs Mouse, it just checks if it is either one of them. Why would you do that? Which other click event types are there that you want to filter?
- joshtumath 2y ago
  I omitted that code to keep the article simpler. We want to turn off the animation on keyboard, and move the focus to different things depending on if it's a keyboard or pointer user.
Aaargh20318 2y ago
They are breaking Curly’s Law here (https://blog.codinghorror.com/curlys-law-do-one-thing/ https://blog.codinghorror.com/curlys-law-do-one-thing/), the screenX/Y location mean one thing: the location of the mouse event on screen. Using it for anything else is a huge red flag.

nightpool 2y ago

Right, but the article doesn't explain why they cared whether it was keyboard or mouse activation. The linked WebKit bug goes into more detail, but it's still lacking an explanation of why alternative, more common and widely deployed strategies (like having a capturing keyup event that triggers earlier in the render loop) wouldn't be a better idea instead. Also, if you really want to determine whether a MouseEvent is "real" or "synthetic", and you don't want to worry about when mouse events are triggered relative to keyboard events in the event loop (although it doesn't seem very hard to keep track of), it seems like you can use the current click count (i.e., event.detail). This works on both Chrome and Safari—it's 1 for mouse clicks, and 0 for keyboard "clicks", but the spec text is also a little contradictory and under-specified: the "click" event handler says that "the attribute value MUST be 1 when the user begins this action and increments by 1 for each click" (https://w3c.github.io/uievents/#event-type-click https://w3c.github.io/uievents/#event-type-click) but it also says "This MUST be a non-negative integer indicating the number of consecutive clicks of a pointing device button within a specific time" (https://w3c.github.io/uievents/#current-click-count https://w3c.github.io/uievents/#current-click-count), and the definition of "pointing device button" seems to exclude synthetic keyboard events (since those are handled separately)

echoangle 2y ago

> They were trying to detect whether it was keyboard or mouse activation But the code shown doesn't do different stuff for Keyboard vs Mouse, it just checks if it is either one of them. Why would you do that? Which other click event types are there that you want to filter?

joshtumath 2y ago
I omitted that code to keep the article simpler. We want to turn off the animation on keyboard, and move the focus to different things depending on if it's a keyboard or pointer user.

Aaargh20318 2y ago

They are breaking Curly’s Law here (https://blog.codinghorror.com/curlys-law-do-one-thing/ https://blog.codinghorror.com/curlys-law-do-one-thing/), the screenX/Y location mean one thing: the location of the mouse event on screen. Using it for anything else is a huge red flag.