1432935 - Support -webkit-scrollbar styles for webcompat

Status: RESOLVED WONTFIX

(Core :: CSS Parsing and Computation, enhancement, P2)

Description

[Thomas Wisniewski]

The use of -webkit-scrollbar CSS to hide scrollbars, color them, and otherwise manipulate their basic appearance seems common enough that we ought to try to standardize these bits of CSS (Edge supports their own prefixed variants, so we're the only engine without support for anything like them, plus there are sites which do not even bother with prefixes other than -webkit).

At the very least I would suggest supporting the ability to hide scrollbars with rules like this:

  selector::-webkit-scrollbar { display:none }

Note that there is some recent movement/interest [1] in speccing out at least the color-oriented properties, so this might be a good time to hammer out the details and add support to at least the Compatibility Standard.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=77790#c214

Comment 1

[Jet Villegas (inactive)]

[ Triage 2017/02/20: P2 ] Marking this P2 along with the other -webkit-* properties we're pushing on.

Comment 2

[Xidorn Quan [:xidorn] UTC+10]

I'm to some extent against implementing all the pseudo-elements of scrollbar. I guess implementing a small subset of them might be fine, but providing the whole power of touching every details of the scrollbar is probably not.

I would rather we start implementing CSS Scrollbars spec and then ask developers to play with it to see if they like it. Eventually, we may want to map some of the scrollbar pseudo-element ability to those properties for long-tails when possible.

Comment 3

[Mike Taylor [:miketaylr]]

(In reply to Xidorn Quan [:xidorn] UTC+10 from comment #2)
> I guess implementing a small subset of them might be fine, but
> providing the whole power of touching every details of the scrollbar is
> probably not.

I wonder if we can get away with a "good enough" subset, and map that to CSS Scrollbars. 

-webkit-scrollbar seems like most important, since it's often used to hide the scrollbar, or set a width a layout depends on. We should probably attempt some kind of survey to see how these are used in the wild and if only supporting a subset would create problems.

Comment 4

[Panos Astithas (he/him) [:past] (please ni?)]

Assigning to Xidorn as he is working on bug 1460109 and dependencies. Even if we end up deciding that we will not emulate -webkit-scrollbar, we are very much working on this problem.

Comment 5

[Xidorn Quan [:xidorn] UTC+10]

There are currently 8 webcompat issues in See Also of this bug.

I'll try to summarize what are the problem, whether they have been fixed, and whether we can use shim based on scrollbar properties to fix them (as if they haven't fixed them).

* webcompat/web-bugs#12356 - gitter.im
Site fixed: no
Problem: hide scrollbar via ::-webkit-scrollbar { display: none }
Possible shim: can be done with shim like mozilla/webcompat-addon#33.

* webcompat/web-bugs#2767 - twitch.tv
Site fixed: yes
Problem: hide scrollbar via ::-webkit-scrollbar { width: 0; height: 0 }
Possible shim: the same shim above may be used with some additional rule

* webcompat/web-bugs#3816 - cdn.kotsovolos.gr
Site fixed: probably no
Problem: hide scrollbar via dynamically inserting ::-webkit-scrollbar { display: none }
Possible shim: the same shim may need some specialization to handle the dynamic insertion, but allowing arbitrary webkit-prefixed pseudo-element (bug 1486325) may be itself enough.

* webcompat/web-bugs#8626 - readthedocs.org
Site fixed: yes
Problem: hide scrollbar via using negative margin with appearance: none
Possible shim: need specialized stylesheet.

* webcompat/web-bugs#8030 - preview.webflow.com
Site fixed: no
Problem: block Firefox due to lack of ability to style scrollbar
Possible shim: no idea. If they just want to have different color, we can apply specialized stylesheet with user agent overriding.

* webcompat/web-bugs#2429 - itunes.apple.com
Site fixed: yes
Problem: style scrollbar with border image and width
Possible shim: would need advanced shim to simulate the whole scrollbar.

* webcompat/web-bugs#7919 - discordapp.com
Site fixed: no
Problem: advanced scrollbar styling on Chrome, imperfect scrollbar covering with custom scrollbar on Firefox
Possible shim: specialized stylesheet to help hiding the scrollbar so that their custom scrollbar can be used perfectly

* webcompat/web-bugs#17828 - keep.google.com
Site fixed: no
Problem: shrink the scrollbar width with ::-webkit-scrollbar
Possible shim: specialized stylesheet to apply scrollbar-width: thin to the affected element


So in the 8 issues, 3 have been fixed by the sites. In the 5 unfixed ones, 4 can probably be fixed via some specialized stylesheet shim with scrollbar-width property. preview.webflow.com may need specialized stylesheet shim as well as UA override.

Comment 6

[Xidorn Quan [:xidorn] UTC+10]

My general proposal for fixing this kind of webcompat issue is to create a specific injection stylesheet for each site we want to fix. We may need to wait for the scrollbar properties to ship since it doesn't seem to me that we insert the stylesheets as chrome stylesheets, so we have to wait for the properties to be available in content.

The script was an attempt to create a generalized solution, but there doesn't seem to be enough websites to justify that extra complexity. A specialized stylesheet fixup for each site should be straightforward, and we can also hand such stylesheets to the websites when outreaching to help them fix their sites.

Comment 7

[Sean Voisen (:svoisen)]

(In reply to Panos Astithas (he/him) [:past] (please ni?) from comment #4)

> Assigning to Xidorn as he is working on bug 1460109 and dependencies. Even
> if we end up deciding that we will not emulate -webkit-scrollbar, we are
> very much working on this problem.

Now that bug 1492012 has landed, does it remain the plan to NOT emulate -webkit-scrollbar and do specialized stylesheet fixups as needed?

Comment 8

[Panos Astithas (he/him) [:past] (please ni?)]

Yes, the current plan is what Xidorn outlined in comment 6. Note that these will be stylesheet fixups that we apply through our web compat system add-on code on incompatible sites.

Comment 9

[Panos Astithas (he/him) [:past] (please ni?)]

I don't think Xidorn is planning to work on this, but feel free to reassign if I am mistaken.

Comment 10

[Hiroyuki Ikezoe (:hiro)]

Firefox 64 has been already released.  Thomas, are you going to work on the fixup thing in comment 8?  Or should I ask Mike Taylor who will work on it?

Comment 11

[Thomas Wisniewski [:twisniewski]]

Actually Mike has already asked me to take a look at this, so I'll do so ASAP.

Comment 12

[Panos Astithas (he/him) [:past] (please ni?)]

Assigning per comment 11.

Comment 13

[Mike Taylor [:miketaylr]]

I believe Dennis will pick this up.

Comment 14

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating webcompat priority whiteboard tags to project flags.

Comment 15

[Mike Taylor [:miketaylr]]

In Bug 1561299, our current plan is to just intervene using scrollbar-width for important sites. So let's WONTFIX here.

Comment 16

[Thomas Wisniewski [:twisniewski]]

Sites are still using webkit-scrollbar, and to my knowledge neither Chrome nor Safari have adopted the scrollbar-width/color variant that's supposed to be the new standard, so we should probably revisit supporting this (at least as a limited alias).

@dholbert, @emilio, what do you think? It doesn't seem like Chrome is taking implementing the new standard very seriously, and even if both they and WebKit do, I don't suspect they will ever deprecate and remove the -webkit-prefix, so we might want to just bite the bullet here and support at least hiding and coloring scrollbars with the -webkit-prefix for webcompat?

Comment 17

[Emilio Cobos Álvarez [:emilio]]

So... We could support some of it, but doing it performantly would be quite a challenge. Scrollbars already create way too many DOM nodes, and we have optimizations to avoid resolving styles for them over and over which this would break. Also, there are tons of ways of hiding these, which would be hard to get right in general. Plus ::-webkit-scrollbar forces the scrollbar to be overlay, IIRC, so at least implementing something like overflow: overlay would be a prerequisite. All-in-all it doesn't seem particularly appealing :/

Comment 18

[Xidorn Quan [:xidorn] UTC+10]

I don't think anyone is keen to spec the scrollbar pseudo-elements either.

There might be a middle ground. If majority of the issues come from applying display: none on ::-webkit-scrollbar to hide the scrollbar, maybe we can parse it and interpret it as scrollbar-width: none?

Comment 19

[Thomas Wisniewski [:twisniewski]]

FWIW, I think Xidorn's suggestion is a good one. It won't cover all cases, as I just saw a webcompat issue where a site uses 0.5em width and height, which happens to also end up hiding some scrollbars (perhaps unintentionally).

But I suspect it's the most important case, as not seeing the right color or size of a scrollbar isn't as much of a site usability issue as seeing a superfluous or double scrollbar can be.

Comment 20

[Thomas Wisniewski [:twisniewski]]

We can also try two other relatively simple things here, as per what I just saw at https://github.com/webcompat/web-bugs/issues/110174:

1. Use the background-color value a site sets for ::-webkit-scrollbar-thumb as the scrollbar-color.
2. If a site sets a non-zero value smaller than the normal width of the scrollbar (even roughly guessing), use scrollbar-width:thin.

The second of these could help at least keep scrollbars from "covering" content.

Comment 21

[Emilio Cobos Álvarez [:emilio]]

(In reply to Thomas Wisniewski [:twisniewski] from comment #20)

We can also try two other relatively simple things here, as per what I just saw at https://github.com/webcompat/web-bugs/issues/110174:

Part of the issue is that even doing this is non-trivial, performance wise...

Comment 22

[Thomas Wisniewski [:twisniewski]]

I see, then we might as well just implement them "properly".

Comment 23

[Tomas Rimkus]

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

Plus ::-webkit-scrollbar forces the scrollbar to be overlay, IIRC

No, it doesn't. At least in Chrome, it doesn't force scrollbar to be overlay.

Comment 24

[Daniel Holbert [:dholbert]]

(In reply to Thomas Wisniewski [:twisniewski] from comment #16)

Sites are still using webkit-scrollbar, and to my knowledge neither Chrome nor Safari have adopted the scrollbar-width/color variant that's supposed to be the new standard, so we should probably revisit supporting this (at least as a limited alias).

FWIW "scrollbar-styling" is a focus area in interop-2024, so that's a good sign on the standardized options becoming more usable here.

See https://github.com/web-platform-tests/interop/issues/571 which was the proposal to add scrollbar-width as part of interop-2024 (accepted).

There was also https://github.com/web-platform-tests/interop/issues/417 for scrollbar-color which was not accepted, but on the bright side, Chrome shipped it and it sounds like Safari's got an incomplete implementation which isn't yet enabled