[css-scrollbars] Interaction between scrollbar-color and scrollbar-width with ::-webkit-scrollbar

[frivoal]

trafficstars

The css scrollbar spec has a section explicitly declaring ::-webkit-* scrollbar pseudos, and any other similar approach as out of scope: https://drafts.csswg.org/css-scrollbars/#out-of-scope

As documented in multiple previous issues, this is based on the consensus (including implementers) that this approach is a bad idea, and that shipping ::-webkit-* scrollbar pseudos in the first place was a bad idea / accident which we wish we had avoided.

However, the wpt test suite contains a significant number of tests about the interaction between scrollbar-color and scrollbar-width with ::-webkit-scrollbar.

It has 17 tests, for a total of 21 subtests

• scrollbar-color-001.html
• scrollbar-color-002.html
• scrollbar-color-003.html (2 tests)
• scrollbar-color-004.html
• scrollbar-color-005.html
• scrollbar-color-006.html
• scrollbar-color-007.html
• scrollbar-color-008.html
• scrollbar-color-009.html
• scrollbar-color-010.html
• scrollbar-width-010.html
• scrollbar-width-011.html
• scrollbar-width-012.html
• scrollbar-width-013.html
• scrollbar-width-014.html
• scrollbar-width-015.html (2 tests)
• scrollbar-width-016.html (3 tests)

These tests are designed to pass if the user agent does not support ::-webkit-scrollbar at all (which is the case for Firefox), but they do expect a specific behavior if ::-webkit-scrollbar is supported, and that behavior is not specified anywhere as far as I can tell.

What should we do?

• while keeping ::-webkit-scrollbar optional / deprecated, specify the expected interaction, maybe in css-scrollbars, maybe in https://compat.spec.whatwg.org/
• delete the tests, to avoid constraining the behavior of a feature we're trying to get rid of
• keep the tests, but mark them as .tentative
• something else?

[lukewarlow]

I would prefer to keep them in some form they're useful to make sure that Webkit and chromium match in their behaviour.

[frivoal]

Marking them as .tentative for now, which lets us keep them while indicating that they're not part of the spec. We can always decide to do something else later.

[bfgeek]

+1 to keeping them - can also use .optional instead of .tentative if needed.

[frivoal]

Don't think .optional is appropriate, those are for MAY statements, which presumes that there's a spec, which we don't have.

[frivoal]

I think we could specify the interaction without specifying the legacy mechanism, by saying that any non-auto value of scrollbar-width or scrollbar-height takes precedence over any non-standard alternative mechanism offered to authors to style the scrollbars.

[smfr]

There are two possible interactions I can see between the scrollbar style properties and the styled pseudo elements (::-webkit-scrollbar etc):

1. If ::-webkit-scrollbar pseudos are specified, the UA uses them to render the scrollbars. scrollbar-width and scrollbar-color are ignored.
2. If scrollbar-width or scrollbar-color are specified, the UA ignores any ::-webkit-scrollbar pseudo-elements.

The latter seems preferable for forward progress towards removing ::-webkit-scrollbar support, so I agree with @frivoal

[css-meeting-bot]

The CSS Working Group just discussed [css-scrollbars] Interaction between scrollbar-color and scrollbar-width with ::-webkit-scrollbar, and agreed to the following:

• RESOLVED: If either scrollbar-width or scrollbar-color are anything other than initial values, then we ignore legacy -webkit-scroll pseudos

The full IRC log of that discussion

<astearns> ack luke
<fantasai> luke: I implemented the scrollbar properties in Chrome
<fantasai> luke: These properties, as implemented in Chrome, take precedence over the legacy -webkit-scrollbar styling
<fantasai> luke: That decision was kindof arbitrary, but based on feeling that the standard properties should take precedence even though it's not the same properti
<fantasai> luke: There's no specced behavior, would be good to get something in the spec wrt specifics
<fantasai> luke: at least wrt precedence
<astearns> ack florian
<fantasai> florian: Agree. When we drafted up the spec, we made an explicit decision not to spec those pseudos
<luke> q+
<fantasai> florian: it is a question of what to do when they are specified
<fantasai> florian: Proposed that if the new properties have anything other than their initial value, then the old ones don't work
<fantasai> florian: gives a good migration path
<fantasai> florian: limited effect
<fantasai> florian: easy to test
<fantasai> florian: and doesn't require saying anything special about how the legacy things work
<astearns> ack luke
<fantasai> luke: Interop has only included scrollbar-width, not scrollbar-color
<fantasai> luke: reason is that scrollbar-color is harder for WebKit to implement
<florian> q+
<fantasai> luke: but it means that webkit would have scrollbar-width but not scrollbar-color
<astearns> ack florian
<fantasai> luke: I would lean towards either one replaces the pseudos
<fantasai> florian: Agree, and I don't think we can distinguish between altering colors or width
<fantasai> florian: if you try to use a standard property that happens to not be implemented, then it wouldn't have an effect
<fantasai> florian: but using either or both should replace
<fantasai> astearns: smfr's comment is either as well
<fantasai> PROPOSED: If either scrollbar-width or scrollbar-color are anything other than initial values, then we ignore legacy -webkit-scroll pseudos
<luke> +1
<fantasai> RESOLVED: If either scrollbar-width or scrollbar-color are anything other than initial values, then we ignore legacy -webkit-scroll pseudos