[css-scrollbars][css-scrollbars-1] Add to Scope section that we intend not to spec WebKit pseudo-element approach for reasons

[upsuper]

It seems to have been raised in several places that some people are confused why we choose the IE scrollbar color property approach rather than the WebKit pseudo-element approach in the spec. I think it makes sense to have a centralized place for the description, and preferably in the spec itself. Probably we should write down the reasoning in the Scope section.

[Nadya678]

I think, the webkit version is better than IE varsion but not ideal. Webmaster shall be possible to change position, shape and other properties of INTERNAL scrollbars. Internal means here: scrollbars of elements with set overflow:auto and overflow:scroll (including <textarea/>). Without it website looks weird or webmaster must use DHTML JS to emulate scrollbars. No longer DHTML!
Additionally emulation od scrollbars is hard due to lack of resize event for elements. There is only resize event for window.

There shall be specified as little as needed pseudoelements for scrollbar to be possible style the scrollbars like mac, MSIE, EDGE and chrome versions (including mobile versions). No scrollbar element but ::scrollbar-____ pseudoelements applicable to all elements.

[SelenIT]

some people are confused why we choose the IE scrollbar color property approach rather than the WebKit pseudo-element approach in the spec

It seems that I'm one of these people :). Where can I find that reasoning now? Things like *-3d*-color look especially surprising in the spec created in the flat design era.

[craigkovatch]

The -webkit-scrollbar approach is incredibly robust and flexible, and has been supported for many years. IE's approach is no longer supported even by IE, and the properties are very Windows-specific. I strongly recommend that the Working Group reconsider.

