Re: [w3c/pointerlock] MovementX/Y for down and up (#15)

movementX/Y are defined without concern for the locked state, that isn't relevant to these concerns.

The mouse events aren't specified as precisely as they should be, but they are specified sufficiently to ensure that any movement is included in mousemove. What values might mousedown have? Deltas from the previous mousemove event, or the previous mousedown event? For anything the results in mousedown having movementX/Y != 0 applications could easily have logic errors.

Applications wishing to track delta movements should be able to be very simple, and have a handler that reads values of movementX/Y and uses it. If that handler happens to also run on other event types the logic is not brittle thanks to the specification that movementX/Y are only non-zero for mousemove events.

If we'd like clearer specification I would suggest that https://www.w3.org/TR/DOM-Level-3-Events/#events-mouseevent-event-order be clarified to indicate that mousemove events must be dispatched (as ordered in the specification) to account for all movement and that non mousemove events must therefor equal the absolute position of the previous mousemove event. Had that already been the case movementX/Y wouldn't need to have special wording to clarify that point.

Because it wasn't specified, it's unclear what implementations may be doing. But, as I mentioned for the absolute values it doesn't matter much, and for movementX/Y where it does it was specified clearly.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/pointerlock/issues/15#issuecomment-272601284