Direction-Aware Grid Reveal on Scroll — IntersectionObserver

The standard scroll reveal — every element fading up from the same fixed offset, as in Reveal on Scroll — reads as slightly mechanical once a grid has more than a handful of items, because every card performs an identical motion. This variant keeps the same underlying single-observer pattern but lets each card declare its own entrance direction through a plain data-from attribute, so a three-column grid can have its left column slide in from the left, its right column slide in from the right, and its middle column simply rise from below — motion that visually converges toward the grid's center rather than marching uniformly in one direction.

Direction as data, not as a hardcoded class per card

Each .dgr-card carries data-from="left", data-from="right", or data-from="up". The CSS then keys off that attribute directly — .dgr-card[data-from="left"] { transform: translateX(-40px) } and so on — so the JavaScript never needs to know or branch on direction at all; it only ever toggles a single .dgr-visible class, and the attribute selector supplies the starting offset. This keeps the observer callback identical to a plain single-direction reveal while giving markup-level control over per-card motion.

A row-based stagger computed from DOM position, not a hardcoded delay

Rather than hand-authoring a transition-delay inline style on every card (as in the simplest reveal-on-scroll pattern), the delay here is computed at trigger time: Array.from(el.parentElement.children).indexOf(el) % 3 * 90 finds the card's index among its siblings, takes it modulo 3 (the column count), and multiplies by 90ms. This staggers cards left-to-right within whichever row is currently entering the viewport, without needing to know in advance how many rows the grid will end up having — add or remove cards and the stagger still lines up correctly by column position.

Why setTimeout instead of a CSS transition-delay per card

Because the stagger delay is computed dynamically from DOM position rather than known in advance, applying it via el.style.transitionDelay before adding .dgr-visible would work equally well — this snippet uses setTimeout to defer adding the class instead, which is a small implementation choice with an equivalent visual result; either approach avoids hardcoding delay values into the markup.

rootMargin shifts the trigger point earlier

{ threshold: 0.2, rootMargin: '0px 0px -60px 0px' } shrinks the observer's effective viewport by 60px from the bottom, so cards must scroll slightly further up before they're considered "intersecting" — this avoids the reveal firing the instant a card's top pixel touches the very bottom edge of the screen, which can look premature on tall viewports.

Respecting prefers-reduced-motion

The reduced-motion check happens once up front and, when true, both zeroes the computed stagger delay and lets a prefers-reduced-motion media query in the CSS strip the transform entirely (!important overriding the direction-specific starting offsets) — cards still fade in via opacity, but never slide, for users who have asked for reduced motion.

Customizing it

Add a fourth direction like data-from="down" with its own attribute selector and starting transform, change the % 3 in the stagger calculation to match a different column count, or swap translate for a scale-based entrance per card. Pair it with a Bento Grid or Feature Cards layout for a more dynamic feature showcase entrance.