Stylable browser scrollbars


#1

There already are vendor implementation of this, the most complete one seems to be the Webkit one.

Since a lot of websites theme scrollbars using some sort of JS library that often poorly replace the browser scrollbars, I think it would make sense to have a standard for this, probably based on the Webkit implementation.

It is especially needed for container elements scrollbars inside the page, which often break a carefully crafted design.


Scrollbar in css
#2

Indeed, since custom scrollbars, when needed, are implemented anyway (just currently via JS), it would be better to have a standardized proper (consistent and accessible in particular) way to do this in pure CSS.


#3

Agreed, we would want/need to properly spec out the parts of the scroll bar that can be styled, what styles on it can be styled and a standard approach to accessing the elements on it to style (possibly a shadow DOM approach?).

The key to getting this down would be to avoid a complicated series of near similar but still different enough approaches that happens for input type=“range”.


#4

Yes, this would be useful (simplifying custom scrollbars, not requiring JavaScript) and should be a shadow D.O.M. and pseudo element combination. It should be based off the existing WebKit ideas as they are a good C.S.S. implementation. The page https://css-tricks.com/custom-scrollbars-in-webkit/ explains the WebKit selectors well, including scrollbar parts (pseudo elements, below) and scrollbar states (pseudo classes, below)

::-webkit-scrollbar
::-webkit-scrollbar-button
::-webkit-scrollbar-track
::-webkit-scrollbar-track-piece
::-webkit-scrollbar-thumb
::-webkit-scrollbar-corner
::-webkit-resizer

:horizontal
:vertical
:decrement
:increment
:start
:end 
:double-button
:single-button
:no-button
:corner-present
:window-inactive

#5

It’s a good start but I think needs work. Some of the pseudo classes seem a tad odd (:increment and :decrement particularly feel quite off).

Some behaviour also needs speccing out and possibly different from the webkit implementation. There is also some very odd things going on. If you apply a style to the scroll bar suddenly everything needs to be specified. I can see there being some use for this as it means you don’t need to override a lot of style defaults but it makes it impossible to do some changes that work with the user agent defaults (eg I just want to make it a little thinner but otherwise look like the system default, this is impossible).


#6

I agree that the selectors should be a standardised version of the WebKit format. The -webkit- prefix should be removed to have the scrollbar prefix and the pseudo-classes should only be allowed on scrollbar pseudo-elements (but could be available for other purposes on other elements if required).

I’ve noticed the ::-webkit-resizer pseudo-element isn’t directly related to scrollbars (it can appear without them on a textarea element) but is still important so should be stylable. It has an associated CSS3 resize property specifying if the element is resizable by a user, which is unsupported by Microsoft Edge - if they’re persuaded to support customising the style of it, a feature request should be sent to them for enabling/disabling it using this CSS property.

For the styling, I think the default style should apply like it does on standard elements to allow small modifications such as custom width. A slightly hacky solution I thought up to allow completely custom styling is creating a new C.S.S. property called scrolltool-reset that removes all default styles from the specific pseudo-element (but keeps core things like display). I’ve chosen the prefix scrolltool because it’s unspecific to a particular scrolling item such as the scrollbar, also allowing it to be used on the resizer button.

Existing pseudo-class definitions from css-tricks: