[css-scrollbars] Suggestion: "Overflow styling" / Scrollbar styling

[KingSora]

Hello!

I don't really know if this is the correct place to post suggestions, but I will do it anyway.
If this isn't the correct place, please correct me and tell me where I have to post my suggestion.

Ok, so yeah, I've been working on my web-app and there are a few things I don't like about the scrollbars. My biggest problem is, that I have no possibility to style my scrollbars properly. In Chrome / webkit are a few options, but they are prefixed and not supported in all browsers.
As well as the "Overflow: overlay" spec.

So my suggestions are the following:

Webkit did already a good job on styling scrollbars with pseudo elements, so why don't accept them as a standard:

selector:-webkit-scrollbar
selector:-webkit-scrollbar-button
selector:-webkit-scrollbar-track
selector:-webkit-scrollbar-track-piece
selector:-webkit-scrollbar-thumb
selector:-webkit-scrollbar-corner
selector:-webkit-resizer

I like the idea of the different states too

:horizontal
:vertical
:decrement
:increment
:start
:end 
:double-button
:single-button
:no-button
:corner-present
:window-inactive

If you don't know the styling possibilities in webkit, please check this article: https://css-tricks.com/custom-scrollbars-in-webkit/

There is something I really don't like, its the "overflow: overlay" property.
If you don't know the "overflow: overlay" property, follow this link: http://quirksmode.org/css/css2/overflow.html

Basically the overflow property is there for deciding if the element should have a scrollbar or not.
These are the standard values which all browsers support:

visible - content is not clipped, thats why there cant be any scrollbars
hidden - content is clipped but without scrollbars
scroll - content is clipped but with scrollbars (always visible)
auto - the content is clipped but with scrollbars (visible if content is overflowing)

And now the overlay value:

overlay - content is clipped, scrollbars are always visible but are rendered above the container

This kind of value isnt ment to be in the overflow property, it should be a styling option for the ":-webkit-scrollbar" pseudo element:

selector:-webkit-scrollbar {
position: absolute;
}

This would be equal to the "overflow: overlay" property.
Unfortunately the ":-webkit-scrollbar" pseudo element currently doesn't accept the "position" property.

In short:
The idea is to implement scrollbars as pseudo elements on elements which are displaying scrollbars by the correct setting of the property "overflow". On the pseudo element ":-webkit-scrollbar" the property "position" can be applied for custom positioning and achieving of the "overflow: overlay" effect. In the final standard the pseudo elements should work without any prefix of course.

I hope you understand my idea of scrollbar styling and the, in my opinion obsolete property "overflow: overlay". Any feedback to my suggestion is highly appreciated! :)

Best regards!

[tabatkins]

Yup, adopting WK/Chrome's scrollbar styling has been suggested in the past, but the other browsers haven't been very keen on it so far. Without anyone else wanting to implement, there's not a lot of reason to spec it.

(That said, I use the properties myself, to get less-intrusive scrollbars on some personal projects.)

This kind of value isnt ment to be in the overflow property, it should be a styling option for the ":-webkit-scrollbar" pseudo element:

You're right, it doesn't belong in overflow itself. We have a proposal for overflow-style which controls more aspects of how the content overflows, but it's been slow to be adopted. "overlay" hasn't even been accepted by the group yet as a reasonable value to spec. ¯_(ツ)_/¯

[KingSora]

