Browser Internals6h estimated

Browser Event Handling

Difficulty
Importance

The problem

A page needs to react to user actions — clicks, key presses, scrolls — happening on arbitrary, often deeply nested elements, without wiring up a separate listener for every single element that might be interacted with.

Why now

The DOM as a tree already established parent/child structure; event handling is where that structure becomes directly useful for user interaction — events travel through the tree in a defined order, and the JavaScript event loop already covered is exactly what schedules an event handler's execution once triggered.

Mental model

An event doesn't just fire on the element it happened on — it travels down the tree to that element (capturing), then back up (bubbling), passing through every ancestor along the way. This is why one listener on a parent can handle clicks on any current or future child (event delegation) — you're catching the event during its bubble phase instead of listening on every child individually.

Requires

Used in

Projects

  • Attach one click listener to a parent list element and use event delegation to handle clicks on any current or future child <li>, without attaching a listener to each item
  • Demonstrate the capturing and bubbling phases explicitly by logging from listeners at three nested levels with both phase options

Examples

  • A single listener on <ul> using event.target can handle clicks on any <li>, including ones added to the list after the listener was attached
  • event.stopPropagation() prevents an event from continuing its bubble past the current handler, which can silently break outer listeners if overused

Resources

Mastery checklist