[css-scrollbars] `scrollbar-width` should support custom measurements

[WesleyBranton]

SPEC: https://drafts.csswg.org/css-scrollbars-1/#scrollbar-width

The current spec only allows auto, thin and none for the scrollbar-width CSS property. The property should also support custom measurements in regular size units (px, pt, em, vw, ...).

Since the auto width is decided by the operating system and some operating systems do not provide a way for the user to adjust the appearance of the scrollbars (or at least have that ability hidden in some more tech-savvy area). The consequence of this is that if your OS has very thin scrollbars, there's no way to increase the width of the bars using CSS. This could be detrimental to users with certain accessibility issues.

My add-on Custom Scrollbars regularly receives email complaints about this ability not being available. The spec that Chromium-based browsers are using supports custom measurement units.

[rootwork]

A big +1 for me on this request, in particular as a way to support accessibility.

[tabatkins]

This property originally just took a length, exactly as you suggest. During review, multiple browser implementors objected to allowing arbitrary sizes, as it would interfere with usage of the browser-default scrollbars. The current three-value design is a compromise allowing some control (particularly for the primary requested use-case, narrow scrollbars) while still respecting the implementor's objections.

[WesleyBranton]

This property originally just took a length, exactly as you suggest. During review, multiple browser implementors objected to allowing arbitrary sizes, as it would interfere with usage of the browser-default scrollbars. The current three-value design is a compromise allowing some control (particularly for the primary requested use-case, narrow scrollbars) while still respecting the implementor's objections.

With all due respect, Chromium browsers are doing just fine with their approach that allows the width to be a custom value. I think there's a huge accessibility issue by not allowing the width to be widened, since on Mac and most Linux distributions, there's virtually no difference between thin and auto. This is detrimental for users with certain accessibility needs, as it's a pretty small target to hit.

At the very least, there needs to be another option added that's simply "wide" and is displayed at about 15px wide. The current "auto" option is inconsistent between platform. Having a "wide" option that's a standardized size (much like "thin") would perhaps be a better compromise to allowing custom width.

Having a project that works directly with the scrollbars, I can say that the lack of support for custom widths (or even consistent widths) is a complaint I get on a nearly daily basis.

I sincerely think that W3C's approach on this issue should be re-evaluated.

[jonjohnjohnson]

@WesleyBranton I think you may find more headway petitioning specific vendor engineers? Maybe here's a good place to start? https://github.com/w3c/csswg-drafts/issues/1958#issuecomment-409678045

Also, you might find this discourse around custom scrollbars worthwhile? https://github.com/w3c/csswg-drafts/issues/1960#issuecomment-400140259

[maverick74]

Wouldn't this bring users more privacy? Since the size of the scroolbar is identifiable of the browser being used?

[frivoal]

Chromium browsers are doing just fine with their approach

W3C's approach on this issue should be re-evaluated.

Note that W3C isn't making up its own approach, independently of or against the wishes of Chromium browser engineers. W3C is a venue for discussing things, not a source of opinions, and those expressing this position are the engineers working on Chromium (and other browsers).

[missouriwind]

Whoever needs to read this - somebody needs to listen to the users. The small scollbars are very difficult to use. Please do something to make them wider.

[vbmark]

This might be of interest. It worked for me.

https://www.askvg.com/tip-restore-full-classic-scrollbars-in-mozilla-firefox-on-windows-11/

[hg42]

I am one of the users of scrollbar add-ons / user style sheets and also a developer with some focus on usability.

My main point is: Scrollbars (should!) show how much content is visible (including if there is more), and they should be draggable.

This also means, the width (and also the min length of the thumb) should be under control of the user, just like the font size.

Important: Unlike Buttons on a web page, the scrollbars don't zoom! This is another problem with accessibility, and it might be related to the lack of a numeric width.

If scrollbar-width can't be specified in units, it's not possible to override the width by a user style sheet or an add-on or a browser setting.

Adding it would

• allow web page developers to specify their preferred size
• allow the user/browser to override it

which means both worlds are happy like it is for fonts and similar elements.

Instead now, it's inconvenient for both parties.

Also, scrollbar-width simply doesn't follow other width specifications. It's kind of non-standard in my opinion. If I read "width" I shouldn't have to read a document to set one.

I don't see any good reason against it.

Especially this one is kind of weird (meant in the direction of browser implementors, thanks to @tabatkins for telling us):

Multiple browser implementors objected to allowing arbitrary sizes, as it would interfere with usage of the browser-default scrollbars

It's quite similar to the situation for fonts or buttons or anything else. I think the same solutions should be used here. Browsers and users can override the size. And they can do it with all the power of css (conditionally, e.g. for single websites, or in certain situations, etc.).

It's not a new thing that some css properties cannot be fully supported and are replaced by something near to it or even stay fixed. That's especially a no-brainer for scrollbars, they usually don't disturb website layout.

Please do something for users this time.

Websites are already creating their own scrollbar implementations (I think some do it on user demand, because thin might be looking fancy, but usability is bad) and this creates even more diversity, which is the opposite of a standard.

