Event Bubbling Visualizer — Free HTML CSS JS Snippet

The DOM event model has three phases — capture, target, and bubble — and almost every explanation of it draws a static arrow diagram instead of showing an actual click event traveling through actual nested elements. This snippet fixes that: three real nested boxes (Outer, Middle, Inner) each carry genuine addEventListener handlers registered in both phases, a live log prints exactly which handler fires and in what order, and an animated pulse physically travels down through the tree during capture and back up during bubble — using the browser's real event dispatch, not a scripted approximation of it.

Real capture and bubble listeners, not a simulated order

Each box registers two listeners on the exact same element: addEventListener('click', handler, true) for the capture phase and addEventListener('click', handler, false) (the default) for the bubble phase. When Inner is clicked, the browser's actual dispatch algorithm runs: it walks from document down to inner calling every registered capture-phase listener along the way (outer capture, then middle capture, then inner capture), then calls the target's own bubble-phase listener, then walks back up calling every bubble-phase listener from inner to middle to outer. The log entries this snippet prints are not scripted to look like this order — they are the direct, real-time record of the callbacks the browser itself invoked, which is why toggling any of the six checkboxes (capture/bubble per box) genuinely changes which lines appear, because it genuinely changes which listeners exist.

Two animated pulses on the same physical positions

runVisualPulse() computes the screen-space center of each box with getBoundingClientRect() and animates a small SVG <circle> through those points using requestAnimationFrame with a cubic ease-out (1 - Math.pow(1 - p, 3)), not CSS keyframes, because the destination points depend on live layout measurements taken at click time rather than fixed values that could be hardcoded into a @keyframes rule. The first pulse (grey, thinner, radius 4) runs Inner → Middle → Outer to represent the capture phase's top-down path rendered in reverse for legibility, immediately followed by a second pulse (indigo, thicker, radius 6) that runs the same Inner → Middle → Outer path representing the bubble phase — the phase most real-world event listeners actually use, which is why it is drawn heavier and brighter.

Why capture is drawn dim and bubble is drawn bright

This is a deliberate legibility choice, not an accident: capture-phase listeners are comparatively rare in real code (most handlers use the default bubble phase), so demoting the capture pulse to a thin grey line keeps visual weight on the phase developers actually rely on day to day, while still making the true dispatch order — capture always completes fully before bubble begins — visible as two distinct, sequential animations rather than one ambiguous blur.

The stopPropagation() toggle and where it actually breaks the chain

Checking "stopPropagation()" on the Middle box's bubble-phase checkbox flips a flag that is read inside Middle's own bubble handler: if (name === 'middle' && stopChecked) { e.stopPropagation(); }. Calling stopPropagation() from inside a handler stops the event from continuing to any further listeners in the remaining phase — since this call happens during Middle's *bubble* handler, it prevents Outer's bubble listener from ever firing, but it does not retroactively undo the capture phase, which already ran to completion before bubbling even started. runVisualPulse() mirrors this precisely: when the stop toggle and Middle's bubble checkbox are both on, the second (bubble) pulse animation is only given two points, [innerPt, middlePt], so it visibly halts at Middle instead of continuing to Outer — and the log shows the real consequence, with no "OUTER — bubble phase handler fired" line ever appearing.

Independent per-box, per-phase toggles built for direct experimentation

Rather than one global on/off switch, each box exposes its own capture and bubble checkboxes (six total), checked via document.getElementById(name + '-capture').checked and ...'-bubble'.checked at the top of every handler before it logs anything or runs its side effects. This lets you construct any combination — for example, disabling Inner's own bubble listener while keeping Middle's and Outer's — and watch the log and pulse respond exactly as the real DOM event model dictates for that specific configuration, rather than only ever observing the one "all phases enabled" case most diagrams show.