←back to thread

293 points ulrischa | 5 comments | | HN request time: 0.636s | source
Show context
nightpool ◴[] No.42174146[source]
Why are you filtering for screen coordinates in the first place? What if the user is using e.g. an alternative input device that doesn't have a screen? The `click` event should be enough indication that the user has tried to activate the menu. Why reinvent the wheel?
replies(1): >>42174263 #
1. codetrotter ◴[] No.42174263[source]
> 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.

replies(3): >>42174434 #>>42174460 #>>42177879 #
2. nightpool ◴[] No.42174434[source]
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) 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), and the definition of "pointing device button" seems to exclude synthetic keyboard events (since those are handled separately)

3. echoangle ◴[] No.42174460[source]
> 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?

replies(1): >>42175205 #
4. joshtumath ◴[] No.42175205[source]
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.
5. Aaargh20318 ◴[] No.42177879[source]
They are breaking Curly’s Law here (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.