(The logic relies on doing some pixel calculations which could be reworked to use `event.snapTargetInline` instead, but that’s me nitpicking)
Top-level
(The logic relies on doing some pixel calculations which could be reworked to use `event.snapTargetInline` instead, but that’s me nitpicking) 9 comments
The keyframes are also generated and built in such a way that you get the directionality effect. For example, here are the keyframes for the 4th card being active. Upon inspecting the other keyframes you’ll see the keyframe here at 75% move around. (I believe this per-card keyframes approach can be simplified by either leveraging `animation-range` or by relying on a ViewTimeline per scroll-item [which I think would also bypass the need for `scrollsnapchange`], but again: that’s me nitpicking here) Thank you for building this WONDERFUL scroll-driven animations demo, Paul. It was very delightful to see. Stellar work! (Is Paul on Mastodon? Couldn’t find a matching profile here.) The logic/math for the card stack itself was done by Nate Smith a while ago. Find all the details on X: https://x.com/nasm423/status/1795133452016054401 Here’s my take on this demo: https://codepen.io/bramus/pen/xxvgzoL - No Sass Or, if you prefer: a blog post. https://www.bram.us/2024/10/13/scroll-driven-animated-card-stack-with-scroll-snap-events/ |
And finally here’s the third clever thing Paul did: use that `data-active-index` to attach different animations to the cards.
This is done for each possible index and is auto-generated using Sass.