Events

jQuery wraps browser event handling in one method, .on(), that works the same way across every event type and every element — click, hover, keypress, form submit — instead of remembering a different API for each.

A basic click handler

JS app.js

$("#btn").on("click", function() {
  console.log("Button clicked!");
});

Console output, after clicking #btn

Button clicked!

Reading the clicked element

Inside a handler, this refers to the raw DOM element that triggered the event — wrap it in $(this) to use jQuery methods on it:

JS app.js

$(".item").on("click", function(event) {
  console.log("You clicked:", $(this).text());
});

Console output, after clicking an .item that reads "Cherry"

You clicked: Cherry

Because the same handler function is attached to every .item, $(this) is how you find out which one was actually clicked — the function itself doesn't know in advance.

Event delegation

Attaching a handler directly to an element only works if that element already exists when .on() runs. Passing a second argument — a selector — attaches the listener to a stable parent instead, and jQuery checks on every click whether it happened on a matching descendant:

JS app.js

$("#list").on("click", "li", function() {
  console.log("Delegated click on:", $(this).text());
});

$("#list").append("<li>Added later</li>");

Result

Clicking the newly appended "Added later" <li> still logs Delegated click on: Added later — the listener lives on #list, which was already on the page, not on the individual <li> elements.

Note: .click(fn) is a shorthand for .on("click", fn) and behaves identically for elements that already exist — but only the two-argument delegated form (.on("click", "li", fn)) reaches elements added to the page after the handler was set up. Attaching plain .click() handlers to a list and then wondering why newly-added rows don't respond is one of the most common jQuery beginner mistakes.

PreviousSelectors NextDOM Manipulation