Event Bubbling and Event Capturing in JavaScript (Deep Practical Guide)

The first time I saw a click handler fire on three different elements even though I clicked only one, I thought I had a bug. It wasn’t a bug. It was the browser doing exactly what it promised: propagating the event through the DOM. Once you understand how events travel, you stop fighting the platform and start designing interactions that feel clean and predictable. You also get to write less code and avoid whole categories of edge cases.

If you’ve ever built a modal, a dropdown, or a nested menu, you’ve already encountered this. The question isn’t whether bubbling or capturing happens. The question is whether you’re handling it intentionally. I’ll show you how the event propagation phases work, how to control them, and how to build interfaces that behave the way users expect. I’ll also walk through modern patterns I use in 2026 projects, including event delegation at scale, framework boundaries, and performance tradeoffs. By the end, you’ll be able to decide, with confidence, where to attach listeners, when to stop propagation, and how to avoid common gotchas.

Event propagation in plain language

Think of the DOM as a set of nested boxes: a button inside a card inside a section inside the page. When an event happens on the button, the browser doesn’t keep it isolated. It sends that event through a path that touches each box along the way. That path has three phases:

1) Capturing phase: the event travels from the top of the document down to the target.

2) Target phase: the event reaches the element that actually triggered it.

3) Bubbling phase: the event travels back up from the target to the document.

Most events in the browser bubble by default, which means if you attach a click listener to the card, it will also hear clicks on the button inside it. Capturing is opt-in: you have to request it explicitly.

This design might feel odd at first, but it’s incredibly practical. Bubbling lets you attach a single listener to a parent and handle events from all its children. Capturing gives you a chance to intercept and coordinate behavior before the target handler runs. I treat capturing like a “pre-flight check” and bubbling like “after the action.”

addEventListener and the capture flag

You attach listeners with addEventListener. The third argument decides whether the listener runs during capturing or bubbling. Here’s the syntax I use most often:

element.addEventListener(eventName, handler, { capture: false });

A few details that matter:

• capture: false (or omitted) means the listener runs in the bubbling phase.
• capture: true means it runs in the capturing phase.
• The same element can have both a capturing and a bubbling listener for the same event.
• The handler receives the event object, which includes target, currentTarget, eventPhase, and control methods like stopPropagation().

If you want a quick mental model, imagine the browser walking from the document root down to the target, then walking back up. When it passes an element that has a capture listener, it runs it on the way down. When it passes an element that has a bubble listener, it runs it on the way up.

A runnable example that shows bubbling vs capturing

Here’s a complete, runnable example that logs the event flow. Click the inner box and observe the order:

// index.html






.box {
padding: 16px;
border: 2px solid #333;
margin: 8px;
}
#outer { background: #f0f6ff; }
#middle { background: #e0ffe6; }
#inner { background: #ffe6e6; }




Outer

Middle
Inner



const outer = document.getElementById("outer");
const middle = document.getElementById("middle");
const inner = document.getElementById("inner");
// Capturing listeners
outer.addEventListener("click", () => console.log("capture: outer"), { capture: true });
middle.addEventListener("click", () => console.log("capture: middle"), { capture: true });
inner.addEventListener("click", () => console.log("capture: inner"), { capture: true });
// Bubbling listeners
outer.addEventListener("click", () => console.log("bubble: outer"));
middle.addEventListener("click", () => console.log("bubble: middle"));
inner.addEventListener("click", () => console.log("bubble: inner"));

If you click “Inner,” you’ll see:

• capture: outer
• capture: middle
• capture: inner
• bubble: inner
• bubble: middle
• bubble: outer

This ordering is the essence of event capturing and bubbling. You can use it to coordinate behavior, for example to block a click early or to run cleanup logic after children run.

Event target vs currentTarget: the subtle difference that matters

Most bugs around event propagation are really misunderstandings about target and currentTarget.

• event.target is the element that initiated the event (the exact element you clicked).
• event.currentTarget is the element whose listener is currently running.