One example: in our product, we use a :hover rule to only show ::-webkit-scrollbars when the mouse is over (similar to Apple's style). We also change the size from the default, change the colors when the scrollbar is :active, etc. The approach in the draft spec would allow for none of this.

[SelenIT]

I re-read the reasons from the W3C Wiki:

Why not pseudo-elements?

Scrollbars are more like text-decoration than they are things like ::before/::after, or ::first-letter or ::first-line.

Just as we don't have separate pseudo-elements for ::text-underline ::text-overline ::text-strike-through, it doesn't make sense to have separate pseudos for scrollbars or scrollbar parts!

With all due respect, I can't agree with this. Is text decoration really a separate interactive control different parts of which have different action when user interacts with them, as a scrollbar is? Scrollbar is a much more complex thing than just a decoration, it's a combination of two distinct functionalities:

• indicator showing both relative size of the visible area to the whole scrollable content and its current position within that content;
• group of visual controls to adjust the scrolling position (usually a draggable handle, clickable areas before and after it for quick navigation, and arrows for fine control).

In CSS, there is no direct analog for this, since CSS rarely affects the functionality of the element or any of its parts. The closest CSS analog for the scrollbar behavior I can figure out is setting different pointer-events values for the element and its pseudo-elements, making them react differently to the user's input — and it seems impossible without pseudo-elements.

Closer analogs to scrollbars might be native HTML controls like <progress> and <input type="range"> (they even look similar to scrollbar on many platforms!). The look of such controls in all known implementations is customizable via pseudo-elements (though vendor-prefixed and yet not standardized).

So if the decision to restrict the control over the scrollbar appearance to "repainting" it in IE5.5 style was based on the assumption of scrollbar as a decoration, I would strongly oppose to it. Scrollbar is definitely not just a decoration, and it can't be truly customized without separate addressing to its completely functionally different subparts.

[kizu]

I'd also welcome any pseudo-elements based approach and would be really confused with the colors-only one, especially when looking at how scrollbars look at different systems and which “elements” contain: not all of them have arrows, not all of them have any 3d-elements in them etc.

The webkit's variant, while not ideal, provides a lot of control that can be used to enhance the experience of the web apps in a lot of ways.

As @SelenIT wrote, scrollbars are complex interactive controls and styling them should mean styling their shadow DOM. By default browsers can continue to have system controls unless any of the scrollbar's pseudos are defined (just like it works now in webkit), but when defined, each browser should have the same number of pseudos for scrollbars.

Custom scrollbars is a really common use-case, and without proper implementation we either get webkit-specific styles and ugly scrollbars in other browsers, which can make the UX much poorer (example: dark theme for a website with bright contrasting non-styled scrollbars which draw all the attention to themselves), or get some scrollbars that use JS which could have poor UX due to developers' implementation bugs, or we could get scrollbars to be hidden and developers to expect for users to use scrollwheel or gestures to scroll content, and that can be really bad for accessibility (non-visible scrollbars make it much harder to determine if an area is scrollable, some users can have pointer devices but nothing to scroll other than by using the scrollbar's interactive elements, those users just won't have any way to scroll such container with a hidden scrollbars).

Implementing the colors-only solution won't solve most of the use-cases developers want and would make them to use hacks or solutions that provide bad UX.

[SelenIT]

I'm afraid that stating that "pseudo-elements for selecting specific parts of a scrollbar are unnecesssary for the documented use-cases" basing on actual -webkit-scrollbar-* pseudo-elements usage only can be kind of "survival bias". Developers who need more control over scrollbars than is easily achievable with cross-browser CSS have to resort to JS-based solutions. Quick look on some of the popular (3k+ stars) "custom scrollbar JS plugins" (example 1, example 2) shows that these use special styling of the scrollbar parts heavily, including graphical backgrounds and separate hover states for them.

Also, the Tweetdeck example cited in the Wiki uses the color change of the scrollbar thumb on hover (e.g. .column-scroller::-webkit-scrollbar-thumb:hover { background-color: #8899a6 }) and rounds its corners (.scroll-styled-v::-webkit-scrollbar-thumb { border-radius: 5px; }). Both aspects aren't yet addressed by the current color-based proposal, but can be very important for the UI/UX consistency, especially on Windows.

[craigkovatch]

@upsuper @tantek

I disagree that #3079 addressed any issues raised here. Please reopen this. The "reasoning" section is mostly subjective without sourcing or justifications.

The WebKit implementation of pseudo-elements for scrollbar is considered to be a feature mistakenly exposed to the web.

Considered by whom? Why is it considered a mistake?

Operating systems continuously evolve their scrollbar designs to provide better user experience,
beyond the ability of any set of pseudo-elements to accurately model this over time.

I'm not sure this is relevant even if it's true -- and I'm not convinced it's true, either. The visual styling of OSes has changed slightly, but besides auto-hiding the UX has not changed at all since the first release of OSX. Windows, similarly, restyled their scrollbars, but what of the UX has changed? And even if they are continuously evolving, providing just color/width properties makes that harder because the browser must keep up-to-date with every new iteration of OS scrollbars. Having an abstracted, fully-customizable approach like the WebKit approach means the web's appearance can be different than the OS -- and if we don't want that, a significant portion of CSS would be without purpose.

Different platforms have different scrollbar structure means testing interop is harder,
because authors would need to take not only engine but also platforms into account.

Testing for whom? What does "testing interop" here mean? Interop (as I understand it) is a much lower layer of software than a web author would ever consider. Chrome and Safari both have a consistent and stable experience across OSes. Why is this any harder than any "reskinning" any other native behavior?

[SelenIT]

I have to admit that I am also not convinced that this reasoning is enough. I understand (and support) the intention to correct the mistake of exposing the direct mapping of the specific platform implementation to the Web, but using this as a reason against any pseudo-element-based approach still seems kind of throwing out a baby with the bathwater to me.

Different platforms have different scrollbar structure means testing interop is harder, because authors would need to take not only engine but also platforms into account.

This is the reality authors have to deal with regardless which approach is chosen, even without styling scrollbars at all (some platforms always show scrollbars and include their width into the element size, some auto-hide and exclude them, and designs have to adapt to either behavior). I don't see how restricting the ability to affect the scrollbar appearance and behavior with some arbitrarily picked limited set of aspects makes this situation better for authors. On the contrary, there are cases where these artificial limitations may impact the UX negatively (for example, I strongly disagree that losing the ability to handle the scrollbar thumb hovering on Windows is "probably fine").

Operating systems continuously evolve their scrollbar designs to provide better user experience,
beyond the ability of any set of...

In my opinion, the exactly same concern can be raised against any limited set of predefined scrollbar aspects, regardless the exact way they are expressed — via pseudo-elements or via (sub)properties. For example, imagine that some platform decides one day to split the functionality of the scrollbar thumb into two parts, one for large-scale "scrubbing" and one for the "fine tuning" the scroll position in the extremely long documents. Which part should the "scrollbar thumb color" refer to then? Or should the user agent fall back to the "simpler scrollbar than the default platform UI rendering" when scrollbar styling properties are in effect, losing this extra functionality/usability feature entirely?

However, as @craigkovatch mentioned above, the "fundamental" parts of the scrollbar are nearly constant in any given platform over time, so we may expect them to be available in the future — again, either via (sub)properties or via pseudo-elements. And the second approach still feels much more flexible.

I agree that complete modelling of the specific implementation is probably not needed (if possible at all), and limiting the scrollbar styling possibilities to some degree is necessary. But maybe presenting the same two aspects — the track and the thumb — as pseudo-elements (so one would be able to apply :hover to them etc.) can be the acceptable compromise between interop and flexibility?