I've noticed that most browsers now appear to use offsetParent as something
further up than their immediate parentNode. This is what cumulativeOffset
uses to calculate real position on the page.
There is a case where this doesn't work (and I noticed it while using
MochiKig.DragAndDrop). If you have a Draggable inside a div with
overflow:scroll (or auto) and it's scrolled down a bit, then the browsers
don't compensate with their offsetParent, or the offset coordinates.
Below is a patch that fixed this up for me. It feels a bit like a hack
(mostly because it's working around the browsers outright lying about where
elements actually _are_).
Can anyone see a better way of dealing with this?, and what are the chances
we could include this patch in upstream MochiKit.Position?
Index: MochiKit/Position.js
===================================================================
--- MochiKit/Position.js (revision 1233)
+++ MochiKit/Position.js (working copy)
@@ -72,9 +72,20 @@
cumulativeOffset: function (element) {
var valueT = 0;
var valueL = 0;
+ var realParent = false;
do {
+ if (realParent) {
+ while (realParent != element) {
+ valueT -= realParent.scrollTop || 0;
+ valueL -= realParent.scrollLeft || 0;
+ realParent = realParent.parentNode;
+ }
+ }
+
valueT += element.offsetTop || 0;
valueL += element.offsetLeft || 0;
+
+ realParent = element.parentNode;
element = element.offsetParent;
} while (element);
return new MochiKit.Style.Coordinates(valueL, valueT);
--
Martyn
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"MochiKit" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---