In CSS transitions, what does the `transitionend` event fire for on an element that transitions several properties at once, and name two situations where it never fires at all.

## One event per property A transition is not an element-level thing; it is created per property. If a rule says ```css .card { transition: opacity 300ms, translate 300ms, background-color 500ms; } ``` and all three values change, the browser creates three independent transitions, each with its own clock. Three `transitionend` events are dispatched — two at 300ms and one at 500ms. This surprises people who write `el.addEventListener('transitionend', cleanup)` and find `cleanup` running three times. The event object identifies which transition finished: - `propertyName` — the property that ended, always a **longhand**. A `transition: padding 200ms` on an element whose padding changes on all sides yields separate events named `padding-top`, `padding-right`, `padding-bottom`, `padding-left`. - `elapsedTime` — how many seconds the transition actually ran, **excluding** the delay. For a completed 300ms transition it is 0.3 regardless of any delay. - `pseudoElement` — the string `::before` or `::after` when the transition ran on a pseudo-element, and empty otherwise. A pseudo-element's transitions dispatch on the originating element, so this is how you tell them apart. ## It bubbles `transitionend` bubbles up the tree. A handler on a list container receives the end events of every animating descendant. Guard with `if (event.target !== el) return;` when you only care about the element itself — otherwise a child's hover transition silently triggers your close logic. ## The full event family Four events exist, in this order for a transition that runs to completion: 1. `transitionrun` — the transition has been created; fires **before** the delay elapses. 2. `transitionstart` — the interpolation is actually beginning, after the delay. 3. `transitionend` — it finished normally. And instead of the third, when things go wrong: 4. `transitioncancel` — the transition stopped before completing. The `run`/`start` split is what lets you distinguish "a transition is pending" from "it is moving", which matters when delays are long. ## Case one: no transition is generated Nothing fires because nothing was created. This happens when: - the combined duration is zero — the default `transition-duration` is `0s`, so a rule with easing but no time does nothing; - the property is not covered by `transition-property`, or `transition-property: none` is in effect; - the computed value did not actually change — reapplying `color: #333` to an element that already computes to `#333` is not a change; - the two values are not interpolable, such as a length to `auto`; - the element is being rendered for the first time, so there is no before-change value to start from. ## Case two: the transition is cancelled A running transition is cancelled when its element becomes `display: none`, is removed from the document, or when the property stops being transitionable — and in these cases `transitioncancel` fires and `transitionend` does not. Interruption by a *new* value behaves differently: the running transition is replaced by a fresh one that starts from the current interpolated value, so you get a later `transitionend` for the new transition, not for the one you were waiting on. ## Why this matters in practice The dangerous pattern is making cleanup conditional on the event: ```javascript panel.classList.remove('open'); panel.addEventListener('transitionend', () => panel.remove(), { once: true }); ``` If a stylesheet change drops the duration to zero, if a user setting removes motion, or if the element is hidden mid-flight, the event never arrives and the panel stays in the DOM forever. Robust code either treats the event as an optimisation with a timeout fallback, listens for `transitioncancel` as well, or filters on `event.propertyName` so only the property it cares about triggers the work. ## What interviewers are listening for That the event is per-property and reports longhands; that it bubbles; that `elapsedTime` excludes the delay; and above all that it is **not guaranteed** to fire, so it must never be the only path to a state change. Candidates who have shipped animated UI mention the cancellation case unprompted.