Friday, March 20th, 2009

WebKit now let’s you style scrollbars

Category: Browsers, CSS

There are a couple of camps out there that like to argue between “let me change anything I want” and “don’t give developers power as they will build crappy things.”

In today’s context, that would be “have you seen the crappy Flash scrollbars that are SO hard to use?”

After having to deal with this in Bespin, I am very happy to see that Dave Hyatt and co have added the ability to style scrollbars via CSS:

The scrollbar pseudo-element indicates that an object should use a custom scrollbar. When this pseudo element is present, WebKit will turn off its built-in scrollbar rendering and just use the information provided in CSS.

  1. ::-webkit-scrollbar {
  2.     width: 13px;
  3.     height: 13px;
  4. }

The width and height properties on the scrollbar element indicate the width of the vertical scrollbar and the height of the horizontal scrollbar. Percentages can be specified for these values as well, in which case the scrollbar will consume that percentage of the viewport area.

A scrollbar consists of scrollbar buttons and a track. The track itself is further subdivided into track pieces and a thumb. The track pieces represent the areas above and below the thumb.

In addition the scrollbar corner can now be styled, as well as the resizer used by resizable textareas.

Here is a complete list of all the new pseudo-elements. All of these pseudo-elements must be prefixed with -webkit-.


Each of these objects can be styled with borders, shadows, background images, and so on to create completely custom scrollbars that will still honor the settings of the operating system as far as button placement and click behavior.

James Roe (in a comment) pointed to the various hacky ways in which we have had to do this in the past:

Creating out own scrollbars and messing with positioning divs begone! I can think of a couple of places that I can use this in Bespin off the top of my head.

Posted by Dion Almaer at 1:10 am

3.1 rating from 34 votes


Comments feed TrackBack URI

Eeek, it’s bad enought that it’s possible in IE … leave my browsers alone, I like them just fine the way they are!!!

Comment by MorganRoderick — March 20, 2009

“WebKit now let’s you style scrollbars” = bad grammar
let’s = let us
lets = 3rd person of “let”

Comment by Diodeus — March 20, 2009

I agree with MorganRoderick. I think it’s best to leave the appearance of browser controls up to the user, not the developer.

Comment by WillPeavy — March 20, 2009

Afraid I’ll have to disagree. It may be YOUR browser, but it’s MY web page, and scrollbars exist in more places then on the edge of your screen.The fugly OS/browser default can clash with the theme of your site, especially when its that god awful transparent blue one Safari uses.
It’s not as if disallowing the ability to apply css styles eliminates the desire to change the appearance. Many libraries exist to provide this functionality and its about time more browsers adopt this trend natively. For example:
Paranoid that this will be abused? I don’t think it will, how many sites do you see today that overuse this feature in IE when it has existed for a number of years now?

Comment by TNO — March 20, 2009

I’m going to write a plugin that scans a page, finds all the elements that have overflow: hide, set them to overflow: scroll and then color the scrollbars so that all of the individual elements match the background color.

Just kidding, I probably will stay away from this feature for usability reasons. Sometimes the hardest part of UI design is knowing what to leave out.

Comment by zachleat — March 20, 2009

Won’t somebody think of the children?!

Comment by jamiethompson — March 20, 2009

I think it’s important to remember that it’s WEBKIT not just Safari. Why? Because iPhone and Android use webkit, and so does Adobe AIR – this means that webheads can create full-blown apps that look and feel exactly how they want without branching too much into new technologies.

This is good

Comment by oopstudios — March 20, 2009

I don’t think that the usability argument is solid.
First of all, you can break usability by many other ways, for instance by setting overflow to hidden and having NO scrollbars at all which is far worse than colored scrollbars :P:P
Secondly, if we think like that, then why should we be able to style form elements? Text selections (via CSS3)? Even links! Why should we style links? Let them in their default underlined #00f and presto! Even the worst noob will understand them. Or lists! Let’s leave the bullets or the numbers in the lists, let’s not use list-style-type:none, it can break usability! In fact, why not ditch CSS altogether and leave the html tags in their default? This way, no user will be confused, since all webpages will look almost the same!
What I’m trying to say is that we cannot and we should not force usability on anyone. We shouldn’t willingly restrict our toolkits so that our tools don’t get misused. Badly designed webpages existed since the very beginning of the web and they’ll probably exist for ever, so we’ll just end up restricting these people that would create something nice with these tools. If someone wants to make a site unusable, it’s very easy to do so even with simple HTML. The penalty they’ll get is losing customers. And I find that fair enough.

