There has been long-standing confusion regarding this big question: “How to get mouse coordinates on a page with the mousemove event?”
My googling lead me to this page that says that its impossible to do this. But this did not satiate my itch, so I did some of my own digging (or scratching, if you please ).
I conclude that while this question has no all-pleasing answer, the task is quite doable (though in a useless scientific-theory kind of way).
This post addresses this question in detail. And I’ll take this step by step.
The mouseover event
This event is supposed to be generated whenever the mouse is moved in the “client area” – the white area where the page is rendered.
This event has 6 sets of properties (in all browser taken together):
- clientX, clientY
- layerX, layerY
- offsetX, pageY
- pageX, pageY
- X, Y
- screenX, screenY
Now, thats the easy part. The major PITA is that not all browsers support all these properties. And, if two browsers support the same property, they don’t implement them the same way!
The only exception to this confusion is the screenX/Y pair: they are available consistently across all browsers, and all do the same thing – get the coordinates with respect to the top left corner of you screen. But then, this value doesn’t really have much use, does it?
And here’s how the rest of the properties behave cross-browser:
1. Firefox – both 2 and 3
- offsetX/Y and X/Y pair are undefined. So if you try to read them, you will get “undefined”. No, not even null. Plain undefined.
- clientX/Y, pageX/Y and layerX/Y all get us the coordinates of the mouse with respect to the top-left corner of the client area, regardless of the padding of ‘body’.
So whatever be the padding of your page’s body, you’ll always get the same values, no matter what.
This is kind of standard across browsers too, except that different properties return this value.
- Now then, there’s the quirk: FF2 does something strange with layerX/Y: it is not equal to pageX/Y and clientX/Y – instead they it is always (1+clientX)/(1+clientY) – God knows why! This is probably because it does not count the border of the client area. But again, defining the client area’s border is like fighting foo.
2. Konquerer 3.5
It is this browser’s implementation that has appealed to me the most.
- All the properties are defined. clientX/Y, pageX/Y, layerX/Y and X/Y all mean the same thing - the coordinate w.r.t the top-left corner of the client area.
- offsetX/Y gives the coordinate of the mouse inside the current element, where current element is the element over which your mouse is hovering.
- A point to note is that offsetX/Y gives the coordinate from the outer edge of the border(in case of more-than-1px-wide border) of the element – so margin is not counted, and the padding is considered as part of the element.
3. Opera 9
- Here, layerX/Y is undefined.
- clientX/Y, pageX/Y and X/Y are the same as that in Firefox and Konqueror.
- But offsetX/Y is a different story. It behaves like in Konqueror, but it returns the coordinate w.r.t the top-left corner where the padding ends!
- Further, the padding region and border region are part of the “current element”, but when your mouse is in, like, the left padding region, the layerX is negative. Baaaad!
- However, this behaviour is not repeated with the layerX/Y etc for the body – in the case of body, padding’s just as much a part of the client area as is the content.
4. Google Chrome
This browser, thankfully, adopts the konqueror standards. Perhaps that’s because the google guys liked that model too. (That says something about me, doesn’t it? )
But there still is one small difference — and I’ve saved that for the last! Noooo… don’t rush down to the end just now!
5. IE 7 and 6
- Here, layerX/Y and pageX/Y are undefined.
- clientX/Y and X/Y are the coordinates w.r.t the client area’s t-l corner (yeah, no padding).
- But then, there’s a glitch (again). In IE, the mousemove event is generated very slowly – only when your mouse crosses an element’s boundary, or you are shaking the mouse rather too vigourously. Perhaps this was intended to be some kind of performance bonus, it is headache for us devs.
- And, offsetX/Y behaves like in Konqueror, but the event is generated too slowly to really tell whether the padding is being included in the coordinates or not. IE’s weird as ever. Microsoft. Bleah!
I got the same result with IE 5.5 and IE 5, but the testing was not as thorough. Who cares, anyway.
BTW, I did my IE testing on both Windows machines, as well as my dear Ubuntu. I used ies4linux, of course.
In all, here are a few things to note:
- screenX/Y and clientX/Y work in all the above browsers.
- Firefox does not support offsetX/Y.
- All the rest support offsetX/Y, except that Opera pulls in all the padding shaggywag.
- IE has a very lousy “refresh-rate”. Hopeless, really.
Now for the final piece-o-cake:
Q: What happens when you drag your mouse out of the client area?
A: One would expect that mouse tracking should stop, and it does. But, Opera and Konqueror do one additional thing – they track the first point that lands outside the client area. This means that after tracking has stopped, one of the values in the clientX/Y pair (or X/Y or pageX/Y etc) may be negative! So watch out! But again, google chrome does not do this stunt – it does not track any point outside the client area. Nor do Firefox and IE.
So I guess this info is for just alpha geeks who want such info just for the sake of it. But it satisfies my itch quite perfectly.
So then, Thank you. ¡Hasta luego! (bows and exits)