ScrollReveal Hero Text Reset — reset: true Replay Explained

Every other ScrollReveal snippet in this library sets reset: false (or relies on it as the default) because most content — a feature grid, a timeline, a pricing table — should reveal once and stay. A hero is the exception, and this snippet exists to make that exception explicit and to explain, precisely, what reset: true changes under the hood.

The default: reveal once, then disconnect

With reset: false, ScrollReveal attaches an IntersectionObserver to each target, and the first time that element crosses the visibility threshold, it plays the reveal animation and then calls unobserve() on it internally — the observer is torn down for that element. Scrolling it out of view and back in afterward does nothing, because nothing is watching it anymore. This is why the feature-grid and timeline snippets in this library never replay: it would be wasted motion for content the user has already read.

reset: true: the observer stays attached forever

With reset: true, ScrollReveal does not unobserve after the first reveal. Instead, on every subsequent IntersectionObserver callback, it checks direction: when the element's intersection ratio drops to zero (it has left the viewport), ScrollReveal reverses the animation — instantly resets the element back to its pre-reveal transform/opacity state, without an animated transition, so the hero looks "reset" rather than visibly un-animating. Then, the next time it crosses back into view, the full reveal transition plays again from that hidden state. The result: scroll past the hero, scroll back up, and the heading/subtext/CTAs all fade and slide in again exactly as they did on first load.

Why sequencing four separate reveal() calls instead of one

js sr.reveal('#shrTag', { delay: 0 ... }); sr.reveal('#shrTitle', { delay: 120 ... }); sr.reveal('#shrSub', { delay: 260 ... }); sr.reveal('#shrCtas', { delay: 400 ... });

Each hero element gets its own .reveal() call with an explicit, increasing delay rather than one call with interval across a shared selector. This is necessary because the four elements aren't visually interchangeable siblings (the way grid cards are) — they need specific, hand-tuned gaps (tag first, then a beat, then the headline, a longer beat before the CTAs) that read like an announcement rather than a mechanical cascade. interval assumes uniform spacing between same-type elements; explicit per-element delay is the right tool when the pacing itself is part of the design.

Reusing it

This is the pattern to reach for on any hero, landing page, or full-bleed intro section — anywhere a visitor might realistically scroll back to the top and would benefit from the entrance replaying rather than staying inert. Combine it with reset: false on everything below the fold, exactly as this library's two snippets demonstrate side by side.