Usually I am the one who says ‘Let the developer change every default browser behaviour’. Except, there are behaviours that, when customised, can hurt the user’s experience more than a custom behaviour could help. Such a case is custom scrolling.
In the past week I visited a lot of different websites. Not the usual web development websites that I visit all the time but very different normal websites: Product pages and travel websites which are much more likely to be seen by normal users than my web development pages. But on some pages I experienced serious issues to navigate. Many of them used custom scroll behaviour. And not in a way you would assume, like binding animations (i.e. fading in elements on scroll) to scroll events but they actually altered the scroll behaviour itself. Some altered the speed which I found the worst, others blocked the scrolling entirely to jump to the next or previous section of a page.
The main issue with that is that even I as an experienced web user couldn’t read some product specifications as I failed to scroll slow enough (or more precisely, to scroll only a few pixels which seemed to be the threshold on a page to go to the next page), resulting that I always switched not one section but two or three and was unable to go where I wanted to.
The same issue occurred on sites making scrolling faster. It is a key principle of a scroll device experience that I can set the speed of scrolling to my own default in the OS settings. A page altering this now leads to issues because the user can’t scroll in the speed he’s used to. This means he can’t read the content of a site anymore which should be the ultimate goal of a website.
Do it right, do it properly
Now you could say: ‘Do it right, do it properly’. But what if people use Wordpress Themes that include this behaviour?
Facing the facts, that is what most people do and what causes most issues nowadays.
Again, why would you alter the default scroll speed? I agree that we probably shouldn’t prevent the jumping to next section behaviour on scroll because web-apps sometimes want to do this and although I think a proper responsive concept shouldn’t have a paging mode I also accept that people use this for an application style.
But maybe a smart browser would automatically fix issues like a threshold which is too small to navigate or disables the function then. Because currently, it’s going the other way round. It seems that Blink wants to provide native binding to scrolling. While they seem to be aware of some issues they want to allow hiding scroll bars (which is bad because it’s a great indicator for the user) and don’t prevent too fast scrolls on the snap point navigation.
For altering the default scroll speed I honestly couldn’t come up with a valid use-case. If you have one, let me know. To me this is one of the worst and contra productive UX ”improvements“ people have done so far.