This page describes a drag-‘n’-drop algorithm.
Looking only at the first snippet of code (which the article continually improves upon), it says it’s important we use document in document.addEventListener('mousemove', onMouseMove);.
Is this because if we were to use ball, there’s a chance we might move the cursor so fast the cursor might leave the box-model of the ball before mousemove would have a chance to execute again? We wouldn’t be moving the mouse over ball so mousemove wouldn’t re-fire.
Advertisement
Answer
Is this because if we were to use ball, there’s a chance we might move the cursor so fast the cursor might leave the box-model of the ball before mousemove would have a chance to execute again?
Yes.
This will happen if you drag an object upwards when your drag-point is also the top row of pixels of the object.
This is less likely to happen if you drag a larger object from its centre and your computer has a mouse with a high poll-rate and a high display refresh rate and the browser is capable of processing OS-provided input events rapidly – so if you’re a front-end dev using a high-end gaming machine (with a 1000Hz USB mouse and a 120Hz+ display) may not notice the problem compared to someone using a 100Hz mouse on a 30Hz display (which is a thing: many people run 4K displays over HDMI 1.x which can only run 4K at 30Hz).
Another scenario is when the user is using an absolute pointing device, such as a touch-screen or graphics tablet in absolute-mode (aka “pen mode” for Wacom) rather than relative-mode (aka “mouse mode” for Wacom) – if the user “drags” an object to somewhere else on the screen by only tapping the destination location with their finger (or by moving the stylus vertically outside the detection zone) then there will only be 1 mousemove event which will not be captured by ball at all.