A <ul> has a click handler that does `if (event.target.tagName === 'LI') { ... }`, but each <li> wraps its label in a <span>. Why does clicking the label do nothing, and how do you fix the dispatch?

## What `event.target` refers to The `target` property of the event object is the element the interaction actually concerned — the innermost element under the pointer, not the element you registered the handler on. That is exactly the property delegation depends on: without it, a handler on the container would have no idea which child was involved. But it is also the source of the bug in the question, because "innermost element" is decided by the markup, and markup changes. Given `<li><span>Buy milk</span></li>`, clicking the words gives you the `<span>`. Clicking the few pixels of `<li>` padding outside the span gives you the `<li>`. So the handler works intermittently — it fires when you click the edge of a row and does nothing when you click the label, which is a maddening bug to reproduce from a report. ## Why tag-name checks are brittle by construction A `tagName` comparison asserts that the hit element and the element you care about are the same node. In a delegated handler they almost never are, and any of these routine edits breaks it: - wrapping the label in a `<span>` or `<strong>` for styling; - adding an icon element inside the row; - putting a nested `<button>` or `<a>` inside the row; - swapping `<li>` for a `<div role="listitem">`. The check also couples your JavaScript to the element name, so a purely presentational markup change becomes a behaviour regression. Nothing in the tooling warns you: it is valid code that silently stops matching. ## The fix: map upwards with `closest()` `Element.prototype.closest(selector)` starts at the element it is called on and walks up through ancestors, returning the first one that matches the selector, or `null` if it reaches the top without a match. It includes the starting element itself, so it handles both cases — hit the `<li>` directly, or hit something inside it — with one call. ```js list.addEventListener('click', (event) => { const row = event.target.closest('li[data-id]'); if (!row || !list.contains(row)) return; activate(row.dataset.id); }); ``` Use `Element.prototype.matches(selector)` instead when you deliberately want an exact hit — for example "only when the checkbox itself was clicked" — and `closest()` whenever you mean "which row is this in". ## The two guards you always want **Null result.** Clicks land on the container's own padding, on a header, on empty space below the last row. `closest()` returns `null` there, and code that immediately reads `row.dataset` throws a `TypeError`. An early `return` is the whole fix. **Containment.** `closest()` does not stop at the element you registered the handler on; it keeps walking to the document root. With nested lists — a list inside a list item of an outer list — an inner container's handler can return a row belonging to the outer list, and you act on the wrong item. `container.contains(row)` pins the match to your own subtree. (`Node.prototype.contains` returns `true` for the node itself as well, which is what you want here.) ## Marking rows explicitly Selecting on `li` alone matches every list item, including ones that are decorative, disabled, or belong to a different feature. Matching a deliberate marker — `li[data-id]`, or `[data-action]` for controls — makes the contract explicit: an element opts into the handler by carrying the attribute. It also gives you a natural dispatch key: ```js const handlers = { edit: editRow, delete: deleteRow }; const el = event.target.closest('[data-action]'); if (el && list.contains(el)) handlers[el.dataset.action]?.(el); ``` That scales better than a chain of tag-name tests and survives markup refactors, because the attribute travels with the element that owns the behaviour rather than with its tag name or position. ## Diagnosing it in the wild The symptom to recognise: a handler that works on some parts of a row and not others. When you see that, log `event.target` at the top of the handler and click the failing spot — you will see a child element you did not expect, and the fix is always the same shape: stop testing the hit element, start mapping it to the element you actually mean.