Smooth scrolling has gotten a lot easier. If you want it all the time on your page, and you are happy letting the browser deal with the duration for you, it’s a single line of CSS:
html {
scroll-behavior: smooth;
}
I tried this on version 17 of this site, and it was the second most-hated thing, aside from the beefy scrollbar. I haven’t changed the scrollbar. I like it. I’m a big user of scrollbars and making it beefy is extra usable for me and the custom styling is just fun. But I did revert to no smooth scrolling.
As Šime Vidas pointed to in Web Platform News, Wikipedia also tried smooth scrolling:
The recent design for moved paragraphs in mobile diffs called for an animated scroll when clicking from one instance of the paragraph in question to the other. The purpose of this animation is to help the user stay oriented in terms of where the paragraph got moved to.
We initially thought this behavior would benefit Minerva in general (e.g. when using the table of contents to navigate to a page section it would be awesome to animate the scroll), but after trying it out decided to scope this change just to the mobile diffs view for now
I can see not being able to adjust timing being a downside, but that wasn’t what made me ditch smooth scrolling. The thing that seemed to frustrate a ton of people was on-page search. It’s one thing to click a link and get zoomed to some header (that feels sorta good) but it’s another when you’re trying to quickly pop through matches when you do a Find on the page. People found the scrolling between matches slow and frustrating. I agreed.
Surprisingly, even the JavaScript variant of smooth scrolling…
document.querySelector('.hello').scrollIntoView({
behavior: 'smooth'
});
…has no ability to adjust timing. Nor is there a reliable way to detect if the page is actively being searched in order to make UX changes, like turning off smooth scrolling.
Perhaps the largest downside of smooth scrolling is the potential to mismanage focus. Scrolling to an element in JavaScript is fine, so long as you almost move focus to where you are scrolling. Heather Migliorisi covers that in detail here.
Firefox (at least on Linux) automatically “disables” smooth scroll when using on page search.
I just tried it on macOS and seems to be true there also. Good job Firefox! I think that’s desirable UX.
Have you noticed all the places you can’t use scroll-behavior?
https://caniuse.com/#search=scroll-behavior
I’ve seen two definitions for “smooth scrolling”. One, which is smooth auto-scrolling on link clicks, I can see why that might be annoying, but as long as it’s only on links down the page, it’s relatively inoffensive.
Unfortunately, what I’ve seen a lot of sites do is use JavaScript to override the user’s scroll wheel behavior, and that’s a whole different can of worms, one which often goes by the same name. It may look pretty in a demonstration, but in for end users, it is a usability nightmare, making scroll wheel operations slower and less precise.
In general, I think messing with input devices is a bad idea. People have certain expectations for how they can interact with a website, based on their own experience and mouse/browser configuration, and whenever you tell a user that you know better than them how they ought to be using their computer, you risk driving that user away.
I think the latter is more generally known as “scroll jacking” yeah?
This is pretty interesting as I would have never even guessed that find/search would also animate. I feel like this is an oversight of the browser though, as using a built-in browser function like that should be independent of a site’s code.
According to the Specs the duration of smooth scrolling is managed by the user agent, which makes Sense IMO. AFAIK in Most Browsers this is configured by some flag in about:config or so … So Users could even Set it to 0 to disable it completely. I think this ist absolutely the right way even though Browsers should make this configuration Option more prominent in the Future…
I prefer to always have scrollbars visible as well, but I have to disagree on forcing a large, garish, orange/pink one when the user has explicitly chosen to hide scrollbars through their OS settings. I think that if a user has a choice, and they made their choice clear, we should do our best to honor it.
Note: Firefox seems to honor the user’s choice regardless of the CSS, so kudos to them.
I’m probably out of the loop here, buuuut why do/did people hate smooth scrolling so much? In most use cases, like this, it seems like a really good and useful thing to have.
I’m probably missing something then, am I not? About why it was so hated?
Check out what I wrote in the post above – it had to do with “Find on Page” being altered (in Chrome).
So the article’s title should read “Downsides of Smooth Scrolling when applied to the whole page” ? For single anchor links that lead to another section, I can’t see a downside as well. People, who do not like this kind of transitions or prefer no animations at all, can disable this behavior browser-wide (as I wrote in my first comment here).
What is the browser support for this feature? What is your benchmark in browser support for implementing a new feature?
Personally … I use chromium, with Overlay scrollbars enabled. I use a flinger (cheap wacom one tablet with 2 buttons) a lot and make heavy use of smooth scroll.
If we had a
:root:searching
pseudo-property, and perhaps a:root::searchbar
pseudo-element that could have limited styling (perhaps) that would be useful.Same with events. A set of
search
events that expects an async iterator of DOM nodes for instance would be useful. For instance,searchopen
,searchbegin
,searchterminate
,searchrestart
and so on. You would start with a document iterator of text nodes… I guess.Would be more useful on infinite scrollers though.
So it seems like the answer to your problem is that you only want to enable smooth scrolling temporarily when a user clicks an anchor link.
When the user clicks the link, enable smooth scrolling. The browser should smooth scroll. One second after the user has clicked the link, disable smooth scrolling.
The end effect is that you get the smooth link scrolling that people like when clicking links. When using ctrl + F smooth scrolling is disabled.
I like the beefy scrollbar, it’s prominent and easy to use. I just don’t like that it has an embossed effect that’s not found anywhere else in the redesign.
The worst of all is when it’s JavaScript managed (scroll jacking as you pointed out), it’s always janky and almost unusable on mobile.
But when the natived method is triggered via JavaScript like:
it only happens on the selected links, therefore there is no downside in my opinion.
On a side note: Whyever one would want to place the CSS smooth scroll property on the WHOLE page in the first place ..?!?
On my very own site, I’m using smooth scroll in the JS variant, but ONLY for specific links. So its being triggered only when clicking on links in the navigation and the main container, IF those are linking to page-internal anchors. Which automatically does not include on-site search etc. pp. But well .. give people a tool, and they are going to abuse it .. eyerolls
cu, w0lf.