John, thanks for the explanation. I see the problem now. How about
building an array of the new elements as we duplicate them, and then
return that?
jQuery.fn.removeAll = function() {
var ret = [];
this.each(function() {
var newEl = this.cloneNode(false);
Devon -
Let me explain this in a different way: You're creating a duplicate
copy of the element, one which isn't tied to anything.
Another way to illustrate it:
var divs = $("div");
// .length == 10
divs.eq(0).children().length
// 3
var empty = $("div").empty();
// .length == 10
empty.eq(0).c
Karl, yes but this is about empty not remove, which means that the
parent of the removed elements is returned not the children
themselves. For example:
$("div.foo").empty() //returns div.foo not the children of div.foo
The element that we call empty on is not removed from the document so
returni
Ah, yes .. of course there is detach() already in 1.4. I remember it
now from a "roadmap" ...
And a "new" remove( selector, keepData ).
But. I am thinking on a more conceptual level. Not just on the API
level. jQuery is in essence a visitor/handler/mediator between a
persistent storage (dom tree)
Devon, some people like to remove elements and have the option of
adding some or all of them back into the DOM at a later time.
DBJDBJ, this is just FYI since you already retracted your suggestion
to add a .detach() method, but jQuery 1.4a already has a .detach()
method. It removes elements
@John I would like to ask the same thing DBJDBJ did. Why would you
want to find the index of an element that no longer exists? This just
seems unintuitive. You shouldn't be able to find the index of
something not in the document. The two sets of elements did refer to
the same thing, but no they
Actually maybe new method is not needed. Instead maybe new argument to
"remove()" will
bring an end (and clarity) to the removal saga ?
var orphanage = document.createElement("div");
$("div.foo").remove( orphanage ) ;
If orphanage is provided, removed elements (aka "orphans") will be
added to it.
Maybe having a method "detach" would bring some clarity?
The removed child node still exists in memory, but is no longer part
of the DOM.
var orphan = this.removeChild(this.firstChild)
Above "orphan " is indeed not a part of the document. Why is this a
problem?
Why would I go back to the documen
A major problem with your technique is that the original elements are
simply no longer part of the document.
For example:
var someElems = $("div");
// length == 10
var removed = $("div.foo").remove();
// length == 5
someElems.index( removed )
// -1 (the elements you just removed aren't found!)
I did some performance testing with the following code, and found it
to be much slower than the cloneNode method, but still often twice as
fast as the current method.
jQuery.fn.removeAll = function() {
this.each(function() {
var nextSibling = this.nextSibling;
Yeah I tried that too, and it was slightly slower in most browsers
than cloneNode. The other issue with this, is that if the user has a
slow computer, or the removal is taking a really long time, layout
problems may occur since there is no element in the DOM during the
emptying. The cloneNode met
hi,
I didn´t see that you clean up events/dom-expandos to prevent memory
leaks. how fast is your method if you invoke the cleanData-function
beofre replacing the parentElement?
regards
alex
On 13 Dez., 14:19, Devon Govett wrote:
> Hi all,
>
> I've just blogged about a technique that I used to m
12 matches
Mail list logo
