A tiny bit-o-CSS for Stable Scrollbar Gutters
I have my operating system configured to use visible scrollbars, a feature prominently elevated in macOS’ System Settings high enough that it would seem to imply some level of common usage (even though it’s not a default).
I don’t necessarily prefer the behavior this feature enables but I use it as an implied measure of quality when browsing the web .
I typically see the following problems:
- Pages that have horizontal overflow (and a scrollbar to match) are more obvious.
- Pages may move ~20px horizontally when sites toggle document-level
overflow: hidden
when toggling modals/dialogs. - On particulary slow pages you may even see pages shift when progressively rendering content slower than it can fill one “page fold.”
The easiest thing folks can do to workaround this issue is add html { overflow-y: scroll; }
to your CSS resets, which can be a great way to very easily reduce those content layout shift issues! But this little snippet adds a scrollbar to every page.
To show scrollbars only when they’re needed (while keeping space for the scrollbar if it’s added later) use the scrollbar-gutter
CSS property. scrollbar-gutter
is Baseline 2024 Newly Available, so make sure you enhance it with a @supports
guard.
html {
overflow-y: scroll;
}
@supports (scrollbar-gutter: stable) {
html {
overflow-y: auto;
scrollbar-gutter: stable;
}
}
This would look great in your reset stylesheet.
Related:
3 Comments
Lynn
`scrollbar-gutter` is great, but I don't know if I'd go so far as to argue that everyone should be putting it in their resets. As far as I'm aware, there's currently no way to put *anything* in the space it reserves, which unfortunately makes it awkward to use wit… Truncated
Bramus
As long as you don’t go for `scrollbar-gutter: stable both-edges`, you should be fine. Reason: Chrome has a bug in which the gutter is doubled up on “retina” devices: issues.chromium.org/issues/40064... (The bug is assigned, and I heard engineering will look at it next quarter)
Bramus
There’s still some discussion on how viewports should behave in this case. What the WG did resolve on – but this hasn’t been implemented anywhere (????) – is that top layer content (such as a modal dialog and its backdrop, or a fullscreen video) can draw on top of the reserved s… Truncated