Csswg-drafts: [css-scrollbars][use-case] Real world product usage

[iamdustan]

Attached is a screenshot demonstrating a subset of the current Webflow Designer scrollbar. This isn‘t intended to be comprehensive of Webflow’s current usage, but is reflective of how much customization is in place. The intent of bringing this up is because the current draft being primarily limited to colors does not sufficiently cover this current usage. (My apologies in this likely being a far cry from proper spec form.)

The following selectors and properties are in use here:

| selector | props |
|----|----|
| ::-webkit-scrollbar | width, height |
| ::-webkit-scrollbar:horizontal | display, border-width |
| ::-webkit-scrollbar-track | background-color, background-clip, border-style, border-color, border-width |
| ::-webkit-scrollbar-track:horizontal | ^-- same |
| ::-webkit-scrollbar-thumb | background-color, border, background-clip |
| ::-webkit-scrollbar-thumb:horizontal | border-width |
| ::-webkit-scrollbar-thumb:hover | background-color |
| ::-webkit-scrollbar-thumb:disabled | background-color |
| ::-webkit-scrollbar-button | display, height, position, background-color, background-image, background-repeate, border-color, border-style |
| ::-webkit-scrollbar-button:hover | background-color |
| ::-webkit-scrollbar-button:disabled | background-color |
| ::-webkit-scrollbar-button:vertical | background-position |
| ::-webkit-scrollbar-button:vertical:hover | background-position |
| ::-webkit-scrollbar-button:vertical:disabled | background-position |
| ::-webkit-scrollbar-button:vertical:decrement | border-width, background-position |
| ::-webkit-scrollbar-button:vertical:increment | border-width, background-position |
| ::-webkit-scrollbar-button:vertical:start:increment | display |
| ::-webkit-scrollbar-button:vertical:end:increment | display |
| ::-webkit-scrollbar-corner | background-color |

[upsuper]

Could you list the complete CSS code here?

From the screenshot, it seems you use display mainly for hiding part of the scrollbar? border-width probably also for hiding borders? I'm not sure what are you using background-position and background-clip for, but the current draft should have met your requirement of background-colors, and width and height is in the plan, I believe.

Using background-image for specifying arrow icon is something we don't want to expose because different OSs do have different style, e.g. macOS doesn't have arrow by default, and Ubuntu's arrows are outside scrollbar and only shown when hovering. Having every component fixed by the spec is something we want to avoid, and it is also usually bad for user experience if scrollbar looks a lot different from native applications.

[upsuper]

What we are seeing is that, the common usecases for styling scrollbars are for changing its color to make it fit into the overall theme of a page / web app. There are also some usecases for narrowing scrollbars to create compact UI.

There are some requests for having greater ability to style scrollbar in different ways, but it is not clear if there is any common pattern, and I don't think sticking to the WebKit model is enough for all those redesigns (see for example, Google Wave's scrollbar). I would think we should provide some API to make it easier for authors to build their own scrollbar in whatever style they want at some point, but that's a different story.

[upsuper]

And for this specific case, it seems to me that just doing coloring is almost enough. I don't see why other properties are really necessary.

[nt1m]

@upsuper Another common use case is hiding the up-down buttons from the scrollbars.

[upsuper]

@nt1m I would argue that is likely either because the WebKit model makes the buttons appear when you style scrollbar, and people don't want them in macOS because it looks different to native style, or people just don't want to bother styling the buttons because that is harder than simply changing the color.

[phistuck]

The overall usage is not low (3+%). You can find metrics for various scroll bar selectors here -
https://www.chromestatus.com/metrics/feature/popularity

[craigkovatch]

Please reconsider your approach here. The people who write webkit are smart people. They didn't add a bunch of superfluous properties. All of those properties exist for a reason, and they are all in-use by a variety of applications.

[frivoal]

Yes, the webkit people are smart, there's no doubt about that, but they have said that this was initially developed for internal, non-multi-platform use, and was accidentally exposed to the web, and that they would like to remove it if they could. They are part of the group of people who approved of working on the spec as it is now.

The webkit approach is more powerful for a single platform, but it is not flexible enough to reliably deal with many platforms, which all have differently structured scrollbars.

This doesn't mean that the spec as it is now is all there will ever be. But more powerful mechanisms need to be able to cope with (in a well defined way) the variety of UIs that different browser on different platforms expose to users.

[craigkovatch]

Thanks Florian. I commented on a number of issues on this spec, including supplying some real-world code from our product. I hope that can be helpful in defining a more robust spec. I'm concerned that starting from the IE5 approach is going to be too limited.

Is your use of "different platforms" about OSes, or e.g. desktop vs. mobile, or?

[frivoal]

Is your use of "different platforms" about OSes, or e.g. desktop vs. mobile, or?

Both. Desktop vs mobile, Windows vs Mac. Gnome vs KDE. KDE 4 vs KDE 5… Chrome vs Edge. There's nothing that forces all of these to have scrollbars that have to same structure.

Defining something generic and powerful is good, but we cannot have a dependency on how scroll bars were structured by a certain browser on a certain OS at a certain date.

[craigkovatch]

But the draft spec starts with a strong dependency on how scroll bars were structured in IE5 in the late 90s. I'm struggling to understand how this could possibly be considered better than the WebKit approach which is quite exhaustive and quite robust. What issues do you see it presenting cross-platform? It's worked great for us.

[litherum]

How do we know when we can close this issue?