Bubbling vs Capturing Explained

Every DOM event travels through three phases. The capture phase starts at the root of the tree and works down towards the target. The target phase is the event at the element the user actually interacted with. The bubble phase then works back up from the target to the root.

A listener registered without options runs during the bubble phase, which is why a click handler on a list item still fires when you click a child element inside it. A listener registered with the capture option set to true runs during the capture phase, which fires first, before the event reaches the target.

// The DOM only exists in a browser, so check before using it.
if (typeof document !== "undefined") {
  const outer = document.querySelector("#outer");
  const inner = document.querySelector("#inner");

  outer.addEventListener("click", (event) => {
    console.log("outer saw a click on", event.target.id);
  });

  inner.addEventListener("click", (event) => {
    console.log("inner saw a click on", event.target.id);
    console.log("current target is", event.currentTarget.id);
  });

  inner.click();
} else {
  console.log("No DOM in this runtime - open a browser console to try it.");
}

The two properties on the event object are worth being able to name. The target property is the deepest element the event happened on, so a click on the text inside a button reports the text node's parent as the target rather than the button. The currentTarget property is the element whose listener is currently running, which is the one that changes as the event travels. Confusing the two is the source of a lot of confusing bug reports, so it is worth stating the difference clearly in an interview.

Some events do not bubble. The focus and blur events bubble, but the focusin and focusout events were added as bubbling versions of them. The mouseenter and mouseleave events also do not bubble, which is why mouseover and mouseout are often used instead when you need delegation.

The capture phase runs first, travelling down from the root of the document to the target. The target phase comes next, where listeners registered directly on the target run. The bubble phase runs last, travelling back up from the target to the root.

The default is the bubble phase. A listener registered with a plain addEventListener call, without any options, runs when the event bubbles back up. To opt into the capture phase you pass an options object with the capture option set to true, or you pass true as the third argument, which is the older shorthand.

Two details make the answer sharper. First, listeners on the target itself run during the target phase, and the order between capture and bubble listeners on the target depends on the order they were registered, not on the phase, because the target is where the two phases meet. Second, some events simply do not bubble, so for them the bubble phase never happens and the propagation is capture then target.

A practical note. In older browsers, attaching a capture listener to the document and then stopping propagation was a common trick to intercept an event before it reached the application code. That is now discouraged in favour of the capture option on the specific element you care about, because a document level capture listener has to inspect every event on the page.

The example below uses a small stand-in for the DOM that models both phases, so you can see the exact order the listeners fire in.

// A tiny stand-in for the DOM that models both event phases.
const element = (tag) => ({
  tagName: tag.toUpperCase(),
  children: [],
  listeners: { capture: {}, bubble: {} },
  parentNode: null,
  appendChild(child) { child.parentNode = this; this.children.push(child); return child; },
  addEventListener(type, phase, handler) {
    (this.listeners[phase][type] ||= []).push(handler);
  },
  dispatchEvent(event) {
    const path = [];
    for (let node = this; node; node = node.parentNode) path.unshift(node);

    // Capture phase: from the root down to the target.
    for (const node of path) {
      for (const handler of node.listeners.capture[event.type] ?? []) {
        handler({ phase: "capture", currentTarget: node });
      }
    }

    // Bubble phase: from the target back up to the root.
    for (const node of path.reverse()) {
      for (const handler of node.listeners.bubble[event.type] ?? []) {
        handler({ phase: "bubble", currentTarget: node });
      }
    }
  },
});

const outer = element("div");
const inner = element("span");
outer.appendChild(inner);

outer.addEventListener("click", "capture", (e) => console.log("outer capture", e.currentTarget.tagName));
inner.addEventListener("click", "bubble", (e) => console.log("inner bubble", e.currentTarget.tagName));
outer.addEventListener("click", "bubble", (e) => console.log("outer bubble", e.currentTarget.tagName));

inner.dispatchEvent({ type: "click" });

The order is outer capture, then inner bubble, then outer bubble. The capture listener on the ancestor fires before the event ever reaches the target, and the bubble listener on the same ancestor fires after the event has been on its way back up.

That order is the reason the capture phase exists. It gives you a way to react to an event before any other handler has had a chance to change the page, which is useful for things like a drag interaction that has to start before anything else responds, or for a global shortcut that should fire before the focused component handles it.

And the order is also why stopping propagation makes such a difference. If a handler on an ancestor calls stopPropagation, the event never reaches the bubble listeners further up, so a capture handler that stops propagation will prevent the target's own bubble listeners from running at all. That is occasionally what you want and occasionally a very confusing bug, which is why it is worth being able to say exactly which phase your listener runs in.