Scroll Horizontal Story Track — Free GSAP ScrollTrigger Sideways Scrollytelling

Vertical scroll is the default, but some narratives — a product's journey, a process pipeline, a timeline of scenes — read more naturally as a left-to-right sequence. This snippet uses the standard GSAP "horizontal scroll section" recipe to translate a wide flex row sideways in exact lockstep with normal, familiar vertical scrolling, so visitors never have to learn a new input gesture.

Vertical input, horizontal output — one scrubbed tween

The five .hst-slide chapters sit in a flex row (.hst-track) five viewport-widths wide. A single gsap.to() tween animates the track's x from 0 to -getScrollDistance() (the track's overflow width beyond the viewport), with its scrollTrigger pinning #hstPin and scrubbing at 0.5. Because scrub ties the tween's progress directly to scroll position, the visitor's ordinary mouse wheel or trackpad scroll — still vertical — drives a horizontal slide, with no custom wheel-event hijacking or gesture remapping required.

`invalidateOnRefresh` keeps distances honest on resize

Both the tween's x target and the trigger's end are functions (() => -getScrollDistance(), () => '+=' + getScrollDistance()) rather than fixed numbers, and invalidateOnRefresh: true tells ScrollTrigger to re-run those functions whenever it recalculates — so resizing the window (which changes track.scrollWidth and window.innerWidth) never leaves the pinned scroll distance out of sync with how far the track actually needs to travel.

Dots and a fill bar both read off the same progress value

The onUpdate callback receives the tween's own ScrollTrigger progress once per scroll frame and uses it for two things: setting the fill bar's width directly, and rounding progress * (slides.length - 1) to decide which chapter dot should be marked active. Both indicators are therefore always perfectly in sync with the actual horizontal position of the track — there's no separate, potentially-drifting tracking logic for the dots versus the bar.

Dots are clickable, and compute their own jump target

Each dot's click handler reads the tween's live scrollTrigger.start/end values (not hardcoded pixel offsets) to compute exactly which vertical scroll position corresponds to that chapter's slice of the pinned range, then animates window scroll to it with GSAP's scrollTo (bundled in GSAP core as of v3). Because the jump target is derived from the same live trigger the main tween uses, it stays correct even after a resize changes the total distance.

Customizing it

Add a sixth .hst-slide and the horizontal distance, progress bar, and dot count all adapt automatically — nothing is hardcoded to five chapters. Swap the CSS gradients for real photography using background-image, or combine with a scroll company timeline for a vertical timeline that transitions into this horizontal chapter walk.