Comment by LeaVerou — March 20, 2009

Microsoft added the ability to style scrollbars to IE about ten years ago. Pretty much all it’s good for is in the design of ridiculous user profiles.

Comment by WillPeavy — March 21, 2009

You’re preaching to the chair.

Comment by Jordan1 — March 21, 2009

No, no, no. Please don’t. This is another just awful idea from the WebKit guys. Did they miss styling the IE scroll bars or something?

Somebody there needs to read a book about UI design.

First off, one rule about app UI design, don’t change the OS default chrome. This includes the scroll bars.

@TNO changing the OS chrome is a UI no no. As you said, it is your web “page”. It is not your computer application and even if it were, you wouldn’t want to change the chrome then either. Even if it is in a web page, it still is the window chrome.

@oopstudios Even if it’s for let’s say an AIR app, you should use the default chrome. Has everyone totally forgotten about the most basic UI design principles?

@WillPeavy exactly my point. The only people that would use this feature are non designer folk that think it looks “cool”.

Comment by oscargodson — March 23, 2009

All arguments that go along the lines of “Don’t mess with the UI” are totally invalid since you’re all talking about SAFARI and not actually WebKit – need I remind anyone that the Safari port to windows already screws with the UI? Brushed metal anyone?

That aside – WebKit is primarily a *rendering engine* and if you wanted to use it for something other than “websites and that” – then custom scrollbars might be a good idea. Agreed, garish is bad, but the choice is *always* good

Comment by oopstudios — March 23, 2009

changing the OS chrome is a UI no no
This being the web, do you know what the chrome will look like on all of the end machines and OS/browser/user setting combinations? Do you know how it will effect your layout? We already have to ability to hide it completely, why not have the ability to fine tune it as well? The chrome that Opera uses and the one Safari used to use are not OS native anyway.

Comment by TNO — March 23, 2009

While I can agree that changing the actual window chrome is a bad idea (I would never use this on the main window’s scrollbars), embedded scroll areas such as iframes or scrolling divs would be seriously improved by this with some layouts. Ever had a scrolling div on a dark background? The OS scrollbars stick out like a sore thumb, it’s garish at best.

Comment by Chiper — March 24, 2009

For those saying don’t screw with the UI, are you aware that even in OS X, Apple does use custom scroll bars in some fairly high profile places, for very good reason and with generally decent results? The most obvious case being CoverFlow. Similar use is here:

Which isn’t to say it can’t be misused or even abused. But the way I look at it, the nature of web technologies is such that you are generally forced to use non-standard UI for most components (as there is no UI standard from which to render various native UI components, and as most UI components do not have web equivalents); why, then, should you be expected to make your UI conform to the vastly varying range of UI conventions with regards to scrollbars of all things? If it is beneficial to conform the scrollbars to the rest of the non-standard UI of your web application, why not do it? Just don’t do it in such a way that it’s unusable or undiscoverable.

Comment by eyelidlessness — March 24, 2009

That so many people are faking scrollbars because the standard just doesn’t suit the design is reason enough to implement this property. And design is not just gravy either, it’s about getting the user from A to B without them even being aware of it (ideally), standard UI elements on an otherwise fully designed page can interrupt this. Of course, there is no accounting for bad design but that isn’t the job of the browser vendor, that’s the job of the designer, if his design fails the site fails. The buck rests with him.
Now that we have different kinds of devices to browse the web not faking should surely be top priority for developers. Mobile Safari, for example, deals with the SELECT element in different way, this could occur on any new device for any element, so using the right element in the right place is now more important than ever. I don’t want to be stuck with a faked scrollbar that won’t work on my device when a standard scrollbar is just dandy. (if only people has a decent framework for dropdown menus)
Furthermore, styling scrollbars isn’t messing with the chrome anymore than styling a button is. We don’t always want gel buttons and the user has the graphical language to understand that a button doesn’t always look like that, just as they do a scrollbar. And besides, webkit currently doesn’t allow the styling of the main window scrollbar anyway, not that we couldn’t fake it.

Comment by StuartJ — March 25, 2009

Leave a comment

You must be logged in to post a comment.