jQuery Live() Method And Event Bubbling

Posted November 9, 2009 at 8:54 PM

Tags: Javascript / DHTML

Recently, there has been a lot of talk in the development community about jQuery's new live() event method. People are just in love with it. If you have not heard of jQuery's live() method, it's an event delegation mechanism that allows you to bind event handlers not just to all existing instances of a given node type, but also to any future instances of a given node type (by "type" I mean a set of DOM nodes matched by a given jQuery selector). This is a very cool thing, both from a development standpoint as well as from a memory and performance standpoint; but, if you don't understand how the live() method works, you might get yourself into trouble.

 
 
 
 
 
 
 
 
 
 

While there is a magical quality to it, under the hood, jQuery's live() method is quite practical. Rather than binding an event handler directly to a given node set, the live() method works by binding event handlers to the document itself and then reacting to all the events that bubble up through the DOM. The actual wiring mechanism is a bit more complicated than that, but in general, you can think of the essence of the live() event cycle as follows:

 
 
 
 
 
 
jQuery Live() Event Method() Works By Using Event Delegation At The Document Level. 
 
 
 

As you can see, the click event on the "A" element bubbles up to its parent element, "P," and then on to its ancestor, the document. At the document level, jQuery then checks the event target against the selector used to define the live() event. If the target matches the selector (or close enough), jQuery then triggers the event handler in the context of the target element.

This event cycle is excellent for event delegation but, it comes with a cost; because it relies completely on the ability for the given event to bubble up to the document object, it is imperative that the bubbling remains in tact. If the event bubbling breaks anywhere within the ancestor chain, the live-bound event handlers will not be triggered. To see this problem in action, take a look at this demo:

 Launch code in new window » Download code as text file »

  • <!DOCTYPE HTML>
  • <html>
  • <head>
  • <title>jQuery Live() Method And Event Bubbling</title>
  • <script type="text/javascript" src="jquery-1.3.2.js"></script>
  • <script type="text/javascript">
  •  
  • jQuery(function( $ ){
  •  
  • // Bind click events to links. This will bind a click
  • // handler to all current links as well as all new
  • // links added to the page.
  • $( "a" ).live(
  • "click",
  • function( event ){
  • alert( "Link clicked!" );
  • }
  • );
  •  
  • // Cancel all click events off of paragraphs.
  • $( "p" ).click(
  • function(){
  • return( false );
  • }
  • );
  •  
  • });
  •  
  • </script>
  • </head>
  • <body>
  •  
  • <h1>
  • jQuery Live() Method And Event Bubbling
  • </h1>
  •  
  • <p>
  • I am a paragraph that contains a <a href="">link</a>.
  • </p>
  •  
  • <p>
  • I am a paragraph that contains a <a href="">link</a>.
  • </p>
  •  
  • <p>
  • I am a paragraph that contains a <a href="">link</a>.
  • </p>
  •  
  • </body>
  • </html>

Looking at the code above, can you see what will happen with one of the "A" tags is clicked?

Nothing.

If you look at the code, you will see that we are using jQuery's live() method to bind a click handler to all the "A" elements. We are also directly binding a click handler to all of the "P" elements. The P-based click handler listens for the click event and then prevents it from being propagated (bubbling up). Now, even though each "P" element is an ancestor of each "A" element, because the live() method depends on event bubbling, the stop-propagation directive kills the live event.

jQuery's live() event method is definitely useful; but, unless you understand how it's working, things can start to fail quite quickly and for no obvious reason.

Download Code Snippet ZIP File

Post Comment  |  Ask Ben  |  Permalink  |  Other Searches  |  Print Page





Reader Comments

Nov 9, 2009 at 10:19 PM // reply »
5 Comments

