[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?

[frivoal]

How do we know when we can close this issue?

Agenda+ to decide on that.

[bmathwig]

Based on regular user feedback, it's clear that fine grained control over scrollbar elements via the WebKit pseudo selectors creates accessibility problems for end-users. It would be nice to explore other options for styling the scrollbar, but I agree with @frivoal that formalizing the WebKit styling isn't the best solution.

[craigkovatch]

“This property could be used in a way that could cause an accessibility problem” can’t possibly be a criteria for not having the property. Should we also ban “font-size” below 12px, or force the browser to not display “color” values that are not contrasting enough to meet WCAG requirements on the computed background color? Of course not.

I’m happy to concede that formalizing the Webkit properties may not be the best path forward, but I still strongly believe that the very limited set of the current proposal is unrealistically constraining. Scrollbar styling options need to meet the clear and universal use case for which we have ample evidence across the web: consistent branding/theming within a particular page.

[bmathwig]

The difference is that font-size can be adjusted with the Zoom feature of a browser and is not an essential control surface. Scrollbar is different in that it is a primary means to navigate a page.

[craigkovatch]

The argument still doesn’t make any sense. Should we enforce a minimum dimension of 44px for any button element on a mobile user agent as part of the CSS spec? Or ban all :hover styles because they are not keyboard-accessible? This is the wrong place to include such criteria. CSS does not philosophically attempt to prevent authors making mistakes.

[jonjohnjohnson]

@craigkovatch if you need a custom scroll indicator/bar that's beyond what seems to be the majority stakeholder consensus of cost in resources versus benefit across os/browser/env for authors and users, I'd suggest making sure that at least the current work on scroll driven animations will cover your needs.

https://drafts.csswg.org/scroll-animations-1/#scroll-driven-animations

[SelenIT]

The problem that a potentially useful tool can mess up things if misused/abused seems a general problem rather than a specific tool problem. With the color-only approach promoted by the current spec, it's equally possible to make the scrollbar completely uninformative and useless by setting scrollbar-color: black black (let alone the fact that possible inability to handle hover state of the scrollbar thumb is "probably fine").

To me, attempting to prevent web devs from "breaking" the scrollbars usability by restricting the tools more and more, seems to be much like adding more and more armor to the areas with most dots on this famous diagram:

It's absolutely not guarranteed that, being unable to change scrollbar according to design/marketing demands, web developers will leave the native scrollbars untouched and will not try to completely replace them by JS-based workarounds. Which would probably worse for UX/usability than minor visual changes to some native scrollbar parts. We can have a "must"-level warning for authors in the spec (like we have for the order property), browser devtools can automatically check whether scrollbars remain functional or not (like Lighthouse checks the readability of text etc.), and, of course, we should educate designers and promote best practices. But trying to prevent misusing tools by artificially restricting their capacities doesn't seem a very productive way to me.

[css-meeting-bot]

The CSS Working Group just discussed Real-world scrollbar usage, and agreed to the following:

• RESOLVED: With ack of the use-case, we still reject exposing a large set of pseudos for scrollbars (webkit-prefixed or otherwise)

The full IRC log of that discussion

<TabAtkins> Topic: Real-world scrollbar usage
<TabAtkins> github: https://github.com//issues/1969
<TabAtkins> florian: at a high level, both these issues are looking at what's in SCrollbars and saying "controlling width/color is nice, but we want way more, can we have a bunch of pseudos to control things"
<TabAtkins> florian: precisely how they justify it is a little different, the exact set they're asking for is a little different
<TabAtkins> florian: One is following the existing webkit pseudos, the other isn't
<TabAtkins> florian: But both are complaining they're too simple and they want access to the deep structure
<TabAtkins> florian: I believe we've already resolved not to do this, for several reasons
<TabAtkins> florian: Not least that scrollbars are UI and OSes want control over this
<TabAtkins> florian: And OSes have different scrollbar structures, so one way of exposing won't work right for another
<TabAtkins> florian: So we've rejected in the past for these reasons
<TabAtkins> florian: I suggest doing so again
<TabAtkins> florian: We have an intro in the spec explaining why we're not doing this
<TabAtkins> florian: fantasai and I are iterating on it a little
<TabAtkins> florian: But preferred action is making the intro clearer as to why we're rejecting, then close as WONGFIX
<emilio> +1
<TabAtkins> florian: Coutner-argument is that if we do this, we might end up with authors not using scrollbar properties at all, and instead using JS scrolling, which is less accessible
<castastrophe> +1
<smfr> +1
<TabAtkins> florian: But still I think the right way is to close and hope that OpenUI helps us with advanced use-cases
<TabAtkins> +1
<Rossen_> q?
<smfr> +1 in support of what florian proposed
<castastrophe> Sorry, +1 to wontfix
<Rossen_> ack fantasai
<Rossen_> q?
<TabAtkins> fantasai: If we're deciding not to fix this, but webkit continues to ship the pseudos, does that mean we'll eventually need to spec those anyway? or is webkit planning to remove?
<astearns> q+
<TabAtkins> smfr: webkit is phasing them out - we don't support them on iOS
<emilio> q+
<TabAtkins> smfr: And generally slowly removing webkit-prefixed things. At some point in the future these'll probably go away
<Rossen_> ack astearns
<TabAtkins> astearns: Wonder if we're not quite closing wontfix, but "wontfix now"
<TabAtkins> astearns:
<TabAtkins> astearns: ARgument is that people will adopt these props, and won't see a boost in the number of custom scrollbars
<Rossen_> q
<Rossen_> ack emilio
<TabAtkins> astearns: If in the future we see that happenings, great; if not we can revisit. So slightly moderated response
<TabAtkins> emilio: We haven't gotten any compat reports about webkit scrollbars for quite a while.
<TabAtkins> emilio: Pages use them, but for now Firefox hasn't gotten compat issues
<smfr> q+
<astearns> s/, great; if not/
<TabAtkins> florian: Back to alan's point, the use-case of having *some* control over scrollbars isn't being ignored; we're taking steps toward that
<TabAtkins> florian: The idea of a whole pile of pseudos is being rejected
<emilio> q+
<TabAtkins> florian: The idea of doing more than today isn't rejected; we're pretty sure that a bunch of pseudos will never be workable, tho
<astearns> +1
<TabAtkins> florian: I niether want to make these people believe we're rejecting their use-case, nor let them believe if they push a little more we'll relent
<Rossen_> ackk smfr
<Rossen_> ack smfr
<TabAtkins> smfr: emilio said firefox hasn't had compat reports about not implementing, but a lot of Google props are using custom scrollbars
<TabAtkins> smfr: Woudl like info from chrome people about why they're still used, if it's not important on firefox
<TabAtkins> emilio: They use the scrollbar-color as well
<Rossen_> ack emilio
<TabAtkins> smfr: Ah, good. They currently show the scrollbars always next to videos on safari, which looks quite bad.
<TabAtkins> emilio: Note that a bunch of pseudos has some perf implications. We have some internal pseudos that we use, but we'd like to stop that, too.
<TabAtkins> Rossen_: so it sounds like the path forward is to acknowledge the use-case, but this isn't the path to pursue
<TabAtkins> Rossen_: Looks like a lot of +1s in chat for that
<TabAtkins> Rossen_: Anything else?
<TabAtkins> Rossen_: Objections?
<TabAtkins> RESOLVED: With ack of the use-case, we still reject exposing a large set of pseudos for scrollbars (webkit-prefixed or otherwise)

[craigkovatch]

@frivoal thank you for the transparency of posting the log. I appreciate this mention:

florian: Coutner-argument is that if we do this, we might end up with authors not using scrollbar properties at all, and instead using JS scrolling, which is less accessible

But I don't really see it discussed, and this is the real crux of the issue, to me. I am not partial to the webkit pseudos. I just want a good way to do what authors and designers want, without resorting to complicated JS hackery that doesn't scale for componentized single-page-apps.

[SelenIT]

we still reject exposing a large set of pseudos for scrollbars

There seems to be a bit of ambiguity in the current resolution: is it the fact that it's pseudos or the fact that there is a large set of them that is problematic? Are there chances that e.g. just two pseudos (one for the scrollbar track, potentially including arrows if the system UI has them, and one for the thumb — like with the range input) would be OK if this happens to cover >80% of real life usage, or is any number of pseudos a complete no-go? Regarding the performance issues mentioned in the discussion, wouldn't they occur as well if the set of scrollbar-related properties needs to expand to account for hover states and other aspects potentially important for both users and designers that aren't covered with the current draft yet?

Currently, rounded corners of the thumb and its hover state seem to be the most actively used aspects of scrollbar customization that can easily be done with pseudos, but are hard or nearly impossible to do with property-based approach. The latter is quite important for usability (visual feedback that scrollbar is active), and the former may be one of those UI details that are probably not so important for users, but are particularly "sensitive" for many designers, like the infamous "dotted focus ring" of links etc.

And speaking about people not complaining about lack of scrollbar customization in Firefox, the hard truth might be not that they are satisfied with status quo, but that due to Firefox's record low market share its "full support" became not so important, like it previously happened with IE:(

[frivoal]

Whether few or many, browsers currently don't want to expose parts of scrollbars as pseudos. Here are a few assorted reasons:

• Elements (or pseudo elements) have a performance penalty. If the internal structure of a scrollbar is not exposed to the author, browsers are free to make them happen in any way they please, without creating a pile of DOM nodes. This is not equivalent to adding more properties. Those are not cost-less either, but having a whole DOM subtree for each scrollbar isn't an appealing proposition.
• Exposing parts of scrollbars (as pseudos) implies a particular structure to the scrollbar. The more parts, the more likely that the structure isn't actually universal across OSes. Just thumb and track is likely quite robust, but as soon as you get beyond that, you're likely to run into an OS where those parts don't exist, or worse, where they exist but are structured differently. The later is worse because it means author styles created with one platform in mind would have an effect on other platforms, but a different one, not necessarily sensible or even legible
• Would these pseudos be stylable with any amount of regular css? Would their default look-and-feel be created through regular css in the UA stylesheet? If the answer is yes to both, then we're limiting what native scrollbars can look like to what CSS can achieve today. If the answer is yes to the first and no to the second, we need to define how regular css applied to scrollbars interact with whatever magic gives them their native look, and that magic is likely not the same from one platform to another. If the answer is no to the first one, then we need to define exactly what works, what doesn't, and possibly what works-but-not-quite-the-same-way-as-elsewhere, and we'd still need to define the interaction with whatever magic gives them their native look.
• OS vendors and browser vendors (who are sometimes the same) attach a high importance to the usability of the system, which comes in part from a well tuned set of UI controls, for which they insist on consistency, as familiarity helps users figure out how to use the system. This means a high reluctance to giving authors the ability to change UI elements, and scrollbars are one of those. While site authors will frequently want to customize things to better fit their brand and be more distinctive in some way, this can be a disservice to the users if that makes their system less predictable / recognizable, etc. This tradeoff is certainly a matter of degree, but browsers are called user agents for a reason: if there is a tension between author and users, browsers tend to pick what they believe will serve users over what will serve authors.
• Even then, there is a recognition that authors do want more control over scrollbars than is available today. Ability to infulence the thumb/track color and the width is what we're starting with, and it's quite possible there will be more in the future, but so far, there is no browser vendor enthusiasm for a future that involves the ability to apply regular css properties to parts of scrollbars via pseudos

[tabatkins]

Note also that, while it is possible for authors write something user-hostile like scrollbar-color: black black, that's also obviously user-hostile to the author. It's not something they'd write as an intended, useful effect on one platform that just happens to be inaccessible on another platform; it'll ruin the scrollbar's usability on ~approximately every platform.

Intentional, obvious possibility of user harm usually isn't a concern; authors can today write * { color: white !important; background: white !important; } and ruin their pages as well, and we're not trying to stop them from doing so. Accidental, platform-specific possibility of user harm is concerning, because a well-meaning author who just isn't testing very widely can write what looks like good code, and still harm users.

[craigkovatch]

I am really happy with the additional detailed discussion and consideration here. Thanks, @frivoal, @SelenIT and @tabatkins .

[SelenIT]

@frivoal, @tabatkins thanks a lot for such detailed answers!

Indeed, my example of the "solid black scrollbar" was quite nonsensical. What I really thought about was somehing like scrollbar-color: black gray which might look OK and consistent with a dark-themed UI, but confuse users because such scrollbar thumb doesn't provide any visual feedback in hover state anymore (at least, in Firefox 90 on Windows 10, in both light and dark OS UI themes). This seems to be an easy way to slighly break the usability of the native UI part, without any means fo fix it (other than resort to a JS-based custom solution). If only the same two scrollbar parts were available as pseudos (so all platforms whose scrollbars have a track and a thumb would likely be affected to about the same degree), the chance to do the same mistake would be similar, but the fix would be obvious.

The question about default styleability of the pseudos is really tricky, but I assumed that the existing Chrome implementation has solved it somehow (yes, including some "magic", but this is not something new for CSS — styling form controls, including range inputs that look and behave quite "scrollbar-like" on many platforms, still suffers from the same issues). In general, the main reason why pseudo-based approach still may be worth discussing is the fact that it actually works in Chromium, which means for at least ~70% of users. If Chromium also plans to "unship" these pseudos and is not interested in pushing some subset/variation of them to the standards track, than, sure, their fate is sealed. The only thing I still ask for is not to leave authors without any tools to fix things that they can accidentally break with existing tools :)