[css-scrollbars-1] Add `scrollbar-style` property for `overlay` scrollbars

[arif891]

Summary

Proposal to add a scrollbar-style property to CSS Scrollbars Module Level 1, allowing authors to request overlay scrollbars on Windows. This addresses critical accessibility and user experience issues where developers currently hide scrollbars completely to achieve immersive designs.

Problem Statement

Chrome on Windows uses fixed-width scrollbars that occupy layout space (15-17px gutter). This creates three distinct problems affecting accessibility, cross-platform consistency, and performance:

1. Accessibility Issues: Forced Choice Between Design and Accessibility

Websites with full-bleed hero sections (gradients, images, videos) find that visible scrollbars create visual imbalance. The current workaround is to hide scrollbars entirely using scrollbar-width: none, which removes important navigation cues for users who:

• Rely on scrollbar presence to understand page length
• Have motor difficulties and depend on scrollbar interaction
• Use assistive technologies that reference scrollbar position

Real-world examples hiding scrollbars for design reasons:

• https://www.creativegiants.art
• https://amritpalace.com
• https://untold.site
• https://iventions.com
• https://www.davidalaba.com
• https://www.bittercreek.studio
• https://www.eathungrytiger.com
• https://www.myhealthprac.com
• https://capsules.moyra.co
• https://tobacco.nl
• https://www.graphichunters.com
• https://elementis.co

These are award-winning websites from awwwards.com, demonstrating this is a widespread professional need.

2. Cross-Platform Layout Bugs

Developers working on macOS (which has overlay scrollbars) often don't account for scrollbar width when designing layouts. This causes horizontal overflow issues on Windows where the scrollbar consumes layout space.

Example experiencing overflow:

• https://titangatequity.com (horizontal content overflow due to unaccounted scrollbar width)

3. Performance and UX Issues from Custom Implementations

To achieve overlay scrollbars, some developers implement custom JavaScript-based scrollbars. These solutions:

• Degrade scroll performance
• Provide inconsistent UX compared to native scrollbars
• Often fail to support accessibility features (keyboard navigation, screen readers)
• Break expected browser behaviors

Examples using custom scrollbar implementations:

• https://landonorris.com
• https://silver-pinewood.com
• https://savor.it
• https://blueyard.com
• https://thelinestudio.com

Cross-Browser Landscape

This proposal aims to bring Chrome's Windows behavior in line with other major browsers:

• Firefox on Windows: Uses overlay scrollbars by default
• Safari/WebKit: Uses overlay scrollbars across all platforms
• Chrome on Windows: Uses fixed scrollbars in gutter (outlier)
• Chrome on macOS: Uses overlay scrollbars (system default)

The inconsistency creates cross-platform development challenges and forces developers to choose suboptimal workarounds.

Proposed Solution

Add a new CSS property to control scrollbar rendering behavior:

scrollbar-style: auto | overlay

Values

• auto (default): Current behavior. Scrollbar is rendered in the scrollbar gutter and affects layout.
• overlay: Scrollbar renders over content without affecting layout, similar to macOS behavior. Scrollbar auto-hides when not in use.

Example Usage

Instead of hiding scrollbars completely:

/* Current problematic approach */
:root {
    scrollbar-width: none; /* Hides scrollbar, breaks accessibility */
}

Developers could use:

/* Proposed solution */
:root {
    scrollbar-style: overlay;
    scrollbar-color: rgba(0, 0, 0, 0.3) transparent;
    scrollbar-width: thin;
}

This maintains scrollbar functionality while achieving the desired visual effect.

Applicability

The property should apply to any scrollable element:

/* Works on root */
:root {
    scrollbar-style: overlay;
}

/* Works on scrollable containers */
.scrollable-panel {
    scrollbar-style: overlay;
    overflow: auto;
}

Benefits

1. Accessibility: Scrollbars remain visible and functional, preserving navigation cues
2. Cross-browser Consistency: Aligns Chrome behavior with Firefox and Safari
3. No Breaking Changes: Default value auto maintains current behavior
4. Performance: Eliminates need for JavaScript-based scrollbar implementations
5. Developer Experience: Reduces cross-platform bugs and testing burden
6. User Choice: Developers can choose appropriate behavior per design context

