This may seem close-minded, but I tend to think the need to delete a node from the DOM and hold onto that exact node the way it was when it left the DOM in the event that exact node needs to be re-inserted is kind of a specific implementation that shouldn't be handled natively by .remove(). I've always thought of .remove() as a means of destroying the element outright.
What's the use case for holding onto a DOM element for later? If I was going to try to hold onto the data and events, I would probably try to access everything in $.cache for the element before removing it, store it in some storage obj so that you can easily access the stored info it needs to be attached to the element again. --adam On Jan 29, 6:28 pm, Már Örlygsson <[email protected]> wrote: > > var foo = $('#foo').clone(true); > > $('#foo').remove(); > > foo.appendTo('somewhere else later') > > Kludgy, inefficient, and ineffective (if there are references to the > original element elsewhere). > > However, I guess another way around would be to use a storage node/ > fragment and append the removed elements to it - like so: > > var offlineStore = $('<div />'); > $(elementsToRemove).appendTo( offlineStore ); > > Although "understandable" or "elegant" are hardly words that spring to > mind. :) > > My initial guess was that there had to be an optional boolean argument > for `.remove()` to indicate when events and data shouldn't be stripped > away. > To my surprise, there wasn't. > > -- > Már Örlygsson --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jQuery Development" 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/jquery-dev?hl=en -~----------~----~----~----~------~----~------~--~---
