`. Changing `entryKey` makes React discard that subtree and mount a fresh one; a new element runs its `animation` from frame zero, which is the entire replay mechanism. The key goes on the wrapper, not on each child — keyed individually, only the children whose own identity changed would replay, which for a caption is usually none of them. 2. One keyframe, `kinetic-rekey-in`, runs `opacity: 0` and `translateY(var(--kx-rekey-from))` to `opacity: 1` and `translateY(0)` over 0.5 s on `cubic-bezier(0.22, 1, 0.36, 1)`. Because the offset is a custom property rather than a literal, flipping its sign on the root turns a rise into a drop — both directions from one set of keyframes. 3. The stagger is a generated ladder of `:nth-child(n) { animation-delay: calc(var(--kx-rekey-stagger) * (n - 1)) }` rules, built once at module scope for the first eight children. A ninth-and-beyond rule pins the tail to the eighth delay, so an overlong block degrades to "the tail arrives together" rather than "the tail arrives first at delay zero". 4. `animation-fill-mode: both` is what makes the delay usable. Without it a delayed line is painted at its normal full-opacity style for the length of its own delay, then snaps to the from-frame to begin animating — every line flashes before it enters. 5. The stylesheet is emitted once through React 19's ` {/* The key is on this wrapper, so every child is a new node on every change and every child animation restarts. Putting the key on the children individually would replay only the ones whose own identity changed, which for a caption is usually none of them. */}

{children}

); } ``` ## Requirements These are not optional. A version of this component that skips any of them is not finished. **Cleanup.** Nothing to clean up. There are no listeners, no timers, no rAF and no tweens — the animation is CSS and the nodes running it are removed by React itself on every key change. **Reduced motion.** `animation: none` on the children, which re-exposes their base styles — full opacity, no offset. The caption is fully rendered on the first frame after the key change, in its final position. This is the one case where dropping the animation is the correct still state rather than a cop-out, because the from-frame is the only thing the animation adds. **Frame-rate independence.** Any smoothing must be a function of delta time. `x += (target - x) * 0.1` converges twice as fast at 120 Hz as at 60 Hz; use `x = target + (x - target) * Math.pow(smoothing, dt)` instead, where `smoothing` is the fraction of the gap remaining after one second. **Strict mode.** Assume effects run twice in development. Setup must be idempotent and teardown must fully undo it. ## Known pitfalls — avoid these specifically - Restarting the animation by toggling a class off and on. The browser coalesces both mutations into one style recalculation and the animation never restarts, which is why that approach always ends up with a `void el.offsetWidth` forced reflow wedged between the two lines. - Tweening the caption with an animation library instead. A fast prev/next leaves two opposing tweens on the same node and the text jitters between them; a remount cannot have that problem because the contended node is gone. - Omitting `animation-fill-mode: both`. Every delayed line paints at full opacity for the length of its delay, then snaps to invisible to start animating. The block flickers, and it flickers worse the larger the stagger. - Putting the key on the individual lines. Their identities usually do not change between captions, so React reuses the nodes and nothing replays — the most common way this technique silently does nothing. - Wrapping anything focusable or stateful. The remount destroys DOM state and moves focus to the body: an input inside this loses its caret and its value on every key change. This is for display content only. - Animating both directions with a second keyframe block. The two drift apart the first time someone tunes the offset. One keyframe reading a signed custom property cannot. ## Notes - Pairs with a counter badge and prev/next controls to make a slideshow caption, which is where the technique was observed. The same wrapper works for a filter result header, a hovered-row detail panel, or a step label in a multi-step form summary. - Direction is a prop rather than something derived internally, because only the caller knows whether an index change was forward, backward, or a jump from a thumbnail strip. - For the media beside the caption, a CSS `transition` on the background beats a tween: an index change is a discrete event with one start and one end state, which is exactly what a transition is for. ## Definition of done Step forward and the eyebrow, title and metadata rise into place one after another, roughly 60 ms apart. Step backward and they drop in from above instead. Click next four times as fast as you can and every caption plays its full entrance from the start with no jitter or stuck line. With reduced motion the new caption is simply there, complete, on the first frame. When you are finished, tell me which of the requirements above you implemented and where, so I can check them.