Hi,
FWIW, I don't think this is should be core. It may be useful in the
scenario in which you're using it, which is great, but I see too many
dangers involved in copying event handlers from one element to
another. I mentioned one of them here.[1]
[1]
http://groups.google.com/group/prototype-scr
I'm not proposing that the Element.clone have this functionality by
default (I agree there are scenarios when you wouldn't want the event
handlers and the storage item(s) copied.) What if Element.clone where
to be given another one or two arguments (ie. Element.clone(deepClone,
cloneStorage, clon
Unfortunately for me, i don't offer much on the deeply technical side,
but want to offer my vote to explore this idea. The self-stop is
definitely an attractive feature, and while the examples that i've
seen in this thread show a stop-on-return-false, it would probably be
more correct to stop-on-p
Hey Robert,
And in the worst case, we throw a $stop object instead. :-) It's just
too good an idea (IMHO), letting us have self-stopping while still
being able to use functions as repeaters that didn't know they were
going to be repeaters... But I'm for continuing to use $break until/
unless it
@tobie: I'm a little unclear how the ES5 implementation of forEach()
impacts the idea of using $break to terminate a repeat() call. Can
you elaborate?
Unless $break is removed from Prototype altogether, I don't see how
this is an issue. And the only reason to remove $break is if all the
Enumera
