That example is broken.
[snip]
Many recent browsers, including Opera, Safari, and Firefox implement
MSIE's element.getBoundingClientRect[1][2] which also included in a w3c
*draft*[3]. getBoundingClientRect is fast and avoids the problems of
differences in offsetTop. offsetTop is a mystery-meat property.
Keep in mind that the CSSOM draft is a *draft*. It has seen significant
changes in offsetTop through the years).
offsetTop is defined by Microsoft using circular logic with the
definition of offsetParent. Looking at MSDN explains why:
offsetTop:
| Retrieves the calculated top position of the object relative to the
| layout or coordinate parent, as specified by the offsetParent
| property.
http://msdn.microsoft.com/en-us/library/ms534303(VS.85).aspx
offsetParent:
| Retrieves a reference to the container object that defines the
| offsetTop and offsetLeft properties of the object.
http://msdn.microsoft.com/en-us/library/ms534302(VS.85).aspx
So we see that offsetTop is taken from the offsetParent, and
offsetParent is the element that defines where offsetTop is taken from.
It's circular logic.
The reader can implement a manual mutual recursion by clicking the links
back and forth. The offsetTop and offsetParent properties are designed
drive a normal human nuts.
Other borwsers copied these properties, but differently. offsetTop and
offsetParent are a mess. You can use them in some cases, but you will
experience differences when measuring in or through TABLE, TD, TR, or
BODY. offsetParent's border width is not generally included in the
offsetTop measurement, so you will need to add in any borders that are
measured through the offsetParent chain.
An older version of CSSOM defined that and that was implemented in Opera
and maybe others (mac IE?).
Dear God no. That site is a shrine to programming by observation.
Yeah, I do see wrong advice on quirksmode when I check it from time to
time. I didn't look in depth at that page, but the findpos.html page is
not a solution that will provide consistent results in other contexts.
It works in only a few cases, and works on that page.
However, some of PPK observations I totally agree with. Like this:
| In my opinion W3C has made some serious mistakes in defining button.
http://www.quirksmode.org/js/events_properties.html#button
The w3c, as usual, went and standardized[4] IE4's event.button[5], but
gave it number values that sort of matched the NS4 "event.which" numbers.
There are several problems with the w3c design:
1) creates a feature that behaves differently an existing IE feature
that already had the same name.
2) does not allow for detecting multiple buttons/combinations
3) does not provide information for no button depressed.
That API is total shit and PPK knows that.
The other problem with that API is that it misfortunately ties "mouse"
to that hardware. The user may be using a writing table or joystick (not
a mouse). The w3c goes as far as using "left" and "right" to define the
way the hardware is designed and configured, while simultaneously
admitting this mistake my mentioning reconfiguration. To say "left"
means "right" is just nonsense, but the w3c provides such provision:
| For mice configured for left handed use in which the button actions
| are reversed the values are instead read from right to left.
Instead, the w3c should have used a new property, say
"event.mouseButton". It should have used terms to describe "default
button", "wheel button", and "context button", and not "left", "middle",
and "right".
</thread-hijack>
[1]
http://msdn.microsoft.com/en-us/library/ms536433(VS.85).aspx
[2]
https://developer.mozilla.org/en/dom/element.getboundingclientrec
[3]
http://www.w3.org/TR/cssom-view/
[4]
http://www.w3.org/TR/DOM-Level-2-Events/events.html
[5]
http://msdn.microsoft.com/en-us/library/ms533544(VS.85).aspx
