Naturally I meant:
getElementPosition(descendant, parent);
... and not the other way around.
/Per
On Mon, Dec 15, 2008 at 12:34 PM, Per Cederberg cederb...@gmail.com wrote:
I think that line was used to do the following:
var parent = $(one);
var descendant = $(two);
Looked a bit deeper into this issue. Seems that the suggested change
to MochiKit.DOM.getElement() would break some tests for Signal and
DOM, since both modules contain code that assume getElement() will
just return whatever non-string object it was provided with.
I've fixed those cases I could
What does this line really intended for?
relativeTo = arguments.callee(relativeTo);
I have removed this line and that error was gone...
- Amit
On Dec 12, 8:08 pm, Per Cederberg cederb...@gmail.com wrote:
Hi,
I ran across a weird bug in MochiKit.Style.getElementPosition causing
FF to throw
Due to a new set of weird rounding errors in JavaScript floating-point
numbers, I opted to fully replace the MochiKit.Format.truncToFixed and
roundToFixed functions with new implementations. This basically
affects all of the other MochiKit.Format functions as well. The new
code pass all the tests
I think that line was used to do the following:
var parent = $(one);
var descendant = $(two);
getElementPosition(parent, descendant);
I.e, we can send another node as the relativeTo value. Not just an
object with x and y properties.
Cheers,
/Per
On Mon, Dec 15, 2008 at 12:17 PM,
Ah, yes... You are probably right. Thanks for the analysis!
It only makes sense for getElement() to return a Node or
null/undefined. Other return values are probably just a side-effect
for the fast-path return for DOM nodes.
But perhaps fixing this will break one or two things, like the