[rootwork]

Scrollbars (should!) show how much content is visible (including if there is more), and they should be draggable.

This is a really good summary of the a11y issue. The first half is the reason I personally customize scrollbars to be always visible and wide on whatever OS I'm on, but the second part is the argument for why this isn't just a personal-preference thing.

Important: Unlike Buttons on a web page, the scrollbars don't zoom! This is another problem with accessibility, and it might be related to the lack of a numeric width.

This is key actually. Scrollbars are in a sort of gr(a|e)y area -- they're technically browser chrome but very dependent on the content of the page, and already somewhat adjustable by CSS -- unlike, say, the titlebar/tab. It would make sense that they should be adjustable in the way other page elements can be adjustable, rather than falling back on the "they're just chrome" argument that feels like it underlies a lot of the objections to this.

Also, scrollbar-width simply doesn't follow other width specifications. It's kind of non-standard in my opinion.

It's very nonstandard, and for no good in-CSS reason -- the reasons all come from browsers' interests in having consistent UI. Great, but a11y should trump consistency. This width should be like other CSS widths, and accept CSS length values.

[hyperlogos]

This is an accessibility issue and a usability issue in one. It's very difficult to mouse into that minuscule scrollbar, period.

[Durobot]

Not being able to change scrollbar width is a constant source of irritation for me. That and not having up / down arrow buttons.

[ThomasCorbin]

Your telemetry should tell you that no one uses scrollbars because they are impossible to use. I have poor eyesight and need bigger/wider scrollbars so that they are even usable. It's so frustrating to try to work the current scrollbars in Firefox. Please fix this issue.

[tabatkins]

Your telemetry should tell you that no one uses scrollbars because they are impossible to use.

I'm not certain why you'd believe that.

I have poor eyesight and need bigger/wider scrollbars so that they are even usable. It's so frustrating to try to work the current scrollbars in Firefox. Please fix this issue.

Again, this is not an argument for pages being able to control the width of their own scrollbars, but rather for browsers to give their users the ability to control scrollbar widths on every page, the same way users are currently allowed to set default fonts and font sizes.

If we added the ability for scrollbar-width to take a custom measurement, that would not help you in any material way, as the vast majority of sites wouldn't set it.

[tabatkins]

File bugs in your preferred browser's bug tracker; we just help browsers do CSS the same, but otherwise have no control over their internal features.

[hg42]

you're on the wrong track...

Browsers have the same 80/20 problem like standards or operating systems. They usually only do what "most" of the users use or want or whatever.

Basically they don't have time or motivation or whatever to add the missing 20%.

So it's very important, that we - the users - can do something by ourselves.

There are enough developers among those users that can write extensions to browsers or userstyle userchrome.css or usercontent.css etc.

BUT, if the necessary css attributes are not available, it's impossible to do at all.

We can only override something with !important, if it does exists or the desired value is possible.

PLEASE...do not redirect us to someone else, but solve our problem instead.

There are plenty of examples where this works very well.

The real power of CSS lies in it's selector rules, which allow to override looks and behavior and gives users the last word with !important (if implemented correctly, that is browser !important has priority over web site !important, which they should never do, but some devs don't care)

[jludddy]

+1 on scrollbar width customization.

[magicalskye]

i am disabled and i do have problems with that tiny scrollbar. there is an extension for making it visible (by setting colours that i can actually discern), which only does 1/4 of the job because most websites override the setting and even when they don’t, it’s still just too thin to see properly and also too thin to comfortably grab and operate it, especially if i have the browser window on the left screen.

what abled people think of as “pretty” is what ruin’s disabled people’s day

[hg42]

the usual autohide and tiny size scrollbar is generally not designed to grab it, it's designed to see something when scrolling with a mouse wheel or when swiping on touch displays.

Instead I use the scrollbar to drag it to a certain position.

I already lost all hopes that UI designers will ever think of this use case. They simply don't give a shit about it. And while fulfilling some accessibility rules (who made them?), I think they only do it to get a badge, not thinking about it could really work for disabled people (and I would probably blame myself if still in that business).

The possibility to override something is very important for those 20% that are not considered in this 80/20 world (to remember, I grew up with the goal to do things 100%).

And we can only override something that exists.

[hg42]

I guess if it's closed, nobody reads it? are we talking to ourselves here?

[Amit0617]

Disclaimer! Apologies if my opinion hurts anyone. Probably I might not be able to see issue on yours side.

I am feeling that many of the people aren't using peripherals right way when they have to drag scrollbar by clicking over it. I use Firefox around 95% of the times (very rarely chromium based) and never face this BECAUSE I never try to drag scrollbar, rather I use scroll on mouse to move page up and down. Similarly, two fingers drag on the touchpad.

[hg42]

a scrollbar allows directly dragging to a certain position, instead of incremental scrolling. It's provides spatial orientation.