Have you seen the livequery() plugin? It's similar, but its internals are a bit different, allowing it to do certain things that live() cannot. For example, live() won't work with events like blur, focus, change, etc., whereas livequery does (or at least it does with focus and blur, the two I've used). There's a decent explanation here: http://www.neeraj.name/blog/articles/882-how-live-method-works-in-jquery-why-it-does-not-work-in-some-cases-when-to-use-livequery


Nov 10, 2009 at 5:39 AM // reply »
2 Comments

Not really a question about the article, but what font did you use in the event bubbling diagram?


Nov 10, 2009 at 7:23 AM // reply »
9 Comments

@Thomas, I believe jQuery 1.4 (yet to be released) will support both the blur and focus events in its "live" mechanism.


Nov 10, 2009 at 7:54 AM // reply »
6,513 Comments

@Thomas,

I believe, from what I have heard, that live() was actually inspired by the liveQuery() plugin. But, as you know, they work in very different ways.

@Dave,

The font is a free font known at Sketch Rockwell. I think you can download it here if you are interested:

http://www.urbanfonts.com/fonts/Sketch_Rockwell.htm


Nov 10, 2009 at 9:45 AM // reply »
1 Comments

Ben, when I listened to your video, I was taken back at your pronunciation of live(). Since the word is a Heteronym http://bit.ly/heteronym it could be pronounced as the verb "l?v" or the adjective "la?v". I always assumed the later, but you've adopted the prior. You're probably right, but I'm very interested to know what anyone else thought.


Nov 10, 2009 at 9:54 AM // reply »
6,513 Comments

@Luke,

To be honest, it was *painful* to pronounce it the way I did :) When I see that word, everything in my wants to pronounce it as "L'eye've". People tell me this comes as a hold-over from "liveQuery", which prople pronounced "L'iv Query". I only recently changed my pronunciation because someone told me it was wrong... but I don't care for it :)


Nov 14, 2009 at 11:31 PM // reply »
1 Comments

Hmmm... Ok, I always pronounced it live-rhymes-with-give (I mean, c'mon - it's live & die!), but after arguments with a live-rhymes-with-jive colleague we went out searching.(Which you could read about here: http://www.mrspeaker.net/2009/11/12/how-to-pronounce-live/ )
Brandon Aaron says, via Twitter, that it's "live as in 'live broadcast' :)"

Do you think he's wrong, and that I might still have a chance of turning the tables on my nemesis?!


Nov 15, 2009 at 6:52 AM // reply »
1 Comments

Nice explanation.
At least it encourages me to find out the logic under the hood.


Nov 18, 2009 at 10:15 AM // reply »
4 Comments

@Thomas,

@James provides a special 'blur' and 'focus' handler, which can allow you to use those events with live():

http://stackoverflow.com/questions/1199293/simulating-focus-and-blur-in-jquery-live-method


Nov 18, 2009 at 12:54 PM // reply »
2 Comments

This is a awesome entry.
I like it. Thanx man.


Post Comment  |  Ask Ben

Recent Blog Comments
Nov 20, 2009 at 4:53 PM
Maintaining ColdFusion Sessions Across SMS Text Message Requests Without Cookies
Ben, you can ramp up the security by turning on J2EE session which gives you a third set of numbers other than CFID/CFTOKEN. There's a reason why ACF put this in place (other than just session replic ... read »
Nov 20, 2009 at 4:52 PM
Maintaining ColdFusion Sessions Across SMS Text Message Requests Without Cookies
Case in point, Ben, you may not be aware of this, but in Railo - OnApplicationStart() & OnSessionStart() act differently than in ACF. ACF does: OnApplicationStart (1st hit) OnSessionStart (1st and e ... read »
Nov 20, 2009 at 4:46 PM
Maintaining ColdFusion Sessions Across SMS Text Message Requests Without Cookies
@Todd, That's understandable. I am not sure if this really leaves any more security holes than the fact that using old cookie-based CFID / CFTOKEN values will create a new session using the old CFI ... read »
Nov 20, 2009 at 4:42 PM
Maintaining ColdFusion Sessions Across SMS Text Message Requests Without Cookies
My opinion is that I don't think auto-generating your own CFID/CFTOKEN is recommended. I'll have to wait for Micha to answer what the ramifications are, but he probably didn't allow this in Railo for ... read »
Nov 20, 2009 at 4:31 PM
Maintaining ColdFusion Sessions Across SMS Text Message Requests Without Cookies
@Todd, Yeah, each phone has a unique ID; this is the value that is being used to hack the custom CFID / CFTOKEN session values. ... read »
Nov 20, 2009 at 4:23 PM
Maintaining ColdFusion Sessions Across SMS Text Message Requests Without Cookies
Is there no unique (device or otherwise) id that gets passed in the request that you can shove into the application scope? ... read »
Nov 20, 2009 at 4:21 PM
Maintaining ColdFusion Sessions Across SMS Text Message Requests Without Cookies
@Todd, I mean "bug" only in the sense that it deviates from the way "Adobe ColdFusion" implements it.... only so far in that Railo is an open-source version of ColdFusion. I guess it depends on w ... read »
Nov 20, 2009 at 4:18 PM
Maintaining ColdFusion Sessions Across SMS Text Message Requests Without Cookies
Not sure how it's a bug, definitely a difference. I don't want my users or coders creating their own CFID/CFTOKEN. That's the server's job. ... read »