Fix scroll “bounce” with CSS – Some gotchas

June 20, 2024

Last December, I posted about fixing scroll “bounce”–when you scroll through a website and the browser allows you to scroll past the uppermost or lowermost part of the page before returning to the correct position. It was a solution that Michelle Barker made me aware of in her article, Preventing Scroll “Bounce” with CSS.

I have learned a few things since I wrote that article in December and I wanted to share them. These are a couple of gotchas that you will want to consider if you decide to “fix the problem” of scroll bounce.

The default solution does not work in Chrome on :root

The solution that Michelle shared has you apply overscroll-behavior to “none” to the :root element.

:root {
  overscroll-behavior: none;
}

But applying it to :root (or the html element) does not work in Chrome. It will work if you have if you have an overflow-x: hidden applied to the :root (or html element). For this site, I ended up applying the overscroll-behavior to the body element.

body {
  overscroll-behavior: none;
}

As I tested that out, it did not have an adverse effect in other browsers that supported putting the overscroll-behavior on the :root. Of course, you could always add the overflow-x: hidden to the :root and that will solve it for all browsers.

:root {
  overscroll-behavior: none;
  overflow-x: hidden; // or you could use overflow-x: clip
}

Issues with trackpad for Mac

The other gotcha that I learned about came from a colleague of mine who uses a Trackpad for his Mac. There is a behavior that allows you to scroll between pages in a browser window with the Trackpad. But if you have the overscroll-behavior set to ‘none’, it will disable that gesture. The same thing will happen with the trackpad on a Mac laptop.

The gesture is a two-finger swipe to the right on the left-hand side of the trackpad to go back to the previous page. And two-finger swipe to the left on the right-hand side to go to the next page (if there is one).

The behavior works a bit differently between browsers. There is not a visual cue in Firefox but the window will go to the previous and next pages if you use the gesture on the trackpad. In Chrome and Edge, there is a visual cue of an arrow to the left (previous page) or the right (next page). However, the functionality will not work on a page that has the overscroll-behavior: none set on the :root or body element except in Safari. The overscroll-behavior: none is not a problem in Safari.

You could change the overscroll-behavior to overscroll-behavior-y: none so that it only addresses the bounce vertically on the page. But I am not sure I like that solution because you will have the bounce on the horizontal which defeats the purpose of using the solution in the first place. I would much rather that the behavior was consistent between the horizontal and the vertical.

Should we try to fix the “bounce”

This leads to the question of whether we should try to fix the scroll bounce in the first place. As I mentioned in my first article, I have never liked the behavior. It can expose the body background color, which might differ from your header. It gives a very professional design a less elegant look.

But the bounce is part of the behavior of modern browsers. I tend to think that you should not mess with the default behavior of browser elements (like form elements) because those solutions tend to lead to new problems (like accessibility issues with forms). In this case, adding the overscroll-behavior set to ‘none’ can disable functionality that many users might rely on to navigate through different pages in the browser window.

Like many problems in the front-end space, you have to make decisions about solutions that are not always cut and dry. It always helps to think about those using your site when you make decisions that can affect their experience. I don’t think there is a definitive answer to the question that I pose. You need to be aware of the tradeoffs and decide from there.

I have only “fixed the bounce” on two sites, this site which is my site, and a client project. The client project worked a lot like an app and we decided in the end that we liked fixing the bounce. And for this site, my main user is myself and because I don’t use the trackpad to navigate between pages in a browser window, I am okay with fixing the bounce and disabling the trackpad functionality. But I might decide differently in the future. Or other browsers may approach it like Safari and it might not be an issue in the future.