Specification Integration

This property fits naturally into the CSS Scrollbars Styling Module Level 1, which already defines:

• scrollbar-width: Controls scrollbar thickness
• scrollbar-color: Controls scrollbar colors

The scrollbar-style property would complement these by controlling rendering behavior.

Interaction with Existing Properties

/* Complete scrollbar styling */
.element {
    scrollbar-style: overlay;          /* Rendering behavior (new) */
    scrollbar-width: thin;             /* Size (existing) */
    scrollbar-color: #888 transparent; /* Color (existing) */
}

Interaction with scrollbar-gutter

scrollbar-gutter reserves space for scrollbars. With scrollbar-style: overlay, the gutter would not be used since the scrollbar renders over content. Consider:

.element {
    scrollbar-style: overlay;
    scrollbar-gutter: stable; /* Should this be ignored? */
}

Suggested behavior: When scrollbar-style: overlay is set, scrollbar-gutter values other than auto should have no effect, since overlay scrollbars don't need reserved space.

Open Questions

1. System Preferences: Should scrollbar-style: overlay respect Windows "Always show scrollbars" setting?

   • Suggested answer: Yes, system accessibility preferences should override author styles

2. Default Value: Should there be a system value that defers to OS defaults?

   scrollbar-style: auto | overlay | system
   

   Where system would use overlay on macOS/Linux and auto on Windows by default?

3. Auto-hide Behavior: Should overlay scrollbars always auto-hide, or should there be control over this?

4. Scrollbar Track: For overlay scrollbars, should the track be visible at all times, or only on hover?

5. Transition States: Should there be author control over fade-in/fade-out timing for overlay scrollbars?

Implementation Considerations

For Browser Implementers

• Overlay scrollbars should auto-hide when not actively scrolling
• Should appear on hover over scrollable area
• Should respect system accessibility settings (e.g., "Always show scrollbars" on Windows)
• Should support both mouse and touch interactions
• Should work with existing scrollbar-width (thin/auto) and scrollbar-color properties

Testing

Test cases should verify:

• Layout is unaffected by overlay scrollbars (no reflow)
• Scrollbars remain accessible via keyboard and assistive technologies
• System accessibility preferences override author styles
• Interaction between scrollbar-style, scrollbar-width, and scrollbar-color
• Behavior with nested scrollable containers
• RTL (right-to-left) language support

Alternatives Considered

1. Extend scrollbar-width

scrollbar-width: none | thin | auto | overlay;

Rejected because: scrollbar-width is about sizing, not rendering behavior. Mixing concerns reduces clarity.

2. Use scrollbar-gutter

scrollbar-gutter: stable overlay;

Rejected because: scrollbar-gutter is about reserving space, not controlling rendering mode. The property already has defined behavior that doesn't align with this use case.

3. Browser-specific prefixes

-webkit-scrollbar-style: overlay;

Rejected because: This is a cross-browser need requiring standardization, not a proprietary feature.

4. Do Nothing (Status Quo)

Rejected because: Forces developers into accessibility-hostile workarounds (hiding scrollbars) or performance-degrading custom implementations.

Privacy and Security Considerations

No anticipated privacy or security concerns. This property only affects visual rendering of scrollbars, not their functionality or data access. Similar to how scrollbar-color and scrollbar-width don't introduce security concerns.

Stakeholder Feedback

This proposal is informed by:

• Analysis of 18+ award-winning websites demonstrating current workarounds
• Cross-browser behavior analysis (Firefox, Safari already support overlay scrollbars on Windows)
• Accessibility considerations (maintaining scrollbar visibility)
• Performance considerations (avoiding custom JavaScript implementations)

Related Issues and Discussions

References

• CSS Scrollbars Styling Module Level 1
• MDN: scrollbar-width
• MDN: scrollbar-color
• MDN: scrollbar-gutter

Conclusion

The scrollbar-style property addresses a real pain point in modern web design by providing a standards-based solution for overlay scrollbars. This eliminates the current forced choice between visual design and accessibility, aligns Chrome's behavior with Firefox and Safari, and removes the need for performance-degrading custom implementations.