Maybe you never used a very long page, where scrolling with a mouse wheel or similar takes quite long. If you have a fast computer and less complex or cached content you can even drag much faster (10-100x) than with incremental methods, while still seeing the content.

[Amit0617]

Okaay... I got your point, and I guess then this problem is not even a problem. Let's say you want to go to the middle of the page, just take your mouse to the right edge of your screen and just click in the middle of the screen on the right most edge. Your scrollbar will jump to middle, and you can do the same for the whole length. You are not required to grab that miniscule scrollbar!

[hyperlogos]

You didn't get the point, just clicking in the tiny scrollbar is difficult for many.

That it doesn't affect your use case doesn't mean it's wrong, it means you don't have skin in this game and your opinion can safely be ignored.

[hg42]

on the right most edge

so you are a full screen guy... my screen is 42" and it doesn't make sense to only have one window, in fact I have more like ten open and can see them all

additionally I have window borders and need them because of the same reasons, even with full screen windows I would grab the window border

[Zygzaq]

I can't use firefox for one reason only - lack of custom scrollbars. Why? When I work on a 55" 4K monitor, I want to quickly grab and move all long content quickly, and not waste time and nerves on the mouse wheel, it must work at maximum speed! I have many open windows with a lot of content, which I catch in the blink of an eye, only when I can easily grab the scrollbar with the mouse, it speeds up my work many times... many!

[frivoal]

@Zygzaq

I can't use firefox for one reason only - lack of custom scrollbars. Why?

Firefox does have custom-sized scrollbars. Type about:config in the url bar to access advanced settings, then set widget.non-native-theme.scrollbar.style to 3 (for some resizable scrollbars that look like the normal ones), widget.non-native-theme.scrollbar.size.override to 32 or some other value, depending on the size you want (32 is about twice the normal size). This allows you to set up scrollbars that fit your needs and tastes based on your environment.

This repository is not the appropriate place to request end-user features (or help) for browsers. We are discussing here features aimed at web page authors.

[hg42]

this actually seems to help on Firefox as far as I see (so thanks, because I mainly use firefox and did not know it, I'm sure I search for scrollbar when this thread started). Does it override scrollbars that are discussed here?

Apart from Firefox, the main problem we discuss here, is the case when browsers or OSes do not override all possible scroll bars, then the only way to solve this, is to set the width with important or modify it via javascript.

This is only possible if the value exists.

Users that use different OSes and/or browsers are very interested in a solution that can be used on all of them. That solution is usually a userscript that can be injected and modifies css.

[SebastianZ]

As it was pointed out earlier in this issue, implementers object to add a way to set arbitrary scrollbar widths.

Therefore, in #10650 I suggest to add at least a thick value to cover the accessibility use case for the case that OS and user agent don't provide a way to adjust the scrollbar width.

Sebastian

[hg42]

different situations need different sizes. Think of someone using the foot vs. a 90 year old person, it mostly depends on vision and motion capabilities. Also the size of the screen etc.

E.g. take me, as a software developer, I have a 43" Monitor with very small fonts, but I like to scroll with scrollbars, because it's faster and you can move the thumb directly to a target position (and I have content summary bars beneath scroll bars, e.g. the text itself, with git status etc.). On a large screen you need a bigger landing area, but also not too big (the 32 is very big for me, I use 16 usually, but nowadays all think 8 is enough, well, that might be ok for a notebook with 13").

I know an old guy who has good vision, but got some trembling hands, which make it difficult to grab something smaller. He also doesn't like to scroll with a mouse wheel, he would constantly swipe pages up and down. Some people suggest to zoom the whole screen, but he says he isn't blind.

I could add quite a few more examples...

[SebastianZ]

Note that I am not an implementer and I wouldn't object to custom measurements for scrollbars. Though I understand the reasoning behind the objection. It is a user preference how thick the scrollbars should be, not a website author preference. Therefore, it's the operating system's and/or user agent's responsibility to provide a way to customize the width of the scrollbars.

The suggestion in #10650 is meant to provide a way to indicate that the scrollbars should be thick enough in case the OS and UA don't provide a way to customize their thickness.

Sebastian

[hg42]

I know that you are not an implementer. I only wanted to make clear, that it's not that simple.

I'm not sure if it is a 100% user preference. Nearly the same reasons (without the interaction part) would be valid for fonts. But they have a size. Buttons are even interactive and can be sized at will, they can even be designed totally unusable. Nobody says, buttons should not be sized.

For me it's also an orthogonality thing. If you tweak all web sites with overriding css, you will find, that the scrollbars do not follow, because they cannot be sized. And if they can be sized it's not the same place, not doable in an injected script.

I mostly have normal scrollbars, but there are also scrollbars that only indicate a position, without the need to handle them. Those I want to be much smaller (depending only on vision capabilities, not motion capabilities), this is the "thin" case. There is also a type in between. Those are not handled regularly, but only in special cases. I would size them between thin and normal.

Well, I guess nobody that can change something is reading this closed issue.

[nd-]

A big +1 for me on this request, in particular as a way to support accessibility as already said.