[css-scrollbars] Add wide value to scrollbar-width

[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. While both thin and none are standard across multiple platforms, the auto value currently varies depending on the user's platform, as it implements the "default platform scrollbar width".

This creates an inconsistent cross-platform experience, as many versions of both Linux and Mac display a scrollbar that's similar to thin. This could create concerns for users with specific accessibility needs.

The specification could be similar to the thin specification and read as such:

Implementations should use wider scrollbars than auto when applicable. This may mean a wide variant of scrollbar provided by the platform, or a custom scrollbar wider than the default platform scrollbar.

[frivoal]

While I agree that users can desire wide scrollbars, I don't see in what situation an author would want to control in via stylesheets for specific parts of their site. If users need to be able to say "I want the auto value to be wide", that's something they should do in OS or browser settings.

Is there a significant use case for author control for wider scrollbars?

[frivoal]

Since you seem to be satisfied with the logic in #6351 (comment), does closing this wontfix seem fine?

[WesleyBranton]

I don't really agree with the logic. The same could be said for the "thin" option. When is there really a case where the author wants to control the scrollbar on a specific part of the website to make it thin?

Just because there may not be a clear use case for it, doesn't mean that there isn't a use case. There's no real necessary use case for the "thin" option either, other than a designer's preference.

Perhaps a website that sells glasses wants to have a larger scrollbar on parts of their website because it makes it more functional for people with vision impairments (their customer base). Perhaps a website designer wants to use a wider scrollbar on a long scrolling section to compensate for the fact that the height of the scrollbar thumb is shorter.

Having a "wide" option offers some functional advantages for designers, as opposed to the "thin" option, which only has cosmetic advantages.

[frivoal]

When is there really a case where the author wants to control the scrollbar on a specific part of the website to make it thin?

There's no real necessary use case for the "thin" option either, other than a designer's preference.

Disagreed, there is a use case beyond author aesthetic preferences for thin: if a scrollable component of a web page is small, every last bit of space might be of value, and thin scrollbars might be a better fit for such a thing than a large one.

However, I do not see a parallel for authors requesting wide scroll-bars. Users, sure, but authors, I don't see it.

Just because there may not be a clear use case for it, doesn't mean that there isn't a use case.

We don't add features to the platform just in case there might be a not-yet-identified use case. Moreover, we can always extend this and add wide (or some other keyword) later if there's a good reason for it.

[frivoal]

Agenda+ to get the WG's take on this.

[css-meeting-bot]

The CSS Working Group just discussed scrollbar-width: wide, and agreed to the following:

• RESOLVED: close no change

The full IRC log of that discussion

<fantasai> topic: scrollbar-width: wide
<fantasai> github: https://github.com//issues/6351
<TabAtkins> fantasai: There was an issue where the commenter was unsatisfied
<TabAtkins> fantasai: Request was for an explicit "wide" value for scrollbar-widh
<TabAtkins> fantasai: argument was that people want wider scrollbars for a11y reasons
<TabAtkins> fantasai: florian said that's a good reason for a UA control, not an author control
<TabAtkins> fantasai: Commenter responded the author may know more about their audience. that's where we ended
<TabAtkins> fantasai: So what does the WG want?
<Rossen_> q?
<Rossen_> ack fantasai
<Zakim> fantasai, you wanted to queue up one other scrollbars issue which is Agenda+
<TabAtkins> TabAtkins: I agree with Florian's reasoning
<florian> https://github.com//issues/6351#issuecomment-877496097
<fantasai> TabAtkins: which fantasai just summarized
<fantasai> TabAtkins: The needs for wide is something that can be controlled at the UA level
<fantasai> TabAtkins: whereas need for narrow is depending on the content on the page, might be a small element
<TabAtkins> florian: Also commenter said "just because I dont' have a use-case doesn't mean there's not one somewhere", but we don't usually add features without a known use-case
<TabAtkins> Rossen_: objections?
<TabAtkins> RESOLVED: close no change

[WesleyBranton]

I still disagree with the logic behind the decision, but I guess there's not really much else I can do to convince you.

I think that the "we don't usually add features without a known use-case" logic is directly contradicted by the content in the draft. Take, for example, the scrollbar-color property which is also included in the specification. There is no valid functional use-case for that property, other than cosmetic benefits. Yet, the cosmetic benefits of a wide scrollbar width option is not sufficient enough in this case?

The specification's abstract reads:

This CSS module defines properties to influence the visual styling of scrollbars, introducing controls for their color, width, and impact on layout.

Adding a wide option falls completely within the abstract of the specification.

Focusing in on the "impact on layout" part specifically, there's no way to assure a standard scrollbar width across all platforms, other than the thin option. The auto option is insufficient because the width varies greatly between platforms. If a designer is making a website in which the scrollbar width must have a consistent impact on the layout of the page, there designer needs to use the thin scrollbar, which may not be desirable. The inconsistency of the width of the scrollbar when using the auto option can have a negative impact on the layout of a page, by causing page content to wrap or resize in a way that's different on each platform.

Additionally, the application of the specification may extend beyond websites. For example, web extensions for browsers also use these standards. Some of these web extensions may require more specific control over the scrollbar's visual appearance. Other web extensions may allow users to make visual adjustments to their scrollbars (take for example Scrollbar Customizer for Google Chrome), which is a far more accessible option for the average user compared to UA modifications.

And then of course there are the accessibility concerns I've already expressed previously, which have been ignored by saying that it should be set with a UA modification, which (as far as I know) is not covered under any standard and therefore may be inconsistently supported across browsers.

[frivoal]

There is no valid functional use-case for that property, other than cosmetic benefits

Please do not confuse "I don't know of a need for it" or "I don't need to" with "nobody has a need for it".

Also, lots of features in CSS relate to appearance, so you could deem them cosmetic. That's also not the same as no use case.

For wide scrollbars, there can be an aesthetic preference for them. There can be a functional preference for them. But the functional preference is a user preference, not an author preference.

a UA modification, which (as far as I know) is not covered under any standard

Indeed. Standards do not cover user settings in user agents. Not because we don't want them to happen, but because it's outside of the range of things standards have influence on. Standards cannot do anything to force user agents to do anything. They willfully follow standards when they aid in interoperability, but UI or user settings are not part of that, and therefore not part of standards. Writing a standard about what user agents ought to do in the UI will do nothing to make it happen. This does not mean it won't happen, but writing it in a standard isn't how you get there.

and therefore may be inconsistently supported across browsers.

Of course. Web standards are there to help user agents be interoperable with each other. Not to ensure that they are identical in all respects. Some browsers will offer lots of customizability, some will offer simple UI… They compete on that sort of things (among other things).

I guess there's not really much else I can do to convince you.

If you have evidence that there is a meaningful amount of authors who are attempting to display wide scrollbars (and that doing so would not do a disservice to users), you're very welcome to make that case.

[AutoSponge]

There is a compelling accessibility reason to allow for variable scrollbar sizes beyond auto, thin, none especially given that auto is defined by the platform (i.e., user agent). Pointer device users with motor issues and/or low vision could benefit from scroll bars that appear larger for them or scale with user agent zoom. Easier to "land on" and easier to see.

[michael-n-cooper]

APA requests further discussion in light of the above.

[emilio]

There is a compelling accessibility reason to allow for variable scrollbar sizes beyond auto, thin, none especially given that auto is defined by the platform (i.e., user agent). Pointer device users with motor issues and/or low vision could benefit from scroll bars that appear larger for them or scale with user agent zoom. Easier to "land on" and easier to see.

It seems to me like the user-agent should use larger scrollbars at request of the user, not at the request of the site?

[frivoal]

@michael-n-cooper, @AutoSponge

APA requests further discussion in light of the above.

The above (#6351 (comment)) had already been taken into account prior to closing the issue: as mentioned in #6351 (comment) and #6351 (comment) and in the minutes in #6351 (comment) (and now in @emilio's comment in #6351 (comment)): the CSSWG considered that wide scrollbars could be a useful user setting due to accessibility considerations or preferences, but that this didn't imply it was relevant as an author-exposed property.

If you think our reasoning is flawed, I'd appreciate information as to why.

[AutoSponge]

the CSSWG considered that wide scrollbars could be a useful user setting due to accessibility considerations or preferences, but that this didn't imply it was relevant as an author-exposed property.

Is there another mechanism, other than user agent stylesheets, we could use to influence browser vendors to institute this behavior? Also, if this is never supposed to be author-controlled, why is there a thin option?

[WesleyBranton]

Also, if this is never supposed to be author-controlled, why is there a thin option?

This is my point exactly. The people who are opposing adding the option for wide are arguing that there's no reason for an author to change the scrollbar to wide, but they are completely ignoring the cosmetic control.

They are arguing that in order to add a wide option there needs to be some functional reason other than cosmetic... ignoring the fact that there are plenty of other CSS options under the W3C standards that are purely cosmetic, like the scrollbar-color option for example.

It's a flawed logic.

[tabatkins]

Is there another mechanism, other than user agent stylesheets, we could use to influence browser vendors to institute this behavior?

File bugs on browsers. Standards can't reasonably impose restrictions on browser's own UI.

Also, if this is never supposed to be author-controlled, why is there a thin option?

See the reasoning in #6351 (comment)

[emilio]

Just for reference, on Firefox you can set default scrollbar sizes by going to about:config and setting widget.non-native-theme.scrollbar.size=<whatever-px-value>. On Windows it also needs widget.non-native-theme.win.scrollbar.use-system-size=false (because by default we honor the Win32 scrollbar width settings, SM_CXVSCROLL and SM_CYHSCROLL).

Of course if this is a common enough user need we could / should implement explicit settings for it in the browser settings, but that seems tangential to whether we should expose a wide value to CSS.

[meyerweb]

Minutes from the CSS & APA joint meeting at TPAC: https://www.w3.org/2021/10/20-cssa11y-minutes.html#t05

[philljenkins]

Is there a significant use case for author control for wider scrollbars?

Web site authors have and do want to provide options to their users independent of the browser/UA settings, especially when the options don't exist on all browsers/UAs. For example, authors provide (for various reasons) light and dark modes styules, large and small fonts sliders for users, high contrast version, etc. The reasons authors do this is becasue users don't have options in the browser or, more importantly, the browser doesn't support the feature well with the particulare code/framwework.

Using the good, better, best approach; I agree it is (should be) the best approach when supported by browsers/UAs. However when not well supported, and its critical to a set of known users of the particulare web site (e.g. low vision users, users with tremors, etc.), then the good solution is for authors to be abe to provide an option to their users to increase the width of the scroll bars.

[emilio]

Using the good, better, best approach; I agree it is (should be) the best approach when supported by browsers/UAs. However when not well supported, and its critical to a set of known users of the particulare web site (e.g. low vision users, users with tremors, etc.), then the good solution is for authors to be abe to provide an option to their users to increase the width of the scroll bars.

What is the chance that a browser that doesn't implement a way to customize their scrollbar width would implement scrollbar-width: wide instead? Honestly the ability to do the former is sort of a prerequisite for the later.

[frivoal]

Cleared with the APA WG: https://lists.w3.org/Archives/Public/public-apa/2021Nov/0015.html

[Helixopp]

Use case for "wide" scrollbar UA setting = Author understands that users with learning and cognitive disabilities need to be able to understand what things are and how to use them, as referenced in How To Make Content Usable For People With Learning and Cognitive Disabilities Guide (pasted below). COGA users need to understand that the page is not showing all available content on the screen, let's say financial transaction bank account data for example. The page has more content if, and only if, the user scrolls down to view it. Understanding that additional content exists, by scrolling, is predicated on the presence of a visual indicator, most commonly the scroll bar. However, a thin scroll bar can be easily hidden from view due to neuropsychological phenomenon's commonly exploited by magicians, that also effect how we navigate content (in-attentional blindness, visual masking, etc.). The overwhelming amount of content on the screen makes the sliver thin scroll bar impossible to notice. Worse than that, it is intelligible because it's so thin it looks like it's possibly just part of the frame. In any case, the author knows that this is an important part of the user experience for the customer to have cognizance of what information is available to them, but just what exactly is an appropriate standardized width to effectuate this understanding? Having an available setting provides them with a consistent implementation, giving the user confidence to navigate their account across platforms.

4.2 Objective 1: Help Users Understand What Things are and How to Use Them

Users with cognitive and learning disabilities may have trouble with orientation and learning. This can mean people get disoriented in a site.

Learning new things and remembering new information is especially difficult for people with cognitive and learning disabilities. They can also struggle or be unable to learn new design patterns. Make controls, icons and elements simple and conventional to help.

Make it clear to users what things are and how to use them. This includes clearly indicating the purpose of:

a site,
section of a site,
page,
section of a page, and
controls.
Use headers, labels, and other signposts to help users know the purpose of the page, region, or control.

Help users understand how to use controls and elements on each page.

Use familiar design patterns, terms, and icons to help users who struggle to remember new designs. Ensure the look, location, and interaction of controls and other elements are familiar and consistent across the site.

Show a clear relationship between controls and the content they effect to help users understand the effect of possible actions and reduce potential confusion.

[tabatkins]

Again, all of these are reasons to make wide scrollbars something you can set at the browser level, not something that individual pages can choose to use. Anyone who needs wider scrollbars to help them interact with the page will need it on all pages. This exact argument has been had multiple times in this thread already.

As this issue has already been resolved by the WG, but this keeps coming up, I'm going to go ahead and lock the thread. If there are new arguments or data, not already stated in this thread, for something about a wide value, please open a new issue.