Direct vs. Delegated – jQuery .on()

  1. Home
  2. javascript
  3. Direct vs. Delegated – jQuery .on()

I am trying to understand this particular difference between the direct and delegated event handlers using the jQuery .on() method. Specifically, the last sentence in this paragraph:

When a selector is provided, the event handler is referred to as delegated. The handler is not called when the event occurs directly on the bound element, but only for descendants (inner elements) that match the selector. jQuery bubbles the event from the event target up to the element where the handler is attached (i.e., innermost to outermost element) and runs the handler for any elements along that path matching the selector.

What does it mean by “runs the handler for any elements”? I made a test page to experiment with the concept. But both following constructs lead to the same behavior:

$("div#target").on("click", function() {
   alert($(this).attr("class") + " is clicked");


$("div#target").on("click", "", function() {
   alert($(this).attr("class") + " is clicked");

Maybe someone could refer to a different example to clarify this point? Thanks.

First answer

Case 1 (direct):

$("div#target").on("click", function() {...});

== Hey! I want every inside div#target to listen up: when you get clicked on, do X.

Case 2 (delegated):

$("div#target").on("click", "", function() {...});

== Hey, div#target! When any of your child elements which are “” get clicked, do X with them.

In other words…

In case 1, each of those spans has been individually given instructions. If new spans get created, they won’t have heard the instruction and won’t respond to clicks. Each span is directly responsible for its own events.

In case 2, only the container has been given the instruction; it is responsible for noticing clicks on behalf of its child elements. The work of catching events has been delegated. This also means that the instruction will be carried out for child elements that are created in future.

Second answer

The explanation of N3dst4 is perfect. Based on this, we can assume that all child elements are inside body, therefore we need use only this:

$('body').on('click', '.element', function(){
    alert('It works!')

It works with direct or delegate event.

Third answer

Tangential to the OP, but the concept that helped me unravel confusion with this feature is that the bound elements must be parents of the selected elements.

  • Bound refers to what is left of the .on.
  • Selected refers to the 2nd argument of .on().

Delegation does not work like .find(), selecting a subset of the bound elements. The selector only applies to strict child elements.

$("").on("click", ...

is very different from

$("span").on("click", ".green", ...

In particular, to gain the advantages @N3dst4 hints at with “elements that are created in future” the bound element must be a permanent parent. Then the selected children can come and go.


Checklist of why delegated .on doesn’t work

Tricky reasons why $('.bound').on('event', '.selected', some_function) may not work:

  1. Bound element is not permanent. It was created after calling .on()
  2. Selected element is not a proper child of a bound element. It’s the same element.
  3. Selected element prevented bubbling of an event to the bound element by calling .stopPropagation().

(Omitting less tricky reasons, such as a misspelled selector.)

Spread the love

Related articles

Comments are closed.