Lea and I looked at this in the TAG Virtual F2F breakout:

• We'd like to see screenshots from different platforms and/or dark mode to make sure this generalizes well - scrollbars look ver different on Windows where there are arrow buttons that have hover effect and can be pressed. Also they look different when two scrollbars meet
• Maybe allow auto instead of either of the <color>'s to auto-generate the other with proper contrast.
• Control over scroll indicator vs scrollbar. What if I want a scroll indicator but not a scrollbar? (scroll indicators are painted over the website and auto hidden, scrollbars are always there). Some developers don't like scrollbars that take up space as they can change rendering when they appear and disappear, like on YouTube where scrollbar can appear because you open the drawer, ending up resizing all thumbnails. Slack as one example turns off naive scrollbars and draws their own scroll indicators which we would like to avoid as it can have a performance penalty. We think a third property is needed to control this distinction.

Windows:

Slack custom scrollbar

iOS (indicator only appears when you scroll)

Hi, @kenchris,

Thank you very much for your comments. I apologize that it has taken me a few days to address them.

Point 1 is a reasonable request. It is important to know whether authors can be confident that those values will deliver similar outcomes across different systems. As far as I have seen, there isn't a good visual reference for the light and dark values yet. The specification leaves a lot of room for implementors in terms of visual style, but the one browser that has implemented the feature so far (Firefox) does not support light and dark.

As for point 2, I have already opened an issue along similar lines: https://github.com/w3c/csswg-drafts/issues/5651

My proposal would be that, when only one color is provided to scrollbar-color, it would be used by the UA to automatically create a color scheme for the scrollbar (to "tint" it, so to speak). This would allow authors to easily style scrollbars while ensuring adequate accessibility.

Another advantage I see for the "tint" semantic is that it is more flexible in case the scrollbar has more (or fewer) visual elements than a track and thumb.

Regarding point 3, as I understand it this functionality has been intentionally kept out of the specification because of lack of consensus, one reason being that on some operating systems the type of scrollbar (static or overlay) responds to a user preference.

Nevertheless, there is recognition that in some cases authors have strong reasons to implement their own scrolling solution: for those cases, scrollbar-width: none was proposed as a way to avoid the hacks that authors were (and are) resorting to in order to hide the native scrollbar.

When authors would like to prevent changes in their layout as scrollbars appear and disappear, like in your YouTube example, a good solution could be the scrollbar-gutter property.

Hi there, we looked at this in the TAG breakout today

Scrollbars are everywhere on the web and one of the things developers are struggling with when making applications feel native.

We are sad to hear that there is lack of consensus but we would still like this to be pursued. Maybe as part of Open-UI? https://github.com/WICG/open-ui @gregwhitworth

No one on the TAG breakout was aware of scrollbar-gutter (maybe it was discussed before, but no one seems to remember) but it feels like something that should be reviewed as part of this (cc @dbaron).

That spec also doesn't list the use-cases behind scrollbar-gutter which would have been quite useful and generally required per review.

Nevertheless, there is recognition that in some cases authors have strong reasons to implement their own scrolling solution:

Same in this above case. Let's hear the use-cases and see what is the best approach to solve them, even if that is for people to brew their own scrolling solution.

Thank you for your comments, @kenchris .

scrollbar-gutter was reviewed by TAG in https://github.com/w3ctag/design-reviews/issues/520 and there is an explainer at https://github.com/felipeerias/scrollbar-gutter-explainer

Regarding the CSS Scrollbars spec, as I understand it the intention was to provide a simple way to cover most of the customizations that authors are already doing, while avoiding the complexity of ::-webkit-scrollbar and other non standard solutions.

For example, in the case scrollbar-width: none the two main use cases (again, as I understand it) are:

• the site wants to use a scrollbar that is very different from the default (colors, sizes, effects, interaction, etc.)
• the site wants to offer a different way to scroll through the content (e.g. image carousel) and having a scrolling container underneath is just a convenient implementation detail.

In both cases, authors are already using different hacks to hide the default scrollbar so they can implement their own solution.

There are some more materials regarding the use cases behind the spec (for example), I guess it would be a good idea to compile them and extent that section of the explainer in https://github.com/felipeerias/css-scrollbars-explainer

Hi @felipeerias - thanks for that and sorry for our snafu regarding the scrollbar-gutter review. Yes, I think it would be a good idea to bring those use cases into the explainer. We're continuing discussion on this and should have more for you soon.

Hi @felipeerias, I've recently joined the OpenUI initiative and my goal is to try and work a bit on how to bring a little more standardization to scroll UI.

My first two goals are the following:

1. Make it easy to get rid of any native chrome while keeping all user interactions. That way devs can easily create their own scroller chrome.
2. Make it easy to style scroller chrome as generated by the browser. I'll call this 'native chrome' for now.

The first point should be fully covered by the scrollbar-width property, really great and simple approach. I love it.

The 2nd point is partially handled with scrollbar-color, but it isn't really a very granular approach. I think that's it's strength though, because it doesn't go off into the weeds on all the various ways different browsers and OS's implement scroll UI elements.

