Browser Events

Dispatch, capture, target, bubble. Delegation, default actions, pointer and keyboard input, and why cancelling the wrong thing breaks scrolling or accessibility.

How an Event Is Dispatched
▶ lab

Hit-test to a target, build the propagation path, then walk it: capture down, at target, bubble up — with the path frozen before any listener runs.

Q · When a user clicks, how does the browser decide which code runs, and in what order?
Event Delegation

One listener on a container instead of one per row: fewer registrations, no rebinding after a re-render, and a matching step you now own.

Q · When a list has a thousand rows and each needs a click handler, where should the listener actually go?
preventDefault vs stopPropagation

Two operations that share nothing: one cancels what the browser was about to do, the other stops the event travelling. Reaching for the wrong one breaks somebody else's feature, silently.

Q · The browser did something I did not want, or my handler ran twice — which of these two calls is the fix, and what does the other one break?
Pointer Events

One event model for mouse, touch and pen — plus pointer capture, gesture cancellation, and the unrelated CSS property that shares the name.

Q · How do I write one interaction that works with a mouse, a finger and a stylus without three code paths?
Keyboard Events

Why Enter and Space activate a native button on different events, why a clickable div gets neither, and why `key` and `code` answer different questions.

Q · What does the browser do for keyboard users on a `<button>` that it does not do for my `<div onclick>`?
Passive Listeners

A `touchstart` or `wheel` listener can hold a scroll hostage until it has run. `{ passive: true }` is a promise not to cancel — and browsers now assume it in places, which changes what your code does.

Q · Why does adding an empty scroll-related listener make scrolling stutter, and what does `{ passive: true }` actually promise?