Alright, thanks for your answer!
In my opinion the overflow-style shouldnt be implemented, because the efficiency wouldnt be as good as a scrollbar-style. With my "position: absolute;" suggestion you would have a overlay-scrollbar plus you would be free to position it as you want (example: top: 0; left : 0; bottom: auto; right: auto; would position the scrollbar to the left side.

I hope in future the group will realize the importance of scrollbar-styling.

[frivoal]

different browser vendors may have a different opinion, but I don't think your suggestion of complete freedom of styling the scroll-bar would get everyone's favor. Browser vendors need not only to give power to authors, but also to make sure things make sense for users. Allowing authors to tweak native controls like scrollbars is considered risky, as the resulting UI may end up making no sense. Not that authors make page that make no sense on purpose, but it isn't rare that they fail to take into account some variations between browsers or platforms, and end up making something that doesn't quite work everywhere.

overflow-style would give a more limited set of options. This is certainly more limiting for authors, but it also more likely to always work. I think it is a decent compromise.

[frivoal]

Agenda+, to see if we can close this as wontfix for the reasons above.

[css-meeting-bot]

The CSS Working Group just discussed ``.

The full IRC log of that discussion

<dael> Topic:
<dael> Github Topic: https://github.com//issues/107
<dael> Florian_: Bassed on previous I think we want ot reject, but I want to check
<dael> Florian_: Request is for pseudo elements to style parts of the scrollbar. I believe browsersdon't want to give authors control since they're native UI components and therefore we should reject. If that's not the case let me know.
<dael> MaRakow: I think the main interest I have from Edge is along lines of interop. There were suggestions of enhansements that I'm not sure about, but -webkit-scroll we see getting used on certain sites. We'd b e interested in a compat spec to explain behaviors.
<dael> MaRakow: I'm not certain about going beyond what's there.
<dael> astearns: MaRakow are you interested in ahving webkit behavior spec or do you want something interop spec so everyone can do non-prefix.
<dael> MaRakow: The former b/c we see it used. Once I understand what's going on it would be easier to comment on second. But it's more if sites like gmail are using this how do we get interop render of gmail onmulti UA
<dael> dbaron: One other question is that there are cases where devs are rebuilding scrollbars from scratch b/c they don't have this. That creates perf and UI problems that this would avoid. There are tradeoffs.
<dael> MaRakow: We see those too. I have less udnerstand of the exact requirements. I think a compat spec around webkit functionality and if the experts have any learning that would be valuable. I wouldn't oppose understanding better, but there's more expertese on the people who worked with existing webkit.
<dael> fantasai: There's a lot of talk about different things related to scrollbars. This is about h aving selectors, not prop, for each piece of scrollbar.
<myles_> darth vader
<smfr> fantasai: we can’t hear you
<rachelandrew> are we being dragged into another dimension?
<jensimmons> smfr: she’s not talking
<Rossen_> zakim, mute everybody
<Zakim> sorry, Rossen_, I can't do that anymore
<Rossen_> zakim, I love you anyway
<Zakim> I don't understand 'I love you anyway', Rossen_
<dael> fantasai: This is about having selectors to style peice of scrollbar. What you guys are talking about seems broader.
<dael> fantasai: This issue we need comments on and then we can talk about more things to control scrolling behavior and bars and stuff.
<glazou> let's be serious, there have been proprietary selectors for that for AGES.
<dael> Rossen_: I think what you said covers the GH issue. It also aligns with the compat observatison we have.
<glazou> and the web is full of them
<dael> Rossen_: It is mostly those pseudo classes effecting the way the experience is different between webkit and everyone else.
<dael> Rossen_: If the folks with experience on those particular properties can come up with an explainer or compat spec or anything that will help us understand we would be very interested in impl those, prefixed or not we don't care at this point.
<fantasai> s/point/point as long as we achieve compat/
<glazou> a lot of sites use those pseudos to "style" the scrollbar, in particular often for a color matching the corporate color
<dael> Rossen_: The second part ot this is once we get past styling there is a whole scrollbar customization people want to do like going into the scrollbar and adding marks like to show where changes are. Those are fairly advanced which people are hacking today. We're be interested in persuing that, but i t's more expensive and an advanced scenario.
<dael> Florian_: If we just get the pseudos, before we get to fancy it seems we would not be anywhere near done because we'd need to say which prop do what and what the default UA is. You can access the thing, but does the scrollbar change if you change the width of scrollbar thumb.
<bradk> Tick lines in the scroll bar could be done with linear-gradient background
<dael> Rossen_: This is where it goes back to webkit and blink supports that. For your question, yes they would change the scrollbar. We're interested in their experience in supporting those properties. I'm itnerested in hearing from webkit folks who are often resistant to control customization.
<dael> Rossen_: Also they have the most experience.
<dael> Rossen_: Is there anyone from webkit who can speak to that?
<dael> smfr: The scrollbar styling they tried to impl for itunes.
<dael> smfr: It was a mistake to leak to web. We don't really like that people can style scrollbars. We won't enhance and prefer to dedpricate it.
<dael> smfr: Other thing is pseudo elements become artifacts because platform changes scrollbar. For Ex we don't have arrow at bottomo f scroll for map and when you try to style it it's not there. That's the general take.
<dael> astearns: So item was on agenda to close this. I don'thtink we want to close and not fix. I've heard people want more info about what's currently prefixed, btu I don't hear anyone to work on it.
<dael> fantasai: AS long as Safari & blink ship this there will be pressure on other browsers to impl. We need to decide if that will be removed or we'll have to standardize. You can't say we're going to deprecate.We have to either remove it or add it to the platform. The pressure will increase over time.
<fantasai> s/We have to either/You have to either/
<dael> MaRakow: I agree with fantasai. I'd be happy if selectors are removed. My goal i s interop if that's achieved by everyone impl or if everyone removes. I'm not interested in prop for own merrit, but interested in interop of rendering.
<dael> astearns: I'm guessing browsers with it can't commit to remove.
<dael> TabAtkins: Oh no. We can't remove. They're used more than possible to kill.
<dael> Rossen_: Can you explain them?
<dael> Rossen_: Like write an explainer or compat spec so impl that don't have it can add that behavior? We'd be happy following the behavior if we get compat.
<dael> TabAtkins: IN theory yes. I can put it at the end of my current to do list.
<smfr> explainer here: https://webkit.org/blog/363/styling-scrollbars/
<dael> Rossen_: I didn't mean you personally
<dael> Florian_: I'm curious. WOuld people really impl them? There are not prop, they're selectors. Are peopler eally willing to make people relpos the thumb of a scrollbar.
<dael> TabAtkins: They're restricted.
<dael> Rossen_: We're willing to impl whatever gets us interop. I'm pretty sure that doesn't mean having relpos and grid in a scroll bar. That's why we want the browsers with support to give us MVC of supporting that.
<dael> astearns: smfr posted a link to a blog that desc them.
<Bert> (What happened to MS's scrollbar properties from around 2001? Are they still used?)
<dael> astearns: Could someonefrom Edge look and see how much more would be nec to get compat impl?
<dael> Rossen_: We'll review it.
<dael> Rossen_: For purposes of this topic what if we end here. We'll review and bring back if we need more info.
<dael> astearns: sgtm
<dael> Rossen_: There was the q i f this goes into UI4.
<dael> Florian_: That was one possibility. CSS UI hasn't had selectors so I'd prefer somewhere else.
<dael> fantasai: I Think UI4 makes sense due to specificity of selectors.
<dael> fantasai: As far as what we need for more info, we need a full spec for things you want to add. We need a proper set of standard aliases. You don't get compat...you can't say this won't be part of the platform. If we're not removing and we're adding it's part of the platform.
<fantasai> s/and/then/
<dael> Florian_: The q i s do we have enough info in the blog to make a spec. I would say we don't because it doesn't have a per pseudo class whitelist of prop that apply and if it's unusual, how? Because otherwise I can put grid in thes crollbar track.
<fantasai> +1
<dael> astearns: That's as much time as we should spend. We have something to start with.

[upsuper]

I'm feeling disappointed on that a feature mistakenly exposed to the web ends up needing to be implemented everywhere for interop.

I don't think doing the scrollbar pseudo-element is a good idea. OSs continuously evolve their scrollbars to provide better user experience. macOS and Ubuntu, IIRC, both have quite different scrollbar structure than that on Windows. Having something like this specified may make it harder for browsers to have decent behavior on different platforms.

Also, different OSs having different scrollbar structure also means testing interop is harder, because you would need to take not only engines but also platforms into account.

Actually, it is already not fully interop among platforms for Blink. ::-webkit-scrollbar-button doesn't have any effect on macOS while it works on Windows.

TabAtkins: Oh no. We can't remove. They're used more than possible to kill.

I doubt this.

From the document Blink principles of web compatibility, it seems there are various aspects taken into account when deciding whether Blink wants to commit some breakage, not just the use counter.

It seems to me that removing this

• would mostly be a cosmetic breakage, which is generally safer than other kinds of breakage, and
• may actually give users more consistent experience on their platform, which could improve user experience, and
• aligns browsers behavior with less overall effort.

For web developers, I don't think the current situation, that it is not even fully interop among platforms even within a single engine, is very helpful. Existing usages may already fail to take different platforms into consider.

If we really want this kind of feature, I think we should think about some better design, rather than just accept whatever happens to exist, especially given that its origin thinks it's a bad idea and wants to deprecate it.

[KingSora]

@upsuper
I think its important to give the developer a possibility to style his scrollbars, if he wants uniform scrollbars on all systems.

The final spec could include a scrollbar structure where all elements which a scrollbar must have are listed. That means, if the developer decides to use a styled scrollbar with buttons and scrollbar buttons are in the spec, he has a possibility to style a scrollbar with buttons, regardless wheter the native scrollbar has buttons or not. This would be a "all or nothing" scenario, use a completely styled scrollbar or use the native system scrollbar.

Since the developer would have the full control over styled scrollbars and lets say he doesn't want scrollbar buttons although they are in thr spec, he could set them to "display: none" to "remove" them.

I think webkit did a nice job on their spec structure because you really have access to every important element in every state. But I dont like how they are handling the actual styling. They only allow specific properties which aren't documented. There is definitly much room for improvement.

I am not asking for making the webkit scrollbar styling to a standard.
I am asking for a standard for scrollbar styling.

[frivoal]

I agree with @upsuper. @tabatkins @RByers, could you look more closely into the possibility of unshipping this, not only looking at usage (which is indeed somewaht high), but also including the rest of your more nuanced criteria?

[tabatkins]

From what I understand, removing this ends up with far more than a cosmetic breakage, as a number of sites (Facebook, several Google properties) use it with the expectation that they can get thin scrollbars, and reverting them to standard-thickness would end up drastically messing up the UI.

[frivoal]

Since this is currently not supported in other UAs, do these sites do UA sniffing to serve a different UI to browsers lacking that capability?

If not, then there's no problem :)
Either way, we should seriously consider giving authors tools to do feature detection rather than UA sniffing here. Time for @supports selector(:-webkit-scrollbar) {...} ?

[RByers]

@bokand @dtapuska does the chromium input team own scrollbar styling? Our principle in general for this sort of thing is is that we should either be moving towards standardization or removal (which in this case probably means better understanding the compat constraints for what behavior is actually required by the web beyond just a few popular origins).

[bokand]

No, input generally deals with scrollbars as they relate to handling input events and scrollability issues. For issues with scrollbars appearance that would likely fall to some combination of paint team and layout team. @skobes and @progers

[skobes-chromium]

I would support removing Chrome's current implementation of custom scrollbars, if possible.

It might be good to have a simpler / less general API, with a path to standardization, that still allows some degree of visual customization of scrollbars, which we could push as an alternative.

It looks like Facebook has cross-browser "custom" scrollbars implemented entirely in DOM/JS, so I don't think they would be affected.

[frivoal]

Putting back on the agenda to see if we can find a way forward.

I support removal and eventual replacement with something cleaner, but that means doing the work to check if removal is actually possible. I suggest trying to see if removal (to be followed by replacement) is considered desirable if possible, and if so, action Chrome to try (or Safari, but probably Chrome, due to market share). If Chrome succeeds, then we can move to looking for a replacement, and if they find that they cannot due to compat concerns, at least we should have gained enough insight about these compat concerns that we know better what we need to specify.

[tantek]

In parallel I have been pursuing a minimal spec scoped for compat with existing scrollbar styling properties, starting with just colors, to document existing scrollbar coloring support just enough to gain additional interop implementations and quickly get something dependable for this use-case to REC (separate from everything else we are evolving / iterating in css-ui-4).

The CSSWG discussed this at our f2f today and approved adopting the separate CSS Scrollbars spec that I've written up accordingly as an editor's draft - #1955

Given the intended conservative compat scope of CSS Scrollbars, if that's sufficient for this issue, feel free to close. Otherwise if there's desire / request for use-cases beyond scrollbar colors (and perhaps widths), feel free to document those additional future use-cases here and keep this issue open.

Thanks! -t

[ExE-Boss]

scrollbar‑3dlight‑color, scrollbar‑arrow‑color, scrollbar‑base‑color, scrollbar‑darkshadow‑color, scrollbar‑face‑color, scrollbar‑highlight‑color, scrollbar‑track‑color, scrollbar‑shadow‑color

🤦🏻‍♂️ Definitive NO from me for this draft,
I am in support of #2153 instead

Yeah, Windows ME scrollbars obviously won’t look out of place in modern operating systems.^</sarcasm>

[tantek]

The CSS Scrollbars first public working draft (https://www.w3.org/TR/2018/WD-css-scrollbars-1-20180925/) was published, with as requested removal of “scrollbar‑3dlight‑color, scrollbar‑arrow‑color, scrollbar‑base‑color, scrollbar‑darkshadow‑color, scrollbar‑face‑color, scrollbar‑highlight‑color, scrollbar‑track‑color, scrollbar‑shadow‑color”.

Rather than a new 'overflow-style' property, see the CSS Overflow Level 4 (https://drafts.csswg.org/css-overflow-4/) specification for how it handles the related use-cases. I believe all consensus use-cases requested in this issue have been addressed, and this issue can be closed without any further edits.

(Originally published at: https://tantek.com/2020/023/t1/)