Before you read this, pull this list of events up in another page, the API itself is tremendously helpful, and all of what I’m discussing below is linked directly from this page.
First, .click(function) is literally a shortcut for .bind('click', function), they are equivalent. Use them when binding a handler directly to an element, like this:
$(document).click(function() {
alert("You clicked somewhere in the page, it bubbled to document");
});
If this element gets replaced or thrown away, this handler won’t be there anymore. Also elements that weren’t there when this code was run to attach the handler (e.g. the selector found it then) won’t get the handler.
.live() and .delegate() are similarly related, .delegate() actually uses .live() internally, they both listen for events to bubble. This works for new and old elements, they bubble events the same way. You use these when your elements may change, e.g. adding new rows, list items, etc. If you don’t have a parent/common ancestor that will stay in the page and not be replaced at any point, use .live(), like this:
$(".clickAlert").live('click', function() {
alert("A click happened");
});
If however you do have a parent element somewhere that isn’t getting replaced (so its event handlers aren’t going bye bye) you should handle it with .delegate(), like this:
$("#commonParent").delegate('.clickAlert', 'click', function() {
alert("A click happened, it was captured at #commonParent and this alert ran");
});
This works almost the same as .live(), but the event bubbles fewer times before being captured and the handlers executed. Another common use of both of these is say your class changes on an element, no longer matching the selector you originally used…with these methods the selector is evaluated at the time of the event, if it matches, the handler runs…so the element no longer matching the selector matters, it won’t execute anymore. With .click() however, the event handler is bound right on the DOM element, the fact that it doesn’t match whatever selector was used to find it is irrelevant…the event is bound and it’s staying until that element is gone, or the handler is removed via .unbind().
Yet another common use for .live() and .delegate() is performance. If you’re dealing with lots of elements, attaching a click handler directly to each element is expensive and time consuming. In these cases it’s more economical to setup a single handler and let bubbling do the work, take a look at this question where it made a huge difference, it’s a good example of the application.
Triggering – for the updated question
There are 2 main event-handler triggering functions available, they fall under the same “Event Handler Attachment” category in the API, these are .trigger() and .triggerHandler(). .trigger('eventName') has some shortcuts built-in for the common events, for example:
$().click(fn); //binds an event handler to the click event
$().click(); //fires all click event handlers for this element, in order bound
You can view a listing including these shortcuts here.
As for the difference, .trigger() triggers the event handler (but not the default action most of the time, e.g. placing the cursor at the right spot in a clicked <textarea>). It causes the event handlers to occur in the order they were bound (as the native event would), fires the native event actions, and bubbles up the DOM.
.triggerHandler() is usually for a different purpose, here you’re just trying to fire the bound handler(s), it doesn’t cause the native event to fire, e.g. submitting a form. It doesn’t bubble up the DOM, and it’s not chainable (it returns whatever the last-bound event handler for that event returns). For example if you wanted to trigger a focus event but not actually focus the object, you just want code you bound with .focus(fn) to run, this would do that, whereas .trigger() would do that as well as actually focus the element and bubble up.
Here is a real world example:
$("form").submit(); //actually calling `.trigger('submit');`
This would run any submit handlers, for example the jQuery validation plugin, then try to submit the <form>. However if you just wanted to validate, since it’s hooked up via a submit event handler, but not submit the <form> afterwards, you could use .triggerHandler('submit'), like this:
$("form").triggerHandler('submit');
The plugin prevents the handler from submitting the form by bombing out if the validation check doesn’t pass, but with this method we don’t care what it does. Whether it aborted or not we’re not trying to submit the form, we just wanted to trigger it to re-validate and do nothing else. (Disclaimer: This is a superfluous example since there’s a .validate() method in the plugin, but it’s a decent illustration of intent)