If you attach a listener on a parent and click a button inside it, target is the button and currentTarget is the parent. That’s how delegation works.

Here’s a small example that makes this obvious:

const card = document.querySelector(".card");
card.addEventListener("click", (e) => {
console.log("target:", e.target);
console.log("currentTarget:", e.currentTarget);
});

I recommend logging both when debugging. It instantly tells you whether you’re handling the right element. It also helps you avoid the classic mistake: using target when you meant currentTarget, which can lead to strange behavior when users click on nested elements like icons or spans.

Why bubbling exists: event delegation at scale

Bubbling isn’t just a historical accident. It’s the backbone of efficient event handling. When you have a list of 1,000 items and each item has a “Delete” button, you can attach 1,000 listeners. That works, but it’s heavier than it needs to be and easier to leak if you re-render frequently.

Instead, you attach one listener to the parent and inspect the target. That’s event delegation.

const list = document.querySelector(".task-list");
list.addEventListener("click", (e) => {
const deleteBtn = e.target.closest("button[data-action=‘delete‘]");
if (!deleteBtn) return; // Click wasn’t on a delete button
const item = deleteBtn.closest(".task-item");
const taskId = item?.dataset.taskId;
if (!taskId) return;
// Perform deletion
console.log("Deleting task", taskId);
});

This pattern scales well. You can dynamically add or remove items and the listener still works. In modern apps, especially with virtualized lists or frequent DOM updates, delegation can be the difference between a smooth UI and a sluggish one.

When capturing is the right choice

I use capturing when I need to intercept or coordinate before child handlers fire. A few examples:

• Global shortcuts: You might capture keydown at the document level before a component stops it.
• Drag and drop orchestration: Capturing can ensure your drag controller runs before nested components respond.
• Analytics or instrumentation: Capturing can guarantee logging runs even if a child stops propagation.

Here’s a simple capture-based shortcut handler:

document.addEventListener("keydown", (e) => {
if ((e.ctrlKey || e.metaKey) && e.key === "k") {
e.preventDefault();
openCommandPalette();
}
}, { capture: true });

By capturing at the document level, I ensure this shortcut triggers even inside deeply nested components that might also listen for key events. I’m not forcing my handler to run; I’m just ensuring it’s first in line.

stopPropagation, stopImmediatePropagation, and preventDefault

To control event flow, you have a few tools. Each has a different job.

• event.preventDefault() stops the default browser action (like following a link or submitting a form).
• event.stopPropagation() stops the event from moving further along the path.
• event.stopImmediatePropagation() stops propagation and prevents any other listeners on the same element from running.

Here’s a clean example where a modal prevents clicks from closing it when clicking inside:

const overlay = document.querySelector(".modal-overlay");
const dialog = document.querySelector(".modal-dialog");
overlay.addEventListener("click", () => closeModal());
dialog.addEventListener("click", (e) => {
// Prevent the click from reaching the overlay
e.stopPropagation();
});

I use stopImmediatePropagation() sparingly because it can be surprising. If you do use it, document it clearly in the codebase so other developers aren’t left guessing why their listener never runs.

Common mistakes and how I avoid them

You can save a lot of time by recognizing a few recurring mistakes.

Mistake 1: Relying on event.target without checking context

If your UI uses icons, spans, or nested elements, event.target can point to the wrong element. I usually pair delegation with closest() so I always act on a predictable parent.

Mistake 2: Stopping propagation everywhere

Stopping propagation is sometimes necessary, but overuse creates invisible walls that break unrelated features. I prefer to scope it to specific interactions and document why it’s needed.

Mistake 3: Capturing when bubbling would be simpler

Capturing is powerful, but it’s more complex and can surprise other developers. I recommend defaulting to bubbling and only capturing when you need pre-target behavior.

Mistake 4: Forgetting passive listeners for scroll and touch

While not directly about propagation, passive listeners influence performance. On touch and wheel events, I typically set { passive: true } unless I need to call preventDefault().

