Thomas Wisniewski Reporter
	Description • 6 years ago

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

	Jet Villegas (inactive)
	Comment 1 • 6 years ago

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

	Xidorn Quan [:xidorn] UTC+11
	Comment 2 • 6 years ago

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.

	Mike Taylor [:miketaylr]
	Comment 3 • 6 years ago

(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.

	Panos Astithas (he/him) [:past] (please ni?)
	Comment 4 • 6 years ago

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.

	Xidorn Quan [:xidorn] UTC+11
	Comment 5 • 6 years ago

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.

	Xidorn Quan [:xidorn] UTC+11
	Comment 6 • 6 years ago

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.

	Sean Voisen (:svoisen)
	Comment 7 • 6 years ago

(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?

	Panos Astithas (he/him) [:past] (please ni?)
	Comment 8 • 6 years ago

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.

	Panos Astithas (he/him) [:past] (please ni?)
	Comment 9 • 5 years ago

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

	Hiroyuki Ikezoe (:hiro)
	Comment 10 • 5 years ago

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?

	Thomas Wisniewski [:twisniewski]
	Comment 11 • 5 years ago

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