jQuery delegated event handling: how tightly should the container be scoped for a dynamic list

Short answer

Delegate on the closest ancestor that is guaranteed to exist for the page's lifetime and is never itself replaced by re-renders. That is the conventionally accepted rule, and it resolves your tension directly: the table's wrapper is the right root only if your partial-refresh code never swaps that wrapper out. If it does get swapped, move up to the next fixed layout element — not necessarily document, but whatever ancestor survives every refresh path.

Why "stable" matters more than "close"

Delegation works because the handler lives on an element that stays in the DOM while its descendants change. Two failure modes sit at opposite ends of your choice:

• Too close, and replaceable: if a partial refresh replaces the wrapper node, the listener dies with it. This failure is silent — no exception, clicks just stop firing. This is the worse failure mode because it produces a bug report, not an error.
• Too far (document): the handler survives everything, but every click on the page walks from event.target up to document, testing your selector at each ancestor. Correct, just broader than necessary.

So the practical procedure is: inspect your markup and your refresh code, find the nearest ancestor that no code path ever replaces, and bind there. If your table's wrapper is re-rendered, bind to the persistent page-level container above it instead.

// Bind to an ancestor that partial refreshes never replace
$('#page-content').on('click', 'table.results tr', function (e) {
  // this === the clicked tr
});

Does the matching cost on document matter?

For clicks, no — not measurably. Per event, jQuery walks from the target up to the container and runs a selector test at each step. That is a handful of matches() calls on a user-driven event that fires at most a few times per second. This cost only becomes a real concern for high-frequency events like mousemove or scroll, which you should rarely delegate broadly anyway. Choosing document over a wrapper for click delegation is a robustness/scoping trade-off, not a performance one. If you doubt it in your specific page, profile one click in devtools; the delegation overhead will be lost in the noise.

The stopPropagation constraint is the real one

Yes — components that call stopPropagation() (or stopImmediatePropagation()) on the bubble path between your rows and the delegation root will prevent the event from ever reaching the container. The delegated handler simply never fires, again silently. Two consequences:

• Delegating above a component that stops propagation is unreliable. If any of those components sit between your rows and your chosen root, either move the root below them or stop them from swallowing clicks that originate in your table.
• This can cut against document: the higher you bind, the more third-party code sits on the bubble path with a chance to intercept. A closer stable root reduces exposure to other components' propagation handling.

Verify by clicking rows while the suspect components are active, or temporarily add a capturing-phase listener that logs whether the event reaches your intended root.

Two smaller gotchas

• Selector scope: 'tr' matches rows in any descendant table, including a nested table inside a cell. If nested tables are possible, qualify the selector (e.g., 'table.results > tbody > tr' or a row class).
• Version: this behavior of .on(events, selector, handler) is long-stable across jQuery 3.x, including 3.7 — nothing here is version-sensitive.

Recommendation for your case

Bind to the nearest ancestor your refresh logic provably never replaces — a fixed layout container above the swappable wrapper if needed. That gives you bounded selector matching, survival across row-level AJAX updates, and the smallest possible exposure to other components' stopPropagation(). Reserve document for the case where genuinely no stable ancestor exists.