window.addEventListener("wheel", onScroll, { passive: true });

Real-world scenarios that expose edge cases

Here are a few situations where understanding propagation saves your day.

1) Nested buttons and clickable cards

Clickable cards with nested buttons often cause double actions. You click the button, it triggers the card’s handler too. The fix: stop propagation or structure your click targets clearly.

card.addEventListener("click", () => openDetails());
button.addEventListener("click", (e) => {
e.stopPropagation();
saveItem();
});

2) Shadow DOM boundaries

Events can cross Shadow DOM boundaries, but only if they’re composed. If you work with Web Components, check event.composed and the composedPath() to understand what’s really happening.

button.addEventListener("click", (e) => {
console.log(e.composed, e.composedPath());
});

If you see propagation behaving unexpectedly in component libraries, this is usually why.

3) Pointer events vs mouse events

Pointer events unify mouse, touch, and pen. They bubble and capture just like mouse events. But if you mix pointer and mouse events, you can get duplicate triggers. I recommend choosing one set and sticking to it for a given UI area.

4) Form elements and default actions

Clicking a submit button inside a form triggers a submit event. Even if you listen on a parent, that submit can bubble. Use preventDefault() on submit handlers rather than click handlers on buttons if you want consistent behavior.

form.addEventListener("submit", (e) => {
e.preventDefault();
saveForm();
});

Performance considerations in large interfaces

Event listeners are cheap, but not free. A single listener is often just a few microseconds, but if you attach thousands in a complex UI and rerender often, you can feel it. In my experience, delegation keeps interaction handling more predictable and typically reduces overhead in the 10–15ms range on large lists, especially on mid-range devices.

I also watch for two other performance issues:

• Listener churn: Creating and removing listeners during frequent re-renders can add overhead. Delegation avoids this by keeping a stable listener on a parent.
• Heavy handlers: Even if propagation is fast, your handlers can be slow. Keep logic light, defer expensive work, and consider requestAnimationFrame for layout-dependent changes.

If you’re building an app with dozens of interactive widgets on the same page, a small amount of planning around event flow pays off quickly.

Traditional vs modern event handling

Some teams still attach handlers directly to every element, which was common before component frameworks became popular. Modern applications can be more efficient and easier to maintain with a different approach. Here’s how I compare them:

Approach

Traditional

Modern (2026) —

—

— Listener placement

Direct listeners on each element

Event delegation on stable parents Rerender behavior

Reattach listeners on updates

Single listener survives updates Debugging

Many independent handlers

Centralized control with target filtering Performance

Scales poorly with large lists

Scales well even with thousands of items Best use case

Small, static UI

Dynamic, component-driven UI

I still use direct listeners for small, static sections. But for any dynamic list or component tree, delegation is my default.

How frameworks influence propagation

Frameworks like React, Vue, and Svelte have their own event layers. They still rely on the DOM’s bubbling and capturing behavior, but the details can differ.

• React uses a synthetic event system that attaches listeners at the root. Bubbling still matters, but stopPropagation() stops it within React’s system and the DOM if you call the native event method.
• Vue respects native DOM propagation, but it provides modifiers like .stop and .capture to express intent declaratively.
• Svelte compiles to native listeners and behaves very close to the DOM model.

The key point: no matter the framework, the DOM propagation model still underpins behavior. If something feels odd, inspect the real event path and whether a framework is intercepting it.

Debugging propagation: my practical checklist

When an event handler fires unexpectedly or doesn’t fire at all, I follow a short checklist:

1) Log the phase: console.log(e.eventPhase) to know if you’re in capture or bubble.

2) Inspect target vs currentTarget: to see what element you actually clicked.

3) Check for stopPropagation: use the browser’s event listener breakpoints to see if something is stopping it.

4) Look for overlapping elements: z-index or pointer-events might reroute the click.

5) Verify composed path: especially with Web Components and Shadow DOM.

