I don't think this is as much of an edge case as John thinks. I've
run into it as well. Another way around it is to set the .live events
outside of the document load listener in the head. That way, it runs
before the selector returns any results.
I can see why it was placed where it is, so you can chain it like
other jQuery methods.
$(foo).live('click', function() {}).css();
If it was
$.live($(foo), 'click', function() {});
Then it could not be chained. But in practice, I never chain .live()
events because for performance reasons I put them outside of the
document load listener so they cannot chain because the DOM isn't
ready anyway.
Often the reason I use .live is because I am setting a click event on
a hundred or so td's in a dynamic table. Using .click is
prohibitively slow, because they all must be removed before removing
the table from the DOM and just setting that many events is slow as
well.
It's true, I could write a custom event delegate script to constrain
the scope to the table and capture events as they bubble up, but it
seems to me that the point of .live is to encapsulate this exact kind
of functionality so I don't need to write this pattern out every time.
Anyway, I'm fine if it doesn't get added to the core, I've got custom
plugins written for $.live and I use the custom event delegation
pattern that John mentions, but it makes the core $().live a lot less
useful. The only benefits it provides is being able to chain it
(Which I don't really need) and it lets me use an already cached
selector (though I could still do that in the $.live() method).
Just some thoughts on how this pattern is used in the wild.
Josh Powell
--
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=.
