Intent to implement: Scrollbar color properties

[Xidorn Quan]

Summary:
Two CSS properties scrollbar-{face,track}-color to style scrollbars in a color by author.

These properties intends to provide a more restricted feature set for controlling scrollbar styling than ::-webkit-scrollbar-* pseudo-elements shipped in WebKit and Blink, so that authors can get native scrollbars while still have some styling fitting their pages.

There is a consensus in the CSS working group that the existing pseudo-element API is too powerful, and since scrollbar is an evolving technology, we want to provide a restricted API to give users a native experience while allowing authors to customize to some extent.

Hopefully with these properties (and one another controlling scrollbar width or style to fulfill thin scrollbar usecases), WebKit and Blink would be able to unship their current pseudo-elements, so that we wouldn't need to implement them to get web compatible.


Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1460456

Link to standard: https://drafts.csswg.org/css-scrollbars-1/#scrollbar-color-properties

Platform coverage: Desktop

Estimated or target release: maybe Firefox 63 or 64

Preference behind which this will be implemented: "layout.css.scrollbar-colors.enabled"

Is this feature enabled by default in sandboxed iframes? Yes.
If not, is there a proposed sandbox flag to enable it? N/A
If allowed, does it preserve the current invariants in terms of what sandboxed iframes can do? It's a rendering feature which sandboxed iframes can always be simulated with existing rendering features.

DevTools bug: just some color properties, no need specific devtools support?

Do other browser engines implement this? Answer with: mixed signal. We would go through the CSS working group and ensure other browser engines are happy with them before shipping.

web-platform-tests: There are some web-platform-tests in https://github.com/web-platform-tests/wpt/tree/master/css/css-scrollbars
The main rendering of this bug is not testable because scrollbars are very platform-dependent, and rendering it like the platform natives is a large point of the properties.

Secure contexts: It's not clear. Probably no because it is a rendering feature which can always be simulated with existing features.


Also note that, DevTools has been using the properties for dark mode and gave positive feedback of them on platforms which they have been available.

[Karl Tomlinson]

Is there a plan to avoid the contrast problems we have mixing
document colors with system colors in other widgets?

e.g. If one scrollbar color is specified by the document, then what ensures
that other parts of the scrollbar are visually distinct?

Does the computed value of the other scrollbar color change so
that it contrasts with the specified color?

I see some such code in GetScrollbarArrowColor(), but I haven't found
something similar for track and thumb. Does something ensure the thumb will
be visible?

What if the user has a high contrast theme for accessibility
reasons? Does this override document colors?

[Xidorn Quan]

On Wed, Jul 25, 2018, at 6:29 PM, Karl Tomlinson wrote:
> Is there a plan to avoid the contrast problems we have mixing
> document colors with system colors in other widgets?
>
> e.g. If one scrollbar color is specified by the document, then what ensures
> that other parts of the scrollbar are visually distinct?
>
> Does the computed value of the other scrollbar color change so
> that it contrasts with the specified color?

There are only two scrollbar color properties. If a platform has other parts which need different colors, we would derive such colors from the given one based on the native scheme and constrast.

> I see some such code in GetScrollbarArrowColor(), but I haven't found
> something similar for track and thumb. Does something ensure the thumb will
> be visible?

Both track and thumb are specified by the author, so no, there is nothing ensures that thumb will be visible if the author specifically want to hide it.

> What if the user has a high contrast theme for accessibility
> reasons? Does this override document colors?

It follows the same color overriding settings that if browser.display.document_color_use is the default value, and the user is using high contrast theme, those properties would be ignored during style cascading, and consequently no custom scrollbar would be used.

- Xidorn

[Karl Tomlinson]

Thanks very much for answering some of my questions for me.

Xidorn Quan writes:

> On Wed, Jul 25, 2018, at 6:29 PM, Karl Tomlinson wrote:
>> Is there a plan to avoid the contrast problems we have mixing
>> document colors with system colors in other widgets?
>>
>> e.g. If one scrollbar color is specified by the document, then
>> what ensures that other parts of the scrollbar are visually
>> distinct?
>>
>> Does the computed value of the other scrollbar color change so
>> that it contrasts with the specified color?
>
> There are only two scrollbar color properties. If a platform has
> other parts which need different colors, we would derive such
> colors from the given one based on the native scheme and
> constrast.

Does the second sentence also apply when only one of the two
properties is auto?

Would the color for the auto property be derived in such as way as
to hide the thumb or to make it constrast?

>> I see some such code in GetScrollbarArrowColor(), but I haven't
>> found something similar for track and thumb. Does something
>> ensure the thumb will be visible?
>
> Both track and thumb are specified by the author, so no, there
> is nothing ensures that thumb will be visible if the author
> specifically want to hide it.

I can understand that if the computed values of track and thumb
match and are not auto, then a scrollbar might be hidden. I'm not
clear on whether it will actually be hidden because I'm not clear
on how much variation (e.g. shading) the implementation is
permitted to apply to shape the colors.

But my key questions are about the situation where one and only
one of the two colors is auto.

I'm not entirely clear what "If scrollbar-track-color computes to
auto, and scrollbar-face-color is not auto, it is used to color
the scrollbar track." means. I guess it means that, if only face
is not auto, then the track color is the same as that of face. Is
that your understanding?

Would it be correct to say that the "used value" for the track
property is determined from the computed value for the face
property in that situation?

Assuming the face and track colors match after applying this rule,
then would the scrollbar be hidden, in the same way as it would
when face and track colors match but neither computed value is
auto.

What if only track is not auto?

>> What if the user has a high contrast theme for accessibility
>> reasons? Does this override document colors?
>
> It follows the same color overriding settings that if
> browser.display.document_color_use is the default value, and the
> user is using high contrast theme, those properties would be
> ignored during style cascading, and consequently no custom
> scrollbar would be used.

Sounds good, thanks.

[Xidorn Quan]

On Thu, Jul 26, 2018, at 7:44 AM, Karl Tomlinson wrote:
> Thanks very much for answering some of my questions for me.
>
> Xidorn Quan writes:
>
> > On Wed, Jul 25, 2018, at 6:29 PM, Karl Tomlinson wrote:
> >> Is there a plan to avoid the contrast problems we have mixing
> >> document colors with system colors in other widgets?
> >>
> >> e.g. If one scrollbar color is specified by the document, then
> >> what ensures that other parts of the scrollbar are visually
> >> distinct?
> >>
> >> Does the computed value of the other scrollbar color change so
> >> that it contrasts with the specified color?
> >
> > There are only two scrollbar color properties. If a platform has
> > other parts which need different colors, we would derive such
> > colors from the given one based on the native scheme and
> > constrast.
>
> Does the second sentence also apply when only one of the two
> properties is auto?
>
> Would the color for the auto property be derived in such as way as
> to hide the thumb or to make it constrast?

No, currently we don't derive them from each other. We simply use some fallback color in that case.

It is not impossible to derive them, but I would expect authors to specify them together. We may add a shorthand property to set them at the same time.

The spec currently says track can use face color if that's auto... which I don't think I agree with. But I can consider adding some deriving if it's likely to be useful.

- Xidorn

[Karl Tomlinson]

Xidorn Quan writes:

>> Would the color for the auto property be derived in such as way as
>> to hide the thumb or to make it constrast?
>
> No, currently we don't derive them from each other. We simply use some
> fallback color in that case.

How is the fallback color chosen?

> It is not impossible to derive them, but I would expect authors to specify
> them together.

We know from experience that authors will not in general specify
complete pairs of colors intended to contrast.

We need to ensure that if only one color is specified, then the
scrollbar is either consistently usable or consistently not.

We shouldn't add a feature that can lead to pages testing as
reasonable on some systems, but just causes them to render
unusable on others.