| From TFA: > For instance, it is easy for a user to land at an awkward scroll position which leaves an item partially on-screen when panning. > To this end, this module introduces scroll snap positions which enforce the scroll positions that a scroll container’s scrollport may end at after a scrolling operation has completed. Which is exactly what this page is doing. > primarily a touch interaction It's exclusively a scroll interaction, whether the pointer event is the result of mouse or touch input. > the DOM page is still scrolling natively I'm not sure what you're trying to say by "DOM page." JS is reacting to the scroll position of the viewport. The user experience is the same. |
With scroll snapping you the user have always control of the scrollable content. What you do not have control over is where it will stop scrolling. A similar behavior to forced guides in a movable element on rails (such as drawers).
This page doesn’t scroll at all, and uses the scroll as a time control for a “movie”. And that is scroll jacking, as it hijacks the scroll position to do something completely different.
This page, at least on mobile, is also guilty of implementing it in the worst way possible: without any alternative scroll indications and without smooth continuous transitions that make it clear that you are controlling the animation through the scroll.
Apple is somewhat better at doing this since the scrolljacking procedure usually brings you to an element which, at the end of a glamourous entrance, actually scrolls away with the page.