Chrome 121 Broke My CSS By Adopting New Scrollbar Properties

Murtuzaali Surti
Murtuzaali Surti

• 3 min read

Updated On

Recently, in version 121, Chrome started supporting standardized CSS scrollbar properties scrollbar-color and scrollbar-width mentioned in the CSS specification and it broke my CSS. Here's what happened and how I fixed it.

TLDR — Quick Fix:

/* Wrap new scrollbar properties in @supports rule for browsers without `::-webkit-scrollbar-*` support */
/* This way chrome won't override `::-webkit-scrollbar-*` selectors */
@supports not selector(::-webkit-scrollbar) {
  html {
      scrollbar-width: thin;
      scrollbar-color: var(--thumb-color) var(--track-color);
  }
}

I always feel scrollbars on a website seem off if the site is designed with consistency and a little bit creativity. They don't always match the theme of the site. Some people prefer it that way and that's okay but I want scrollbars to feel like an integral part of the website itself. And so, I styled the scrollbars for syntackle a while ago to match the current theme.

Back then, Chrome didn't support scrollbar-color and scrollbar-width properties but it did have the ::-webkit-* pseudo selectors exposed, so I used them to create a custom scrollbar experience. But webkit is only supported on Chrome and Safari, not firefox. To mitigate this, I resorted to the new scrollbar properties for firefox.

html {
    scrollbar-width: thin;
    scrollbar-color: #6d7c77 #cfd7c7;
}

body::-webkit-scrollbar {
    width: 0.5rem;
}

body::-webkit-scrollbar-thumb {
    background-color: var(--tertiary-color);
    border-radius: 0.7rem;
}

body::-webkit-scrollbar-track {
    background-color: var(--primary-color);
    border-radius: 0.7rem;
}

The reason I attached the ::-webkit-* pseudo selectors on the body is that I control the theme of the site using CSS variables on the body element and by altering the CSS classes through javascript.

And this broke the scrollbar styling with Chrome 121. It seems that Chrome now prefers the new scrollbar properties on the html element over the ::-webkit-* pseudo selectors.

One thing that you could do is attach the new scrollbar properties to the body element instead of html, it works in Chrome but firefox doesn't seem to support that.

body {
    scrollbar-width: thin;
    scrollbar-color: #6d7c77 #cfd7c7;
}

I researched a bit online and found out that recently Chrome published a blog post related to this change. There's a whole topic of overlay scrollbars and the impact of operating system on the scrollbar which you can deep dive into. But a quick fix which you can do is for the browsers that don't support ::-webkit-* pseudo selectors, add a @supports rule check and add the new scrollbar properties there.

body::-webkit-scrollbar {
    width: 0.5rem;
}

body::-webkit-scrollbar-thumb {
    background-color: var(--tertiary-color);
    border-radius: 0.7rem;
}

body::-webkit-scrollbar-track {
    background-color: var(--primary-color);
    border-radius: 0.7rem;
}

/* Browsers without `::-webkit-scrollbar-*` support */
@supports not selector(::-webkit-scrollbar) {
    html {
        scrollbar-width: thin;
        scrollbar-color: #6d7c77 #cfd7c7;
    }
}

For me, I still like to have control over the scrollbar styling and that's why I prefer webkit pseudo selectors over new properties but that's just a personal preference. The CSS specification considers exposing ::-webkit-* pseudo selectors as a mistake and have standardized the styling of scrollbar because of different platforms implementing it in different ways.

"Providing too much control would allow authors to get perfect results on some platforms, but at the expense of broken results on others." - drafts.csswg.org

With that being said, I am not encouraging you to use the webkit selectors and you should always look out for standardized properties first and see if that works for you.


rssed — An RSS Feed Reader And Blogroll - Built Using Astro

Previous

Issue With Watching File Changes in Docker

Next