This checklist sounds basic, but it catches the majority of event issues I see in real codebases.

A mental model I keep in my head

I explain event propagation to myself like this: “The browser is a courier. It starts at the rooftop (document), walks down the stairs to the apartment (target), then walks back up. If I want to intercept a package before it reaches the apartment, I stand on the staircase on the way down (capture). If I want to check what happened after delivery, I wait on the way back up (bubble).”

This mental model helps me choose the right phase quickly. It also reminds me that if I stop the courier on the way down, nobody below gets the package. If I stop the courier on the way up, the delivery still happened, but nobody above gets the status update.

Event phases and the eventPhase value

The eventPhase property is an underused debugging tool. It tells you which phase is active at the time your handler runs:

• 1 for capturing phase
• 2 for target phase
• 3 for bubbling phase

I often add a tiny utility during debugging:

function logPhase(label, e) {
const map = { 1: "capture", 2: "target", 3: "bubble" };
console.log(label, map[e.eventPhase], e.currentTarget);
}

Then I can attach it to multiple listeners and instantly see the flow. Once the bug is solved, I remove it, but during a tricky interaction it saves time.

Event delegation patterns I actually ship

Delegation is easy in theory, but there are a few patterns that make it reliable in messy UIs.

Pattern 1: Action attributes + closest

I prefer data attributes because they survive refactors better than class names.

const panel = document.querySelector(".panel");
panel.addEventListener("click", (e) => {
const actionEl = e.target.closest("[data-action]");
if (!actionEl || !panel.contains(actionEl)) return;
const action = actionEl.dataset.action;
if (action === "save") save();
if (action === "archive") archive();
if (action === "toggle") toggleDetails(actionEl);
});

I check panel.contains(actionEl) because closest can walk past the boundary if the element has moved in the DOM or if you click inside a portal.

Pattern 2: Delegation with strict selectors

If the UI is simple, I keep it strict to avoid accidental matches.

list.addEventListener("click", (e) => {
if (!e.target.matches("button.delete")) return;
const item = e.target.closest(".item");
if (!item) return;
remove(item);
});

Pattern 3: Delegation with a registry

In complex dashboards, I sometimes keep a map of actions to handlers to avoid giant if blocks.

const handlers = {
save: () => save(),
archive: () => archive(),
toggle: (el) => toggleDetails(el),
};
panel.addEventListener("click", (e) => {
const el = e.target.closest("[data-action]");
if (!el) return;
const fn = handlers[el.dataset.action];
if (fn) fn(el);
});

This is the smallest pattern I’ve found that still scales nicely.

When NOT to use delegation

Delegation is great, but I avoid it in a few cases:

• Critical form controls where exact element ownership matters, like custom input components that wrap native inputs. Direct listeners keep things explicit.
• Very small widgets where an extra layer of delegation makes the code harder to read.
• Third-party components where I don’t control the markup and closest might break on updates.

When delegation makes the code harder to understand, I choose clarity over cleverness. The browser can handle a handful of direct listeners just fine.

Capturing in complex UI orchestration

Capturing gets interesting when you need cross-cutting behavior. Here are a few real patterns I’ve used:

Global escape to close overlays

When overlays are nested, I capture the keydown for Escape once and close the topmost overlay.

document.addEventListener("keydown", (e) => {
if (e.key !== "Escape") return;
const top = getTopOverlay();
if (top) top.close();
}, { capture: true });

Capturing ensures I still see the key even if a component tries to stop it.

Click-outside handling without brittle listeners

A common pattern is closing popovers when you click outside. I prefer to listen on the document and check containment. I usually do this in bubbling because I want internal handlers to run first.

document.addEventListener("click", (e) => {
const openPopover = document.querySelector(".popover.open");
if (!openPopover) return;
if (openPopover.contains(e.target)) return;
closePopover();
});

If I want to block a click from opening something new before closing the old one, I might switch to capture and manage the order explicitly.