Personally, I envision a future where OpenUI could define a small range of scroll-ui components. These could be a full scrollbar with buttons, a simple indicator, an arrow button (such as listed here: https://github.com/WICG/open-ui/issues/105), etc.

As far as I can see the current suggested styles that are part of CSS Scrollbars don't clash with this in any way, so that's great. The only thing that might be worth considering is the naming of the scrollbar-color property. It might be worth-while to rename it to something like scroll-ui-color or scroller-color, just so it doesn't sound like it necessarily needs to be limited to scrollbars only.

I find it hard to judge if the naming issue is important or entering into bike-shedding territory, so I'm definitely very open to feedback on that point.

The scroll-gutter property is completely new to me, but definitely sounds interesting. I'll have to dive into that before I'm able to give any sensible feedback about it though. I'll do my best to get back on that later today, if time allows.

Alright, I'll try to give some initial feedback on the scroll-gutter property. I've only just familiarized myself with the explainer (https://github.com/felipeerias/scrollbar-gutter-explainer) and the match-parent flag (https://github.com/w3c/csswg-drafts/issues/5232). I may very well be unaware of other relevant discussions. Please feel free to direct me to other issue as necessary.

There are a few things I noticed which don't appear to have been covered in the explainer yet:

positioning of nested elements

I noticed the explainer doesn't appear to define exactly how nested elements will be positioned inside a container with a scroll-gutter.

For example: Say I have a container element with position: relative and a child element inside it with position: absolute; bottom: 0px; right: 0px. Currently, this would position the child element at the bottom-right corner of it's parent such that the outer edges of the child element (including it's borders) align with inner edge of the border of the parent element.

How would such a child element be positioned if the parent control has a scroll-gutter? Does the child element remain aligned with the inner edge of the parent's border or does it align with the inner edge of the gutter?

I'm partial to aligning the child with the inner edge of the gutter. Mostly because one of the big reasons to have a scroll-gutter at all is to keep an overlay scrollbar from being drawn on top of any content.

However, I do think we should also give people an easy way to align such a child element with the inner edge of the container's border. Unfortunately this brings about the problem mentioned here: https://github.com/w3c/csswg-drafts/issues/5232#issuecomment-648047604

I can think of two possible approaching to solving this:

• Figuring out some kind of css unit that matches the width of the gutter. The value of such a unit would be contextual, much like rem.
• A new css property that defines which box a child element should aligned itself with (content-box, padding-box, gutter-box, border-box).

background-clip

I also noticed the explainer doesn't appear to define how the gutter should apply to the background-clip value. Perhaps we could add an additional value there such as background-clip: scroll-gutter-box?

I just realized that if we're going to make it easier for devs to create their own custom scroll chrome (such as when setting scrollbar-width to 0), that might also need to be taken into consideration with scroll-gutter.

I don't have any time left to think this through today, but I figure it's worth mentioning in case anyone has some great ideas about this already.

I've had a night to sleep on this and I have some additional thoughts:

There is a real need from developers to be able create their own custom scroll UI. This means we shouldn't make too any assumptions about the dimensions of scroll chrome. We can't expect the width of a custom vertical scrollbar and the height of a custom horizontal scrollbar to always be the same. If we consider different types of UI (such as a carousel for example) the requirements will potentially be very different from native scrollbars as well.

With this in mind, I would propose that we treat the scroll-gutter as an extra 'shell' in the box model. One that lives in between the padding and the border. I realize this is a big change, but I think it will be worth it.

Just as we have a single border-width property that applies to all borders and separate border-bottom-width, border-left-width, border-right-width and border-top-width, I think it would make sense to have a scrollbar-width property as well as scrollbar-bottom-width, scrollbar-left-width, scrollbar-right-width and scrollbar-top-width properties.

Additionally, if devs are going to use scrollbar-width: 0px to hide native chrome, they may still want to be able to make use of a scroll-gutter, to make room for their own custom UI elements. With that in mind, I think it would make sense to give devs the ability to apply explicit dimensions to the scroll-gutter as well. So we'd have a scroll-gutter property as well as scroll-gutter-bottom, scroll-gutter-left, scroll-gutter-right and scroll-gutter-left properties.

We could keep the auto and thin values currently proposed for scrollbar-width and make them applicable to scroll-gutter as well. This would allow styles such as the following:

.native-scrollbar-scroller {
    scrollbar-width-right: auto;
    scroll-gutter-right: auto;
    
    scrollbar-width-bottom: thin;
    scroll-gutter-bottom: thin;
}

.custom-carousel-scroller {
    scrollbar-width: 0px; // hide native chrome
    scroll-gutter-bottom: 4px; // room for an indicator at the bottom
    scroll-gutter-left: 1.5rem; // room for a button on the left
    scroll-gutter-right: 1.5rem; // room for a button on the right
}

This would eliminate a lot of the complexities that lead to the need for a scroll-gutter css unit as well. Devs can instead just use existing units to set the desired dimensions explicitly. Browsers could still implement their own default scrollbar width like they do now and that would be enough to maintain backwards compatibility.

Finally, for the sake of simplicity I would like to suggest we drop scrollbar-width: thin all together. It seems to me the choice between scrollbar-width: auto and scrollbar-width: thin is ultimately a design decision, so asking for an explicit value rather than some magic value probably isn't a big deal.

Oops, I see I totally forgot to specify something very important. The defining property of a gutter-box should be that scroll chrome always gets rendered as an overlay on top of the gutter.

As we continue to review this proposal it appears @Rayraz is raising a number of good questions that could affect your overall design. @felipeerias I would encourage you to redirect the discussion back to the CSS issues to get broader community feedback. Please bring back any new learnings that might alter this design when ready.

Thanks @atanassov for joining in. To be honest I was a bit worried I might've ground things to a hold by suggesting an extension to the box model. I'm very much in favor of reopening the discussion around CSS Scrollbars.

In reviewing the whole thing again I just now realized there may be a far simpler approach which may not have been discussed yet. We could drop scroll-gutter completely in favor of something like: scrollbar-position: fixed; and scrollbar-position: overlay;.

If we combine scrollbar-position with scrollbar-width existing padding styles will do the job just fine.

I also imagine it'll be a lot less work for browsers to implement compared to both @felipeerias's scroll-gutter proposal or my earlier suggestion to extend to the box model.

We took another look at this during this week's meetings, and we are happy with the direction this proposal is going, so we are going to go ahead and close this. If/when there are substantive changes, feel free to open another review request.

@LeaVerou, when you say the TAG is happy with the direction this proposal is going, is there a preference for a particular direction? These are the 3 directions I'm aware of:

1. @felipeerias' initial proposal
2. My suggestion for extending the box model
3. My suggestion for a scrollbar-position property

Progress on this issue has been slow the past 2 months and I'd like to speed things back up if possible.

Hi @Rayraz,

We are happy with the original proposal which we were asked to review, and @felipeerias successfully addressed the few concerns we had. You raised a few additional issues, and @atanassov directed you to post them in the CSS WG repo to get broader community feedback.

The TAG design review is — as the name suggests — a review, and is not suitable for unstructured brainstorming and iterative design, which should happen in the venue a proposal is incubated in (in this case, the CSS WG repo). The TAG is a small group and we do not generally have the bandwidth to engage in such brainstorming. Also, the TAG design review is generally more high level, and not a substitute for the kind of deep review and iterative design that happens in the WG itself.

Please raise these issues in the CSS WG repo, iterate on the proposal there, and open a new design review when there are substantial changes, then we could take another look. Does that make sense?

Thanks @LeaVerou, that makes sense. I'm new to this so I'm still figuring out the correct procedures. I'll go and have a look in the CSS WG repo and see if I missed anything important.

@kenchris See https://github.com/w3c/csswg-drafts/issues/6090 wrt overlay scrollbar controls. Also I'm not sure why posting comments to the CSSWG here considered is a good idea, if Lea hadn't linked this issue from an existing CSSWG issue, it's unlikely the rest of us would see it.

@fantasai, I was posting in the wrong place too. Mostly because as someone completely new to participating on CSS standards it is not obvious at all where I should be contributing. Or at least it was not obvious to me, not even after attempting to ask around in order to find out where to start.

I didn't say anything about it when Lea pointed it out to me, mostly because I assumed it was an error on my part at the time and did not want to sound negative. However, since I'm apparently not the only one who's in the wrong place, maybe it's helpful I speak up?

To be honest it has been demotivating to spend ~2 months wondering why I didn't receive feedback, questioning if my contributions might be sub-par only to find out everyone else had simply been racing along somewhere else for 2 months.

I have not checked up on progress since May 1st, so I don't know if everyone is still running with the scrollbar-gutter proposal and all that. Personally, I find it wildly complicated and a completely unnecessary.

I'd much rather see things headed in a direction where scroll-gutter is scrapped and a way to force overlay scrollbars gets implemented instead. The already existing padding box can double as a scroll-gutter provided the scrollbars can simply set to overlay in any browser/device (not just mobile ones). Meanwhile, fixed scrollbars can be keept around to keep the old-school way of doing things around for backwards compatibility.

If you feel it may still make sense to throw that idea in the mix (if someone else hasn't already done so in the mean time), I can try and make an effort to share it in the correct place. Someone else would probably have to be willing to adopt it and run with it though, because I likely won't be able to spend significant time participating until late September.

@Rayraz It may take time to parse, but here is a comprehensive discussion on why overlay scrollbars don't have much of a chance at implementation and why/how scrollbar-gutter is thought to be the least worst option.

https://github.com/w3c/csswg-drafts/issues/92

@jonjohnjohnson thanks for pointing it out. It's much appreciated. I'm curious what made scrollbar-gutter the least worst option, so I will definitely take a serious look at it at my earliest convenience.