Update: I submitted this to MochiKit while building Snipshot, a web tool to edit pictures online.

I discovered that IE’s clientX and clientY measurements were sometimes a couple pixels out. It turns out this is because IE’s clientX and clientY measurements start from (2,2) in standards mode, and (0,0) in quirks mode.

IE stores this offset in its document.documentElement.clientLeft and document.documentElement.clientTop properties. This code should calculate the correct cursor position in all current browsers:

function getPosition(e) {
    e = e || window.event;
    var cursor = {x:0, y:0};
    if (e.pageX || e.pageY) {
        cursor.x = e.pageX;
        cursor.y = e.pageY;
    } 
    else {
        var de = document.documentElement;
        var b = document.body;
        cursor.x = e.clientX + 
            (de.scrollLeft || b.scrollLeft) - (de.clientLeft || 0);
        cursor.y = e.clientY + 
            (de.scrollTop || b.scrollTop) - (de.clientTop || 0);
    }
    return cursor;
}

To find out exactly how browsers were interpreting offsetLeft and offsetTop, I built a test page that would tell me I added a 1px margin, 2px border, 4px padding, 8px position, 16px margin, and so on and then used bitwise AND to figure out which parts were being included in the total calculation. what parts of the style calculation were included.

It’s a mess. Firefox and Opera do the calculation in the same way, while Safari and IE each have unique interpretations. IE has the only obvious bug, where the top padding of an element is not included in one calculation, while the left padding is.

The only thing that appears to work consistently is finding an element’s absolute position on a page—as long as no elements have any borders, margins, or padding.

It is possible to get the browsers a little closer to the correct answer if you include the IE-specific clientTop and clientLeft properties. Here’s a test page to demonstrates this. In this case, Safari, IE, and Opera agree on the absolute x coordinate, IE still won’t include y padding, and Firefox is on its own.

I think this comment sums up the problem nicely:

“The problem to begin with, the origin of the problem is that MSDN does not define strictly, explicitly how offsetLeft/offsetTop should be computed in normal situations and in various other situations. Even offsetParent is not defined clearly: there is no precise spec. - formal rigorous spec - identifying how the offsetParent can be, should be determined. offsetLeft, offsetTop definitions are circularly dependent, self-inter-dependent to offsetParent definition.

Add to this quirks mode vs standards rendering mode, and other properties (padding, border, margin, box-sizing) which interfere or affect too calculations of offsetLeft, offsetTop or which may influence too the way offsetParent is to be defined and then you have a real mess, headache, impossible task.”

I’m trying to help out the MochiKit and Dojo projects by writing an event normalizer. I’m tired of writing or finding one-off functions to solve this problem, and want something that will return accurate cursor and element coordinates.

I built a test page to collect seven browsers’ interpretations of a set of event properties. The only event property I normalized was event.target, I left everything else alone. The proxy.* values are calculated based on some assumptions I had about how the browsers interpreted the target’s position (proxy.pos), the cursor position relative to the document (proxy.page), the cursor position relative to the target (proxy.targetOffset), and the cursor position relative to the target’s positioning context (proxy.contextOffset). I used Pixie (Mac) and ZoomPlusU (PC) to position the cursor on every test.

My code still needs some work.

Note that Firefox 1.5 (Gecko 2005-11-11) introduced an off-by-one bug to the event.layerX and event.layerY properties. It’s been fixed in the latest nightly builds.

Also note that IE’s clientX and clientY properties are off by two pixels. From MSDN: “In Microsoft Internet Explorer 5, the window's upper-left is at 2,2 (pixels) with respect to the true client.” The proxy.page.x/y and .targetOffset.x/y variables seem to be relatively consistent up until test point five, when I measure point (1,1) in the document's first absolutely positioned element.

A lot of libraries do something like:

event.layerX = event.layerX || event.offsetX

This is incorrect, layerX and offsetX are not equivalent.

Here is the test page. (Hold down the alt key and click on any part of the page to get a variable dump.) I did nine manual tests at different points in the document, starting from the top left corner of the document. I’ve included Pixie screenshots to show where I’m taking my sample.

There is still a lot of work to do, and I would really appreciate your feedback on what I’ve got so far. You can reach me at beau@hartshorne.ca.

One

Two

Three

Four

Five

Six

Seven

Eight

Nine