We believe this addition would significantly benefit the web platform and respectfully request the CSS Working Group's consideration.

---

Note: I'm happy to provide additional information, write specification text, or help with test cases if this proposal moves forward. Thank you for considering this feature request.

[frivoal]

Thank you for the very detailed write-up.

My main concern would be that this makes it too easy for authors to override the preference of users. When users have deliberately set their system-settings to non-overlay scrollbars, having the author replace those with overlay scrollbars can be frustrating. The proposal here says:

1. System Preferences: Should scrollbar-style: overlay respect Windows "Always show scrollbars" setting?
   • Suggested answer: Yes, system accessibility preferences should override author styles

However, I am not sure how we can tell apart a system+browser's default setting to show non-overlay scrollbars, which the user may very well like, from a user who has changed their settings to show non-overlay scrollbars.

For instance, I use Firefox on macOS, and I've changed my settings to use non-overlay scrollbars. The answer above suggests I'd get to keep those even if the author had set scrollbar-style: overlay, because system accessibility preferences should override author styles. However, when I use chrome on windows, scrollbar-style: overlay would win over the default of non-overlay scrollbars, even though I have the same preferences.

[Loirooriol]

This is basically like the old overflow: overlay, which wasn't much liked by browser vendors and got removed. https://github.com/w3c/csswg-drafts/issues/6090

[arif891]

That is an excellent point and a very important clarification. My apologies for mixing up browser defaults and system preferences, especially regarding Firefox on Windows.

You are correct: the risk is that the author's scrollbar-style: overlay would override what is essentially an accessibility preference for a fixed scrollbar, regardless of whether that preference comes from the OS or a browser setting.

Proposed Hierarchy for Scrollbar Rendering

To ensure User Accessibility Intent always wins, we must define the behavior hierarchy as follows:

