1719948 - Can scrollbar-color have some effect when using overlay scrollbars?

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect, P2)

Description

[jonjohnjohnson]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

Tried to use the scrollbar-color property to style scrollbar colors.

Actual results:

When an os, such as macos, allows for overlay scrollbars, the scrollbar doesn't reflect any colors represented by the value of the scrollbar-color property.

Expected results:

I think there should be some way to color an overlay scrollbar with an authors desired scrollbar-color value.

https://drafts.csswg.org/css-scrollbars/#scrollbar-color

"If this property computes to [a] value other than auto, implementations may render a simpler scrollbar than the default platform UI rendering, and color it accordingly."

Keyword here being "may", though I don't yet find it reasonable to ignore non-auto scrollbar-color values for just overlay scrollbars.

Comment 1

[Release mgmt bot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Scrolling and Overflow' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Seems intentional per this comment fwiw.

Comment 3

[Stephen A Pohl [:spohl]]

Markus, it would be great to get your input here.

Comment 4

[Markus Stange [:mstange]]

Do you have an example of a real-world web site that would be improved by colorful overlay scrollbars?

Comment 5

[jonjohnjohnson]

(In reply to Markus Stange [:mstange] from comment #4)

Do you have an example of a real-world web site that would be improved by colorful overlay scrollbars?

I don't mean to be difficult, but since this is obviously an aesthetic more than functional feature "imporovement" would be in the eye of the beholder/designer.

So I don't think it's a leap to say that ANY time an author tries to recolor the scrollbar with this property, they would be trying to have at least the scrollbar thumb (if not also the track) color be represented in any scrollbar/indicator that the os/browser uses, whether overlay or not.

Comment 6

[Markus Stange [:mstange]]

(In reply to jonjohnjohnson from comment #5)

(In reply to Markus Stange [:mstange] from comment #4)

Do you have an example of a real-world web site that would be improved by colorful overlay scrollbars?

I don't mean to be difficult, but since this is obviously an aesthetic more than functional feature "imporovement" would be in the eye of the beholder/designer.

That's definitely true. However, since supporting this from the browser side is ultimately a judgement call, it can help to have a few before/after examples when evaluating trade-offs.

So I don't think it's a leap to say that ANY time an author tries to recolor the scrollbar with this property, they would be trying to have at least the scrollbar thumb (if not also the track) color be represented in any scrollbar/indicator that the os/browser uses, whether overlay or not.

Well, the design constraints for appropriate colors are very different for overlay scrollbars vs classic scrollbars. It's valuable to have overlay scrollbars be transparent, to avoid fully obscuring the content that they overlap. But, with transparent colors, it's easy to choose colors that clash with the background or that end up being mostly-invisible on top of unexpected backgrounds. The default macOS overlay scrollbar style gets this right: It use both a stroke and a fill on the scrollbar thumb, with partially-transparent white and partially-transparent black, so at least either the stroke or the fill is visible regardless of background.
If we were to respect the specified scrollbar-color on overlay scrollbars, the question would be whether to use those colors as-is or whether to add transparency. And how much transparency is enough transparency?
And then I worry that many people will only test their web pages with classic scrollbars, and end up with unreadable overlay scrollbars.

One big motivation for websites to use scrollbar-color is to avoid having always-visible scrollbars clash with the website design, for example if the website uses a dark theme and the system scrollbars are light. For overlay scrollbars, this kind of clash is much less severe, since these scrollbars are (by design) only visible for a short time. And it is also mitigated by the transparency.

Comment 7

[jonjohnjohnson]

...One big motivation for websites to use scrollbar-color is to avoid having always-visible scrollbars clash with the website design, for example if the website uses a dark theme and the system scrollbars are light. For overlay scrollbars, this kind of clash is much less severe, since these scrollbars are (by design) only visible for a short time. And it is also mitigated by the transparency.

I guess I don't understand the motivation to not simply fade in/out the exact visual that is the classic thumb and track, now overlaying, only while scrolling. The author picked the colors to work with the design, they want those colors in the scrollbar, but instead of sitting alongside the content, it now happens to overlay while scrolling. No transparency added. The colors already support an alpha channel as shown when using classic scrollbars.

If this isn't clear, I can make a graphic/animation, but it will plainly be a recording of a colored classic scrollbar that's now fading in/out above the content when scrolling. Like how the scrollbar thumb and track fade in if I'm moused above them and initiate a scroll.

Comment 8

[Markus Stange [:mstange]]

(In reply to jonjohnjohnson from comment #7)

fade in/out the exact visual that is the classic thumb and track, now overlaying, only while scrolling

Ok, that would be simple enough to implement, and doesn't create unexpected color contrast scenarios. Let's do it.

Comment 9

[Markus Stange [:mstange]]

Attachment: Bug 1719948 - Respect custom CSS scrollbar-colors for macOS overlay scrollbars. r=emilio

Also, for custom-color scrollbars, make sure to always display the track
whenever the thumb is displayed, even if the scrollbar is not hovered (but
adjust the track width accordingly), so that custom color thumbs are never
displayed on top of page content directly.
This means that the thumb color only needs to contrast against the track
color and not against the page background.

Comment 10

[Šime Vidas]

Consider the following scenario:

.box {
overflow-y: scroll;
background: pink;
scrollbar-color: hotpink transparent;
scrollbar-width: thin;
scrollbar-gutter: always; /* currently not supported in browsers */
}

Demo page: https://jsbin.com/kesowuy/edit?css,output

In Firefox on macOS, if the scrollbar is classic, you get a hotpink scrollbar thumb that fits in with the design, but if the scrollbar is overlay, you get a dark-gray thumb that does not fit in with the design.

If Firefox added support for scrollbar-gutter: always, then there would be no risk of the overlay scrollbar overlaying the box’s content, so the scrollbar thumb could be colored safely. As a website author, if I reserve the space for the scrollbar via the scrollbar-gutter property, then I would like to be able to control the color of the scrollbar thumb, whether it’s classic or overlay.

Comment 11

[jonjohnjohnson]

(In reply to Šime Vidas from comment #10)

If Firefox added support for scrollbar-gutter: always, then there would be no risk of the overlay scrollbar overlaying the box’s content.

It's my understanding that this property declaration, when supported, will just force classic scrollbars. If that's the case, there's no worrying about "overlaying" anything. It's just classic and that even when there is no overflowing content, the classic track, with specified color, will always show and/or take up space.

Comment 12

[Šime Vidas]

(In reply to jonjohnjohnson from comment #11)

It's my understanding that this property declaration, when supported, will just force classic scrollbars. If that's the case, there's no worrying about "overlaying" anything. It's just classic and that even when there is no overflowing content, the classic track, with specified color, will always show and/or take up space.

scrollbar-gutter: always is defined in a non-normative appendix of the future level of the spec, and there is no consensus yet. I didn’t notice that earlier.

https://drafts.csswg.org/css-overflow-4/#valdef-scrollbar-gutter-always

The way the always value is currently defined, the gutter is always present “regardless of the type of scrollbar”. The spec example shows that this results in an empty track for overlay scrollbars (example 11, figure 5).

So if always ends up becoming a standard feature that is widely supported in browsers, it will allow websites to create a scrollbar that reserves space like a classic scrollbar but that is only visible while scrolling like an overlay scrollbar. So it will be a hybrid scrollbar. In that case, I think it would make sense for browsers to allow styling the color of the scrollbar, since the only difference to a classic scrollbar is that the thumb is only visible while scrolling.

Comment 13

[Markus Stange [:mstange]]

Attachment: Bug 1719948 - Respect scrollbar-color for overlay scrollbars on macOS. r=emilio

This makes the behavior on macOS consistent with Android, and with overlay
scrollbars on GTK and Windows 11. We don't display the track unless the
scrollbar is hovered.
If we run into color contrast issues, for example because web authors only
considered color contrast between the thumb and the track and not the color
contrast between the thumb and the page background, then we may change to
always display the track. But if we do that, we should do it across all
platforms with overlay scrollbars.

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7089dbf34315
Respect scrollbar-color for overlay scrollbars on macOS. r=emilio

Comment 15

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/7089dbf34315

Comment 16

[jonjohnjohnson]

(In reply to Šime Vidas from comment #12)
I stand corrected, I was mistakenly thinking of a "gutter" as always visualizing a "track", but gutters just visualize the background of the scrolling element and for good reason (think a value of both-edges obviously not placing a thumb-less track on the opposing edge from the usable scrollbar).

Comment 17

[jonjohnjohnson]

(In reply to Šime Vidas from comment #10)

scrollbar-color: hotpink transparent;

Your example brings something new to mind. Since an author can't choose between classic and non-classic scrollbars, what should a classic scrollbar track look like with a value set to transparent? I don't think there's a precedent exactly, but how should this linked screenshot of firefox scrollbars change? Should the track/ground be utterly transparent revealing the scroll containers background? Should the UA pick a contrasting light/dark value of the thumb color as the track/ground color? Ignore the styling request and just use auto?

Currently, firefox on mac allows scrollbar-color: transparent transparent to effectively hide all scrollbars, should this be safeguarded against? Even when we have scrollbar-width: none?

The spec is very forgiving with these colors, affording a lot of wiggle room for usability and system limitations. Maybe [e-mail] has some thoughts?

Comment 18

[Emilio Cobos Álvarez (:emilio)]

I think it's fine to respect transparent. It also hide the scrollbars in all other platforms. It's actually a cool way to implement things like "scrollbar on hover" or such without expensive reflows.

Comment 19

[jonjohnjohnson]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #18)

I think it's fine to respect transparent. It also hide the scrollbars in all other platforms. It's actually a cool way to implement things like "scrollbar on hover" or such without expensive reflows.

Agreed, authors would love to transition these values based upon hover/active, even if it takes some js/mousemove stuff in the place of not having a scrollbar element to attach a :hover.

But I think it still stands that an author can reasonably desire a transparent/semitransparent track for when scrollbars are overlay, while also desiring the track/buttons to not be that same transparent/semitransparent value for when scrollbars are classic on most platforms.

Comment 20

[Markus Stange [:mstange]]

(In reply to jonjohnjohnson from comment #17)

Your example brings something new to mind. Since an author can't choose between classic and non-classic scrollbars, what should a classic scrollbar track look like with a value set to transparent?

I think making the track fully transparent is a reasonable behavior in that case. As an author, I'd certainly want the option to make a classic scrollbar look "overlay-style" by hiding the track.

(In reply to jonjohnjohnson from comment #19)

But I think it still stands that an author can reasonably desire a transparent/semitransparent track for when scrollbars are overlay, while also desiring the track/buttons to not be that same transparent/semitransparent value for when scrollbars are classic on most platforms.

I guess. It's not something I worry about much. The hope with scrollbar-color was to provide just enough functionality so that authors would prefer overflow:auto over custom DOM scrollbars.
And if you set different background colors on the right elements, you can control the background color of the space taken up by the classic scrollbar, so there is a workaround.

Comment 21

[jonjohnjohnson]

I'm kinda nickel and dimin' ya here on this fixed/closed issue, but just figured I'd let you know that for at least current overlay scrollbars on mac scrollbar-color: transparent transparent doesn't hide the shadow/glow of the thumb.

Since I've seen comments from Emilio more than once alluding to this being an effective way to completely hide scrollbars, I think this might have been an oversight?

Comment 22

[Markus Stange [:mstange]]

(In reply to jonjohnjohnson from comment #21)

I'm kinda nickel and dimin' ya here on this fixed/closed issue, but just figured I'd let you know that for at least current overlay scrollbars on mac scrollbar-color: transparent transparent doesn't hide the shadow/glow of the thumb.

Since I've seen comments from Emilio more than once alluding to this being an effective way to completely hide scrollbars, I think this might have been an oversight?

I've filed bug 1762988 on this.

Comment 23

[Kagami [:saschanaz]]

Since BCD has some description about this.

Comment 24

[Hamish Willee]

@Kagami, what documentation is needed (this is a very long thread!).

The BCD for scrollbar-color is:

            "firefox": {
              "version_added": "64",
              "notes": "On macOS, you need to set the <em>General</em> &gt; <em>Show scroll bars</em> setting in System Preferences to \"Always\" for this property to have any effect."
            },
            "firefox_android": {
              "version_added": "64"
            },

Comment 25

[Kagami [:saschanaz]]

I believe the limitation described by the note is lifted by this bug, so some change reflecting that will be appreciated.