This sounds reasonable. Can you make an enhancement ticket so it doesn't get
lost on the list?
--
Brandon Aaron
On Tue, Jan 27, 2009 at 2:02 AM, Jed Schmidt <t...@nslator.jp> wrote:
>
> John,
>
> Thinking about it again, would it make sense to decouple DOM removal
> from element death? This could help you speed up not only
> $.fn.replaceWith, but also $.fn.empty and everything that uses it
> (including $.fn.html and $.fn.text), with something like this:
>
> function kill() {
> jQuery.event.remove( this );
> jQuery.removeData( this );
> };
>
> jQuery.each({
> remove: function( selector ) {
> if ( !selector || jQuery.filter( selector, [ this ] ).length ) {
> jQuery( "*", this ).add([this]).each( kill );
> if (this.parentNode)
> this.parentNode.removeChild( this );
> }
> },
>
> empty: function() {
> jQuery( ">*", this ).each( kill );
> this.innerHTML = ""; // or whatever is fastest
> }
> }, function(name, fn){
> jQuery.fn[ name ] = function(){
> return this.each( fn, arguments );
> };
> });
>
> $.fn.extend({
> replaceWith: function() {
> this.find( "*" ).add([this]).each( kill );
> return this.domManip(arguments, false, function(elem){
> this.parentNode.replaceChild( elem, this );
> })
> }
> });
>
> Jed
>
> On Jan 19, 5:09 pm, Jed Schmidt <t...@nslator.jp> wrote:
> > Ah, I suspected there might be something like that.
> >
> > 1.3 is great, keep up the good work!
> >
> > Jed
> >
> > On Jan 19, 5:02 pm, John Resig <jere...@gmail.com> wrote:
> >
> > > I like it - but the one tricky part is that .remove() is actually
> > > functional beyond the simple .removeChild() call - it also removes any
> > > bound event handlers and bound data from the elements (which is
> > > something that this modified replaceWith would not do). That
> > > functionality would need to stay intact (this is the same reason why
> > > we do .empty().append() in .html() instead of using a straight
> > > innerHTML).
> >
> > > --John
> >
> > > On Mon, Jan 19, 2009 at 7:49 PM, Jed Schmidt <t...@nslator.jp> wrote:
> >
> > > > Hey all,
> >
> > > > Looking at the new source code for 1.3, I was wondering why jQuery
> > > > doesn't take advantage of the native replaceChild method in the W3C
> > > > core. Currently, jQuery implements replaceWith using append and
> > > > remove, but since replaceChild is well supported[1] across browsers,
> > > > it seems like a safe place to optimize performance, since it reduces
> > > > two in-place DOM operations with one.
> >
> > > > So I replaced this on line 487 in 1.3:
> >
> > > > replaceWith: function( value ) {
> > > > return this.after( value ).remove();
> > > > },
> >
> > > > with this:
> >
> > > > replaceWith: function() {
> > > > return this.domManip(arguments, false, function(elem){
> > > > this.parentNode.replaceChild( elem, this );
> > > > });
> > > > },
> >
> > > > and put together a before[2] and after[3] page.
> >
> > > > On OS 10.5.6, Firefox 3.0.5 went from an average of 1239ms to 935ms,
> > > > and Safari 3.2.1 went from an average of 421ms to 331ms.
> >
> > > > What do you guys think?
> >
> > > > Jed Schmidt
> >
> > > > [1]http://www.quirksmode.org/dom/w3c_core.html
> > > > [2]http://s3.amazonaws.com/replacewith/before.html
> > > > [3]http://s3.amazonaws.com/replacewith/after.html
> >
> >
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@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
-~----------~----~----~----~------~----~------~--~---
