Thanks..

$.extend({ handle: function(type, selector, fn) {
    return $.fn.live.apply({ selector:selector }, [type, fn]);
});

This is called as $.handle('click', 'blockquote', function(event) { … }); (read as handle the click event for any blockquote).

I came across your solution when I went to file a feature request (see existing ticket) and now I’m not sure which I prefer :P

Hopefully an officially supported method will materialise in jQuery 1.4.

$.live = function(selector, type, fn)
{
var r = $([]);
r.selector = selector;
if(type && fn) {
r.live(type, fn);
}
return r;
};

allthough it works and it improved performence on my page by reducing the number of calls with 60%.
But is this a preferable way of doing event delegation with jquery?

In my stuff, there isn’t too huge of a performance bottleneck on the callback execution. I’m a bigger stickler for onload performance. :)

I would agree that the “hack” presented above maybe isn’t the most forward thinking approach. Perhaps a hybrid approach with what redsquare presented is in order.


$(document).bind('click', function(event)
{
if($(event.target).is(...)) {
...
}
});


@redsquare

From my perspective, I want the code simplicity of being able to not perform a selector at all to improve both onload performance, and alleviate having to add event handlers later when I add new content using ajax. The live method (in it’s current form) addresses only the latter, not the former.

If I used if($(event.target)), then I’d still have to perform SOME sort of selector to bind the callback to an element, instead of just using the document object.

Maybe I’m being super picky here, but in my tests, the performance difference is large enough to be picky about.

Strictly speaking about the performances, you just scratched the surface of the problem and your cure is not enough (for performances, I repeat).

A “match(element, selector)” method is best suited than a “select(selector, from)” method for a fast event delegation. j

jQuery does not currently implement such a method, it does that by using a standard “select()” then look in the result set and see if the searched element is in there (slow/slow).

The event target should be passed to the “match(element, selector)” method. Only that element should be matched against the “selector”, not all the elements in the document as it currently happens in most implementations.

With event delegation these selection operations have to be repeated continuously for most events while users interact with the pages. You can easily see the selection method itself is the real bottleneck here.