Instrumentation that doesn’t miss events

If I’m tracking user interactions for analytics, I capture at the root and record the event before any component can stop it.

document.addEventListener("click", (e) => {
logClick(e.target);
}, { capture: true });

I keep this lightweight and async so I don’t block UI.

Pointer events, touch behavior, and propagation surprises

Pointer events bubble and capture like any other, but there are a few extra behaviors that matter:

• Pointer capture can redirect events to a specific element even if the pointer leaves it. This changes the effective target for subsequent events.
• Touch events may be canceled by the browser if you don’t declare touch-action or if a scroll happens.
• Passive listeners can prevent you from calling preventDefault(), which is often necessary for custom drag or swipe behavior.

Here’s a minimal pattern I use for drag interactions that respects propagation and performance:

const handle = document.querySelector(".drag-handle");
handle.addEventListener("pointerdown", (e) => {
handle.setPointerCapture(e.pointerId);
startDrag(e);
});
handle.addEventListener("pointermove", (e) => {
if (!isDragging()) return;
updateDrag(e);
});
handle.addEventListener("pointerup", () => stopDrag());

Pointer capture is not the same as event capture, but it’s easy to confuse them. I treat pointer capture as “keep sending events here” and event capture as “run handlers on the way down.” They solve different problems.

Custom events and propagation

Custom events can bubble too. That’s a powerful way to decouple components: a child can dispatch a custom event that a parent listens to without direct references.

const item = document.querySelector(".item");
item.addEventListener("click", () => {
const event = new CustomEvent("item:select", {
bubbles: true,
detail: { id: item.dataset.id },
});
item.dispatchEvent(event);
});
list.addEventListener("item:select", (e) => {
console.log("Selected", e.detail.id);
});

This gives me clean separation. I can build reusable components that communicate up the tree without hard-coded callbacks.

Event propagation across iframes and documents

Events do not naturally bubble across iframes. Each document is its own world. If you need coordinated behavior across frames, you’ll need messaging (like postMessage) rather than relying on bubbling. This is a common surprise for people building embedded widgets. I remind myself: “If it’s a different document, the event path stops at the document boundary.”

Accessibility considerations I keep in mind

Propagation isn’t just about clicks. Keyboard and focus events matter a lot for accessibility:

• Focus events do not bubble, but focusin and focusout do. If I need delegation for focus, I use those instead.
• Key events often need to be handled at the document level for global shortcuts, but I avoid stealing keys from inputs.

Here’s a pattern that respects input fields while still catching shortcuts:

document.addEventListener("keydown", (e) => {
const tag = e.target.tagName;
const isInput = tag === "INPUT" | tag === "TEXTAREA" e.target.isContentEditable;
if (isInput) return;
if ((e.ctrlKey || e.metaKey) && e.key === "k") {
e.preventDefault();
openCommandPalette();
}
}, { capture: true });

This makes the app feel keyboard-friendly without breaking typing.

A deeper look at stopPropagation side effects

stopPropagation() doesn’t just stop events. It can break unrelated features that rely on delegation. I’ve seen three common side effects:

1) Click-outside handlers stop working because a child stops propagation.

2) Global analytics miss events because the capture or bubble listener never runs.

3) Framework-level features like routing or hotkeys break if they depend on root listeners.

When I use stopPropagation(), I ask myself: “Am I stopping it at the right point?” Sometimes the right fix is not to stop propagation, but to adjust the listener’s logic to ignore certain targets. That preserves the event path for everything else.

Avoiding accidental double triggers

Double triggers often come from mixing event types or listening on multiple phases. I avoid this by:

• Picking one event type per interaction (click or pointerup, not both).
• Choosing either capture or bubble for the same handler logic, not both.
• Watching for synthetic events (framework-generated) plus native listeners.

If I see a handler firing twice, I check whether I accidentally registered it in both phases or in both the framework and the DOM.

Propagation and async code

Async code doesn’t change the event path, but it changes timing. If I do something like await inside a handler, it doesn’t rewind the propagation path. The path is determined at dispatch time. That means:

• Stopping propagation after an await is too late.
• If I need to stop propagation, I do it immediately at the top of the handler.

button.addEventListener("click", async (e) => {
e.stopPropagation();
await save();
showToast();
});

This pattern avoids subtle bugs where the event already bubbled while the handler waited.

Event order within the same element

If multiple listeners are attached to the same element for the same event and same phase, they run in the order they were added. This matters when you have shared utilities that attach listeners before your component does. If I need strict ordering, I usually combine logic into one handler or use a dedicated event bus rather than relying on registration order.

Practical UI patterns and fixes

Here are some patterns I use often, with the event propagation rationale baked in.

Clickable rows with inner controls

Rows should open details when clicked, but inner controls should not.

rows.addEventListener("click", (e) => {
const row = e.target.closest(".row");
if (!row) return;
// If the click was on a control, ignore it
if (e.target.closest("button, a, input, select")) return;
openRow(row.dataset.id);
});

No stopPropagation() needed. I just filter the target.

Accordion that closes other panels

I like to delegate on the container and use data attributes to determine which panel to open.

accordion.addEventListener("click", (e) => {
const header = e.target.closest("[data-accordion-header]");
if (!header) return;
const panelId = header.dataset.accordionHeader;
openPanel(panelId);
});

Single overlay listener for many modals

Multiple modals can share the same overlay logic if I keep it centralized.

document.addEventListener("click", (e) => {
const overlay = e.target.closest(".modal-overlay");
if (!overlay) return;
const dialog = overlay.querySelector(".modal-dialog");
if (dialog.contains(e.target)) return;
closeModal(overlay.dataset.modalId);
});

This avoids attaching a click handler to every modal instance.

Event propagation in component libraries

If you’re working in a component library, you’ll often see patterns like onClick props passed down. Propagation still applies, but you have to be aware of boundaries:

• Encapsulated components should avoid stopping propagation unless they explicitly document it.
• Reusable components should emit custom events rather than reaching into parent state.
• Component authors should provide hooks or options for propagation control (like stopPropagation props) rather than forcing one behavior.

I try to keep component behavior predictable and let the consumer decide whether to stop propagation.

A note on non-bubbling events

Not all events bubble. Examples include focus, blur, mouseenter, and mouseleave. This matters because delegation won’t work for them. If I need delegation, I use the bubbling alternatives like focusin/focusout or mouseover/mouseout.

This is a common source of “why isn’t my listener firing?” bugs. If a delegated listener doesn’t run, I first check whether the event actually bubbles.

Handling propagation with options: once, passive, and signal

These options don’t change bubbling, but they change how you manage listeners in large apps:

• once: true automatically removes the listener after it fires.
• passive: true tells the browser you won’t call preventDefault().
• signal lets you remove many listeners at once with an AbortController.

I use signal a lot when I build components that mount/unmount frequently:

const controller = new AbortController();
root.addEventListener("click", onClick, { signal: controller.signal });
root.addEventListener("keydown", onKey, { signal: controller.signal, capture: true });
function cleanup() {
controller.abort(); // removes all listeners
}

This keeps my teardown code clean and avoids leaks.

Testing event propagation intentionally

When I write tests for interactive components, I validate propagation indirectly by verifying outcomes, but sometimes I want to assert phases. I’ll add a small test utility that logs eventPhase and collects the order of events. Even if I remove it later, it helps me verify that a change didn’t accidentally flip capture to bubble or vice versa.

If you don’t have a test suite, you can still do manual verification: log the event path and check that your expected handler order matches what actually runs.

Edge cases I’ve tripped over

A few more corner cases that show up in real projects:

• pointer-events: none on an element means it won’t receive events, so the target might be a parent or sibling instead of the visually clicked element.
• z-index overlays can intercept clicks and change the propagation path.
• Disabled form controls won’t fire click events at all, which can make delegation look broken.
• Programmatic .click() can trigger events without a real user interaction, which affects default actions and focus.

Whenever something feels impossible, I inspect the DOM tree, check styles like pointer-events, and log the event path.

Practical decision framework I use

Here’s the quick decision framework I use to decide where and how to attach a listener:

1) Is this UI dynamic or large? If yes, I default to delegation.

2) Do I need to intercept before child handlers run? If yes, I use capture.

3) Am I preventing a default action? If yes, I attach to the event that actually triggers it (e.g., submit for forms).

4) Could stopping propagation break something? If yes, I avoid stopping and filter by target instead.

5) Will this be reused by others? If yes, I keep propagation behavior predictable and documented.

This checklist keeps my event handling consistent across projects.

Another full example: dropdown + nested actions

This is a compact example that uses bubbling, delegation, and stopPropagation() in a way I’d actually ship.

const menu = document.querySelector(".menu");
const toggle = document.querySelector(".menu-toggle");
// Toggle open/close
toggle.addEventListener("click", (e) => {
e.stopPropagation();
menu.classList.toggle("open");
});
// Close on outside click
document.addEventListener("click", (e) => {
if (menu.contains(e.target)) return;
menu.classList.remove("open");
});
// Delegated action handling inside menu
menu.addEventListener("click", (e) => {
const item = e.target.closest("[data-action]");
if (!item) return;
if (item.dataset.action === "logout") logout();
if (item.dataset.action === "settings") openSettings();
});

I stop propagation on the toggle because I don’t want the document handler to immediately close the menu. Inside the menu, I let bubbling happen and just delegate. This is the simplest, most predictable mix of behaviors for this pattern.

Capturing isn’t evil, but it needs intention

I’ve seen teams avoid capturing entirely because it feels advanced. I don’t think it should be taboo. I just think it needs intention. Capturing is ideal for:

• Shortcut coordination
• Centralized logging
• Intercepting before child state changes

What I don’t use capture for is everyday click handling. I keep it reserved for “before anyone else runs” situations. That’s the mental boundary that keeps the codebase understandable.

Event propagation and clean architecture

Propagation is a low-level tool, but it shapes architecture. If you lean into bubbling, you can build more modular UI because parent components can react to child events without direct wiring. If you rely on capturing too much, you can end up with hidden coupling where global handlers quietly override local behavior. I aim for a balance:

• Local behavior lives in the component.
• Cross-cutting behavior lives at a high level, usually in capture for coordination.
• Communication uses custom events or explicit callbacks, not secret stopPropagation calls.

This balance keeps complex interfaces from turning into spaghetti.

Closing thoughts: how I’d explain it in one minute

If you asked me to explain event bubbling and capturing in one minute, I’d say this: “Every event travels down the DOM to the target and back up. Capturing listens on the way down; bubbling listens on the way up. Most code uses bubbling because it’s simpler and enables delegation. Capturing is for pre-target coordination. The event object tells you where you are, and you can stop or prevent things when you need to. If you understand the path, you can build cleaner, more scalable interfaces.”

That’s the whole game. Once you internalize the path, everything else is just choosing where to stand on it.

Expansion Strategy

Add new sections or deepen existing ones with:

• Deeper code examples: More complete, real-world implementations
• Edge cases: What breaks and how to handle it
• Practical scenarios: When to use vs when NOT to use
• Performance considerations: Before/after comparisons (use ranges, not exact numbers)
• Common pitfalls: Mistakes developers make and how to avoid them
• Alternative approaches: Different ways to solve the same problem

If Relevant to Topic

• Modern tooling and AI-assisted workflows (for infrastructure/framework topics)
• Comparison tables for Traditional vs Modern approaches
• Production considerations: deployment, monitoring, scaling

I’ve already applied this strategy throughout the guide. If you want, I can extend it further with framework-specific deep dives, more edge cases, or a lab-style checklist you can use in reviews and code audits.