numerosign

Internet Explorer has offered the feature since version 5.5, and it's been abused in many, many hideous ways. Though you could recolor the scrollbars, they were still chunky, ugly, XP scrollers. On the plus side, it degraded cleanly, except for the invalid CSS.

The subject came up again recently after Google took the covers off of wave, their inscrutable reinvention of, well, I don't know what. Lukas Mathis turned his reliably-keen eye to their radical custom scrollbar implementation. As Lukas said:

As a general rule, there’s nothing wrong with replacing native widgets with different-looking versions; visual consistency is overrated.
Further, he said that so long as your home-grown widgets are recognizable (i.e., that scrollbars look like scrollbars and checkboxes look like checkboxes), usability won't suffer. But he then said,
However, if you’re going to change how people interact with your widgets, you should have a really good reason.

I fully agree with his point. Don't replace something that's mature, comfortable, and expected with some half-assed, bullshit surprise. It's like calling for Columbo and getting Jimmy Fallon.

Still, I think custom scrollbars are an excellent candidate for progressive enrichment, especially in cases where they appear to be a part of the webpage itself instead of a means of interacting with it (e.g., a scrollbar on a block of sample code vs. the scrollbar that controls the viewport on the entire page.

How not to do it

Don't roll custom scrollbars in Flash, for god's sake. Damn.

My survey of the implementations available in JavaScript indicate that they are better than Flash in that they can degrade cleanly, but good god almighty, look at the source fleXcroll:

fleXcroll_source.jpg

On top of that, these scrollbar overrides exhibit many of the same behavioral quirks of which Lukas complained. They do degrade to a regular widget with JavaScript disabled, but that's not the point. It's not a matter of degrading to regular scrollbars for users with JavaScript disabled, because the users with JavaScript enabled are the ones getting stuck with something unusable.

Inching toward a simpler way

Recently WebKit's freshly-spouted capacity for styling scrollbars caught my eye. The gigantic aqua scrollbars on code samples on this site were getting to me. A few CSS styles to override the default appearance and create something nice looking for about 60% of the visitors to this site would just tickle my fancy.

Until I saw the myriad selectors and pseudo-classes involved. Jee-zus: 


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

Applicable Pseudo Classes:
:horizontal
:vertical
:decrement
:increment
:start
:end
:double-button
:single-button
:no-button
:corner-present
:window-inactive
:enabled
:disabled
:hover
:active
That's more than 100 possible combinations of classes and pseudo-classes! The demo page for the new extensions has nearly 500 lines of CSS that apply to the scrollbars and calls more than 30 images. To hell with that.

To be clear; I'm not afraid of complexity, I just don't like it. And while I'm sure that these extensions are a boon for the iTunes team (they're used all over the new iTunes Store), I'm not the only one who thinks it's absurdly complex. Implementing something so complex and clunky to accomplish only a bit of stylistic sugar just doesn't make much sense.

Nonetheless, I played with the new extensions, and struck upon a way to skip images required by the Surfin' Safari example in favor of a few rules that take advantage of WebKit's support for CSS Gradients.

A simpler way


pre::-webkit-scrollbar {
	height: 1.5ex;
	 -webkit-border-radius: 1ex;
 	}

pre::-webkit-scrollbar-thumb {
	border-top: 1px solid #fff;
	background: #ccc -webkit-gradient(linear, 0% 0%, 0% 100%, from(rgb(240, 240, 240)), to(rgb(210, 210, 210)));
       -webkit-border-radius: 1ex;
      -webkit-box-shadow: 0 1px 3px rgba(0, 0, 0, .4);
}

The result: CSS3 Scrollbar

So there it is: a nice, subtle scrollbar redress for WebKit that uses no images, comes in at ≈ a dozen lines of CSS, doesn't murder the markup or b0rk the behavior, and degrades to a regular widget on non-Webkit browsers.

Caveats

This CSS obliterates the arrows, which is fine with me but conflicts with Lukas' maxim. I don't think I'm alone in that I can't recall the last time I clicked the arrow on a scrollbar, and users that are still using their un-bescrollwheeled 1996 Microsoft Mouse are probably not interested in any code I present here, anyway. You can skin the arrows, of course, but it about triples the about of CSS necessary.

Oh, and If you don't want the gradient and dropshadow on the scrollbar, you can accomplish a [tweetie](http://www.atebits.com/tweetie-mac/)-like scrollbar with just a couple lines: 


pre::-webkit-scrollbar {
    height: 1ex;
    }

pre::-webkit-scrollbar-thumb:horizontal{
    background: rgba(0, 0, 0, .2);
    }

If you're on WebKit, it's the scrollbar you see on the code samples on this site.