Scrolling is also "nonsmooth" in FF, etc., if you scroll fast enough.
I just have the feeling that it will not be worth what you might need:
- load, get the position of each anchor and determine its area
- collect all possible coordinates in an array of objects (index)
{ id: 'my-anchor-1', x: 100, y: 100 }
- onmousemove, check your coordinates on your array (i.e. check each coordinate between the old mouse position and the new mouse position, as other commentators have already noted).
This way you do most of the calculations and select the DOM in front and make it much easier for the mousemove event. This can become messy if the content added to the page later shifts the bindings around: you have to recount the array, but this happens less often with respect to mousemove, and if everything you do is added, you can simply add to it.
Solving the problem of resizing, etc. It really depends on who your audience is and how many anchors you think you will have in the worst case. Since this is mousemove, we are talking about desktops / laptops where window resizing would be very rare, especially with respect to mousemove events.
If you have only a few anchors, and you think that there will be many changes, then creating an index will not make much sense, and you can do the calculation in the event itself (but at least the cache is the choice of the DOM). But if you think that you will have a ton of anchors, especially if they are unlikely to change much, I think that indexing them makes a lot of sense to increase productivity.
source share