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.
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.
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”.
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-inactiveIt’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).
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:
