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).children().length
// 0

divs.eq(0).children().length
// 3

It's not actually emptying out the right elements - you have this
quantum state where you have "the same" elements and they're both
empty and full.

--John



On Tue, Dec 15, 2009 at 4:04 PM, Devon Govett <devongov...@gmail.com> wrote:
> 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
> returning it shouldn't be an issue.  It would be an issue for the
> remove function, which directly removes the element that you call it
> on.
>
> Devon
>
> On Dec 15, 8:37 am, Karl Swedberg <k...@englishrules.com> wrote:
>> 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 from the DOM without removing their events
>> or data.
>>
>> --Karl
>>
>> On Dec 15, 2009, at 7:33 AM, Devon Govett wrote:
>>
>>
>>
>> > @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 don't because you removed the elements.
>> > This makes sense to me.  As far as I know, no matter how you remove
>> > elements they are not part of the document any more.  Isn't that the
>> > point of removing them?
>>
>> > Devon
>>
>> > On Dec 14, 11:48 pm, John Resig <jere...@gmail.com> wrote:
>> >> 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!)
>>
>> >> This creates a problem: You now have two sets of elements that sort
>> >> of
>> >> refer to the same thing but actually aren't the same.
>>
>> >> --John
>>
>> >> On Mon, Dec 14, 2009 at 11:35 PM, Devon Govett
>> >> <devongov...@gmail.com> wrote:
>> >>> 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;
>> >>>                var parent = this.parentNode;
>>
>> >>>                parent.removeChild(this);
>> >>>                while (this.firstChild) {
>> >>>                        this.removeChild(this.firstChild);
>> >>>                }
>> >>>                if(nextSibling)
>> >>>                        parent.insertBefore(this, nextSibling)
>> >>>                else
>> >>>                        parent.appendChild(this);
>> >>>        });
>> >>> };
>>
>> >>> What are the problems with the cloneNode method?
>>
>> >>> Devon
>>
>> >>> On Dec 13, 5:36 pm, Devon Govett <devongov...@gmail.com> wrote:
>> >>>> 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 method has the advantage that during the
>> >>>> emptying process nothing is removed from the screen and so things
>> >>>> don't look weird.  I know this is an edge case, but it is
>> >>>> something to
>> >>>> consider.
>>
>> >>>> Devon
>>
>> >>>> On Dec 13, 10:46 am, John Resig <jere...@gmail.com> wrote:
>>
>> >>>>> Actually, now that you bring this up, it would make a lot of
>> >>>>> sense to
>> >>>>> just remove the element from the DOM first and /then/ go through
>> >>>>> and
>> >>>>> clean up the child nodes, and finally re-inject the element
>> >>>>> again. I'm
>> >>>>> hesitant to do a cloneNode because of the inherent problems that
>> >>>>> exist
>> >>>>> in Internet Explorer. I'll see if I have some time to do some perf
>> >>>>> testing on this later today.
>>
>> >>>>> --John
>>
>> >>>>> On Sun, Dec 13, 2009 at 8:19 AM, Devon Govett
>> >>>>> <devongov...@gmail.com> wrote:
>> >>>>>> Hi all,
>>
>> >>>>>> I've just blogged about a technique that I used to make
>> >>>>>> jQuery.empty
>> >>>>>> over 10x faster in some cases.  Basically, rather than
>> >>>>>> individually
>> >>>>>> removing each child element from the DOM which causes the
>> >>>>>> browser to
>> >>>>>> reflow after each one, I use a shallow cloneNode to do the job
>> >>>>>> then
>> >>>>>> copying events back over.  Check out the blog post for more
>> >>>>>> details:
>> >>>>>>http://devongovett.wordpress.com/2009/12/12/how-to-make-jquery-empty-
>> >>>>>> ....
>> >>>>>> I've included some charts comparing the performance of jQuery
>> >>>>>> 1.4's
>> >>>>>> empty and html("") functions, as well as the function I've
>> >>>>>> written,
>> >>>>>> and the cloneNode method out performs all other methods by a
>> >>>>>> significant amount in all browsers.
>>
>> >>>>>> Thanks for jQuery!
>> >>>>>> Devon
>>
>> >>>>>> --
>>
>> >>>>>> You received this message because you are subscribed to the
>> >>>>>> Google Groups "jQuery Development" group.
>> >>>>>> To post to this group, send email to jquery-...@googlegroups.com.
>> >>>>>> To unsubscribe from this group, send email to 
>> >>>>>> jquery-dev+unsubscr...@googlegroups.com
>> >>>>>> .
>> >>>>>> For more options, visit this group 
>> >>>>>> athttp://groups.google.com/group/jquery-dev?hl=en
>> >>>>>> .
>>
>> >>> --
>>
>> >>> You received this message because you are subscribed to the Google
>> >>> Groups "jQuery Development" group.
>> >>> To post to this group, send email to jquery-...@googlegroups.com.
>> >>> To unsubscribe from this group, send email to 
>> >>> jquery-dev+unsubscr...@googlegroups.com
>> >>> .
>> >>> For more options, visit this group 
>> >>> athttp://groups.google.com/group/jquery-dev?hl=en
>> >>> .
>>
>> > --
>>
>> > You received this message because you are subscribed to the Google
>> > Groups "jQuery Development" group.
>> > To post to this group, send email to jquery-...@googlegroups.com.
>> > To unsubscribe from this group, send email to 
>> > jquery-dev+unsubscr...@googlegroups.com
>> > .
>> > For more options, visit this group 
>> > athttp://groups.google.com/group/jquery-dev?hl=en
>> > .
>
> --
>
> You received this message because you are subscribed to the Google Groups 
> "jQuery Development" group.
> To post to this group, send email to jquery-...@googlegroups.com.
> To unsubscribe from this group, send email to 
> jquery-dev+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/jquery-dev?hl=en.
>
>
>

--

You received this message because you are subscribed to the Google Groups 
"jQuery Development" group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to 
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/jquery-dev?hl=en.


Reply via email to