Here’s the situation: Your site offers a “scroll back to top” button, and you’ve implemented smooth scrolling. As the page scrolls back to the top, users see something that catches their eye and they want to stop the scrolling, so they do a smidge of a scroll on the mouse wheel,, trackpad, or whatever. That’s what I mean by cancellable. Without any further action, the scroll event goes to the destination. Cancellable means you can stop it with a subsequent scroll. I find the cancellable behavior better UX, although I have no data to back that up.
I’m finding some discrepancies between browsers, as well as between CSS and JavaScript on how this all works.
Scroll down on this demo and give it a shot:
Here’s what I experienced on the browsers I have easy access to:
| CSS Smooth Scroll | JavaScript Smooth Scroll | |
|---|---|---|
| Chrome | Cancellable (Speed: Slowish) | Not Cancellable |
| Firefox | Cancellable (Speed: Very Fast!) | Cancellable (Speed: Fast!) |
| Safari | No Smooth Scrolling | No Smooth Scrolling |
| Edge | Cancellable (Speed: Fast) | Not Cancellable |
| iOS | No Smooth Scrolling | No Smooth Scrolling |
If it was up to me, I’d:
- make smooth scroll actions triggered either through CSS or JavaScript cancellable.
- define “cancellable” because it isn’t really the right word. Maybe “interrupted”? Or “controlled”? Ideas welcome!
- make the speed controllable, or if not, attempt to get browsers to agree on a medium-ish speed (that stays consistent regardless of scroll distance).
- make Safari have it. Smooth scrolling makes things like carousels without JavaScript very practical, and that’s great, particularly on mobile where iOS Safari is forced on Apple devices.
“cancellable” makes perfect sense to me, and I completely agree with your recommendations.
I suggest that JS smooth-scroll should return a promise which resolves when finished and rejects when cancelled.
slow scrolling is always bad, browsers already have it enabled by default for no reason other than annoying users but let you disable it, there’s no need or reason to enforce it by styles or scripts, the best practice is to not do it at all
Feels dogmatic.
I don’t see what you mean with bad about smooth scroll ? Seems usefull to understand that the page is scrolling, otherwise I need to scroll a bit manually to check that I’m still on the same page. I’m surprised that user-experience focused company like Apple, didn’t implemented it …
like all blocking animations it only slows users down, ever felt annoyed your flagship phone is sluggish? want to know why? UI transitions taking often 10 or more frames while the operation itself needs much less than single frame of processing time, with animations disabled 5 years old low-mid tier model works faster than latest flagship cause you don’t have to wait for animation to end
and how is user supposed to know that page is scrolling? you know, maybe cause they triggered it? when you tick the scroll wheel you don’t want to see 30 frames of animation, you want the page to move instantly, when you flip right-to-left you don’t want to watch animation for next 15 seconds, you want page to jump to top instantly, simple
blocking animations that absolutely have to show all planned frames before user regains control are evil, and even making the scrolling animation cancellable so you can reverse the scrolling direction doesn’t help as you still have to sit and wait till it scrolls to the target
we don’t need slow UI
One thing to consider is the Gsap scrollto plugin – it features an “autokill” feature for cancellable scrolling https://greensock.com/docs/v3/Plugins/ScrollToPlugin
If you use js library to implement smooth scrolling animation, you can cancel it programmatically. You can listen to “wheel” & “touchmove” events as an indicator for user scroll intervention.
demmmo! demmmo!
I just worked on a project using Fullpage.js and one of the most frustrating things about it is that if you have smoothscroll active, it’ll just fly past sections of the site if you’re not scrolling deliberately slowly. After futzing with it for hours, I absolutely agree with the need for a cancel event.