1. Highest Priority: User Preference Override
   • If the user has enabled a setting (either in the OS like "Always show scrollbars" on Windows, or in the browser like Firefox's "Always show scrollbars" setting) that indicates a desire for a fixed/non-overlay scrollbar, the author's scrollbar-style: overlay must be ignored, and a fixed scrollbar must be rendered.
2. Second Priority: Author Request
   • If there is no explicit user preference for a fixed scrollbar, then scrollbar-style: overlay is respected, and an overlay scrollbar is rendered.
3. Lowest Priority: Browser Default (Implicit Intent)
   • If scrollbar-style is auto (or if it defaults to an implicit value), the browser renders its platform-specific default (overlay on macOS/Firefox, fixed on Chrome/Windows, etc.).

This hierarchy ensures that users who rely on the fixed visual presence of a scrollbar are never disadvantaged by an author's stylistic choice, while still giving authors the tool they need to solve the cross-platform layout issues on Chrome/Windows when a fixed scrollbar is not explicitly requested by the user.

Does defining this strong User Preference Override clarify the desired behavior and address your concerns about authorship overriding user accessibility settings?

[PavelLaptev]

Regarding the "System Preferences" question, that isn't always the best baseline.

For example, in Electron or Tauri apps, we are building standalone applications where we need full control over the UI. The OS settings shouldn't automatically override the design choices we make for that specific app environment.

Also, without this property, developers are forced to use heavy JS workarounds to achieve overlay scrollbars. This is bad for performance and often buggy, especially when dealing with complex lists.

It’s really a pity that the old functionality was removed.

[frivoal]

The OS settings shouldn't automatically override the design choices we make for that specific app environment.

This is very debatable. App developers tend to prefer tweaking everything their way, to make the design of the app itself more coherent. But that results in a lack of consistency between apps across the system, which isn't always to users' tastes, which is why OS vendors tend to prefer making such things system-wide settings, and to avoid giving app developers a choice.

[PavelLaptev]

Sure. But by refusing to provide a standard CSS property for overlay, the CSSWG is not protecting users. it is driving developers toward worse solutions that actively harm accessibility. If we provide scrollbar-style: overlay, the browser remains in control of the interaction (handling hover, drag, and focus) rather than delegating it to buggy JavaScript libraries. Developers are voting with their code.

[benface]

I think the real problem is that the OS should have separate options for "prefer fixed scrollbars" and "force fixed scrollbars".

[alexdln]

But why system settings are such a priority?

A website isn't a system application. Many websites even create their own scrollbar, and that's fine.

So, system settings are preferences that a website can respect or not. Just like with the theme, fonts, animations, etc.

So, this property should have the options auto (unset?), visible, and overlay. The system option is unnecessary, since it's auto (like, for example, the scrollbar color, which is determined automatically based on the theme).

There should be a media query that specifies system preferences (sth like @media (prefers-scrollbar-style: visible) ). And if the website author who uses scroll customization wants to, they can configure this property from the system preferences on the website. This is useful not only for the current property but also for custom scroll bars

html,
html.scrollbar-overlay {
    scrollbar-style: overlay;
}

.scrollbar-visible {
    scrollbar-style: visible;
}

@media (prefers-scrollbar-style: visible) {
    scrollbar-style: visible;
}

[bramus]

FWIW: Since we already giving authors a way to hide scrollbars altogether (using scrollbar-width: none) we might as well allow them to change the scrollbars to an overlay type of scrollbar. It‘s something I personally would love to see.

Allowing authors to change classic scrollbars to overlay scrollbars feels like a safer thing to do than having authors hide the scrollbar and then (hopefully) have them inject a script that fakes an overlay scrollbar (or inject other things that indicate the box is scrollable). Switching classic to overlay scrollbars at least retains the affordance that the box is scrollable, whereas scrollbar-width: none does not out of the box.

The following UI (source) for example would benefit a lot from this:

If UA’s really want to always show a thumb when the user has scrollbars set to “Show always” yet the site has indicated they want overlay scrollbars, then #7421 could help, as the UA could then force apply scrollbar-mode: visible in that case.

[PavelLaptev]

So, system settings are preferences that a website can respect or not. Just like with the theme, fonts, animations, etc.

Yeah. We already have the option to remove the scrollbar using width: 0 and to customize the thumb and track etc, so it doesn’t matter what system settings the user has. So I don’t understand why we can’t have a feature that lets the scrollbar overlay the content.

[emilio]

There's another assumption that is that all OSes have a reasonable way of displaying an overlay scrollbar. This is now more and more the case, but browsers have to make it up otherwise. E.g. on Windows 10 there's no native overlay scrollbar, so we'd need to do something like faking a Win11 scrollbar or so.

@bramus I'd say that the issue there is that Chrome doesn't ship overlay scrollbars on Windows. They've been the default on Windows 11 for a while... :)

[emilio]

To clarify... Chromium-based browsers don't seem to honor the system setting on Windows (Firefox does), and that seems like something that could be addressed and would improve the expected rendering of the UI above while not harming users that prefer always-visible scrollbars...

[emilio]

(And without introducing inconsistent scrollbar styles for users)

[bramus]

There's another assumption that is that all OSes have a reasonable way of displaying an overlay scrollbar. This is now more and more the case, but browsers have to make it up otherwise

My assumption here would be that if a platform doesn’t support a specific type of scrollbars, then it shouldn’t show it (unless the UA really wants to plug that hole). For example, forcing classic scrollbars on iOS wouldn’t (and imho shouldn’t) have any effect as that platform does not support that type of scrollbars.

I'd say that the issue there is that Chrome doesn't ship overlay scrollbars on Windows. They've been the default on Windows 11 for a while... :)

Good news: Microsoft is contributing (Overlay) Fluent Scrollbars to Chromium. At this point it’s still behind a flag, though (chrome://flags/#fluent-overlay-scrollbars)

[arif891]

Update: I have filed a feature request in the Chromium project to explore exposing their existing internal overlay scrollbar implementation (currently behind chrome://flags/#overlay-scrollbars) via this proposed scrollbar-style property.

Chromium Issue: Feature Request: Expose Overlay Scrollbar Control to Web Authors (481353071)

I believe having an implementation path already existing in the engine (via flags) makes this a strong candidate for a prototype implementation of this proposal.