w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.43k stars 656 forks source link

[css-scrollbars-2] Introduce scrollbar-mode for autohide behavior in User Agents #7421

Open bmathwig opened 2 years ago

bmathwig commented 2 years ago

User Agents typically implement different 'shy' behaviors such as hiding the scrollbar entirely until scrolled (macOS) or only showing a single panning indicator until mouse hover (Windows 11). In some cases, it is desirable for a page author to switch a root scrollbar to show its full set of elements (track, buttons, thumb) while keeping this 'shy' behavior in sub-scrollers.

The scrollbar-width property allows for a value of thin, which could be used by the UA to set a hiding behavior. However, the terminology may be interpreted differently for each platform and would not lead to a deterministic behavior.

I propose adding a scrollbar-mode property with the values auto | shy | visible, that when used in conjunction with scrollbar-width can be used to finely control the behavior of the scrollbar.

Example A page author may want the Windows 11 scrollbar to always show its panning indicator (scrollbar-width: thin) but avoid the auto-hide behavior (scrollbar-mode: visible). In another overflow element, they may wish to hide the scrollbar but show the full set of scrollbar elements (scrollbar-width: auto; scrollbar-mode: shy) when hovering over the 16px hit box region of the scrollbar.

tabatkins commented 2 years ago

We have in the past rejected a property like this, because Apple in particular makes this an OS-level user option and the WebKit devs didn't want to allow authors to control it (and thus potentially override the user choice). It's why we've never specified overflow: overlay, for example.

If their opinion has changed I'd be happy to revisit this, tho.

bmathwig commented 2 years ago

Could a case be made that this can potentially assist with accessibility? One side effect of shy overlay scrollbars is that a user may not be able to discover content that has overflow just by looking at it. In some cases, this is an intentional design choice by the author, but in another case the author may want to specially craft an overflow container with a visible scrollbar regardless of the user preference choice.

It's a hard question to answer, so I'm open to ideas! :)

tabatkins commented 2 years ago

A number of cases can be made, but ultimately it's not useful to write a spec that won't be implemented (it's just very boring fiction), so if a major implementor has explicitly said they won't implement it (and the other implementors don't find it enough of a big deal to force it anyway), then an idea is typically dead from the start.

Does this still match WebKit intention, @smfr/@hober/someone else?

benface commented 1 year ago

Not sure @smfr or @hober got a notification. :)

smfr commented 1 year ago

Generally we (Apple) consider that the scrollbar behavior should be under user control, not web author control, and that web content should respect the scrollbar behaviors that the user specifies through system settings.

bmathwig commented 1 year ago

A sample use case where this might be desirable:

A documentation page, where the left table of contents pane is scrollable but would emulate 90s <frame>-style aesthetics if it were forced to show the scrollbar. The right side of the page would always show the scrollbar to indicate position within the documentation.

The Gmail folder pane and message list pane is another example where two different styles of scrollbar would be required.

hg42 commented 1 year ago

@tabatkins

please don't forget, that a non existent property cannot be overridden by a user (-> !important).

So it's the opposite of the intent Apple developers have, as you said. (additionally, I don't think, that Apple should control the world, right?)

There are lots of users, that don't agree with decisions of UI designers. Designers usually have 80% of the users in mind, and totally forget the remaining 20%.

E.g. the first thing I do with a new browser is setting all fonts to sans serif. Serif fonts maybe nice for a newspaper, but not for the screen. I prefer being the master of my computer and not vice versa.

A similar problem is issue #6263, which you closed, and I don't understand why. You basically do the opposite of what you say.

hg42 commented 1 year ago

Generally we (Apple) consider that the scrollbar behavior should be under user control, not web author control, and that web content should respect the scrollbar behaviors that the user specifies through system settings.

I really appreciate the intent, but it's not the global reality.

Maybe, Apple forces that behavior. But it's not the de facto standard.

The reality is, that a web designer can set preferences and the browser can override it and when the browser doesn't do the right thing (e.g. for disabled users), the user has the final word by using some extension to set the property with !important.

The whole mechanism doesn't work, if there is no property to override.

Apple should use the standard way and allow the user to force properties by setting them with !important, if that's what they want.

tabatkins commented 1 year ago

On several OSes the scrollbar behavior is already controllable by the user, via OS settings. They don't need a property to control this.

The question is, and continues to be, if the page author should be able to control this. I personally think they should be able to, but Safari won't implement it and other browsers don't feel strongly enough to try and force the issue, so it remains WONTFIX.

hg42 commented 1 year ago

These developer comments of a Firefox scrollbar extension show the dilemma, we have:

https://addons.mozilla.org/en-US/firefox/addon/custom-scrollbars/?utm_source=addons.mozilla.org&utm_medium=referral&utm_content=search

RE: Custom Width Options

Many users have asked me to include the ability to set a custom scrollbar width, which is currently possible on Chromium-based browsers. I'd LOVE to be able to do this, but currently the standard that Firefox is using does not support that functionality. If this is something that you want to see added to the standard so that Firefox can add this feature, consider leaving a like or comment on this GitHub issue.

Users of multiple systems and browsers need a way to unify this. The purpose of standards is to define common features and prevent browsers from drifting apart. I still don't understand why a scrollbar is seomthing different?

RE: More Customization Options

Some users have suggested more customization options, like setting specific widths or changing just the arrow button colours. While I would love to have more customization options and that type of customization is possible in other browsers, unfortunately, it's not possible in Firefox.

Firefox's scroll bar customization settings are in their very early "experimental" stages. I hope that the Firefox developers will eventually add a lot more customization options in the future and I will continue to add more features as they become available.

This shows, that undefined parts in the standard immediately lead to different behavior. Please stop this. If there would be a standard users could demand that from the Firefox team. Without a standard they always have their excuses.

RE: Facebook Issues

Some users have also brought up some issues with Facebook. When they introduced their new (and ugly) new design, they decided to build their own scrollbars instead of using the standard browser ones. They did this to have full control over the look and bahaviour of the scrollbars. Unfortunately, this means that the add-on is not able to customize their scrollbars.

This shows, that missing css attributes lead to the opposite of what you said it does. The developers want control over their design.

The solution is a hierarchical model exactly like it's defined in CSS. It allows each level (webdev, browser, OS, user) to have it's control and higher levels can override lower levels. The OS is only one level. Additionally CSS attributes can be fine tuned for pages. Some pages need different settings than others.

Again, non-existing attributes remove all the control from the user and each other level.

Fonts and scrollbars are basically the same problem, especially when it comes to accessibility. Fonts can also be set in the OS. But this isn't a reason to force the same fonts and size in each and every application and all the displayed content.

Also, I wonder what you mean with "several OSes". MacOS and iOS? I can not get rid of the feeling, that you are an Apple fan boy. Apart from that, "several" is not enough. What about the other OSes?

tabatkins commented 1 year ago

All right, I've given the reasoning, and now you're getting close to CoC violation. I'm gonna lock the thread.