Nicely done. Isn't it going to be better if you hide the scrollbar when you are not actually scrolling? Like Facebook does for their chat and ticker bars.
The difference between these custom scrollbars is that (in modern browsers) they are still scrollbars that work exactly like other scrollbars and only look different.
Except they don't, try using the arrow keys to navigate in the scrollable DIV. Not working for me (Firefox latest stable). It also scrolls ridiculously slowly using the mouse wheel. So we're actually going backwards in functionality.
No, you see, those were non-standard back when "non-standard" was demonized so we could give Microsoft shit for not doing what we want. We've sense realized that what we want to do isn't standard either, just in a different way from what IE did. Now we do whatever the fuck we want and wait for the standards to play catch-up.
Native widgets with reliable behavior and useability be damned; it looks pretty and thats what we've always really wanted.
Native scroll bars are ugly. I agree that if you're going to override them they should function exactly the same. Modern browsers actually do provide a standard way to re-style them. So if you want to be consistent design-wise on older browsers a javascript solution is necessary.
How am I supposed to know something is scrollable if the scroll bar is hidden unless I'm hovering over it with my mouse? What if I'm using the keyboard?
Hi I'm James. The one who did the plugin. It isn't fully finished yet, it was something I did in my spare time. But I wanted to get it up asap so I could hear people's feedback. Thanks for your inputs so far.
I don't understand what all this pseudo-innovation in scroll bar technology is accomplishing. I first saw it in google wave, which drastically changed the way that scroll bars behaved, and the way I had to interact with them. More recently, I've upgraded Ubuntu and now Unity has funky, unintuitive scroll bars. What is the holy grail of scroll bar usability, and is this getting us any closer? I'm not really feeling the advantages.
Edit: as per slig's comment, a lot of tools in google's latest design refresh are using terrible scroll bars, too.
Many web browsers already have this functionality (sort of) with middle-click.
Forcing the user to navigate to some tiny on-screen affordance which takes up screen real estate is a terrible design (except in the special case where the scroll bar is at the extreme edge of the screen).
Mobile web browsers seem to get this right. Touch the element you want to scroll & drag it; an overlay pops up to show your relative location. Intuitive, easy, and doesn't take up screen real estate.
Scroll wheels (especially Kensington's beautiful "Orbit" scroll rings on their trackballs) are pretty close to the mark too.
You're the website, you deliver me content, I decide what to do with it. Don't take really long ways around to force me to do things your way, use semantic HTML and CSS, use the default scroll bars, let me pick a user-agent that makes scroll-bars the way I want. I don't want to use OSX Lion scroll bars because I think mac's are lame, but now I have no choice.
The custom scrollbar is actually meant for scrollable div layers. (e.g. logs for chat-based applications). I needed a way to get rid of the thick native scrollbar skin for a javascript-dev project to match the overall design. Hence, why I came up with it.
So you came up with a solution that even on Lion doesn't use current scrollbar style (always visible mouse one/thin trackpad one), doesn't use kinetic scrolling if it's enabled, doesn't obey scroll speed preferences and doesn't even scroll in the same direction as the rest of things? That's just marvelous; I hope I'll never have to use your software.
Matching the overall design is not an excuse for doing such a thing.
It changes the default behaviour & design of standard scrollbars and this is a serious design flaw.
I'm really glad your wrote this. It's just the solution I'm looking for. Uber-geeks will always complain about custom scroll bars, but the rest of society appreciates the clean design.
That's not about uber-geeks. It's simply about usability. And the rest of the society will not complain about the failing usability but it will notice it.
Seems to do the same job whilst respecting lion scroll direction (Haven't tested with standard scrolling so there's a chance they could have just imitated reverse scrolling)
Too many custom scrollbar projects (including this one) make the mistake of overriding everything helpful the browser does for you and then imperfectly reimplementing it.
The best technical approach is to make the scrollable element naturally scrollable with overflow: auto, and then put it inside a viewport element (overflow: hidden) narrow enough to cut off the scrollbar (there are plugins that can help you figure out exactly how wide the host's OS's scrollbars are).
Then, you're free to listen for scroll events and overlay your own custom scroller UI.
I agree that it is best to let the browser handle the scrolling mechanics. Then you simply hide the original scrollbar by having an embedded div hold the content with a width thats about 40px or so bigger than the outer, fixed width div ( and overflow: scroll-y ).
I've also made my own scrollbar for a project, so I have enhanced super vision to see the edge cases:
1) scrollbar disappears on drag when the mouse moves out of the container. To fix you need to have a flag when the scrollbar is dragging and not call fadeout when true.
2) convenient UI feature: scrollbar can appear on hover, then disappear if user hasn't moved mouse, and reappear on mousemove. This is done in Facebook for example. This is accomplished by setting and clearing timeouts.
(also, the bot left container for the scrollbar doesn't have a rounded corner)
James, great work and thanks for effort to make it even better.
Now for all people that cry about cross browser difference, you ought to put you energy at criticizing developers that create browsers that are not compatible with w3c standards.
I for one do not want to see same boring scrollbars until I die. Let's be realistic, browser scrollbars haven't changed in the past 20 years (except the option to change colors and that was wow back in the day). It's about time that they do.
49 comments
[ 4.6 ms ] story [ 94.4 ms ] threadFuck the design if it's unusable.
Native widgets with reliable behavior and useability be damned; it looks pretty and thats what we've always really wanted.
Edit: Just updated to 16.0.912.59 beta-m (newest on this channel), still working in reverse. OS: XP.
Edit: as per slig's comment, a lot of tools in google's latest design refresh are using terrible scroll bars, too.
Many web browsers already have this functionality (sort of) with middle-click.
Forcing the user to navigate to some tiny on-screen affordance which takes up screen real estate is a terrible design (except in the special case where the scroll bar is at the extreme edge of the screen).
Mobile web browsers seem to get this right. Touch the element you want to scroll & drag it; an overlay pops up to show your relative location. Intuitive, easy, and doesn't take up screen real estate.
Scroll wheels (especially Kensington's beautiful "Orbit" scroll rings on their trackballs) are pretty close to the mark too.
You're the website, you deliver me content, I decide what to do with it. Don't take really long ways around to force me to do things your way, use semantic HTML and CSS, use the default scroll bars, let me pick a user-agent that makes scroll-bars the way I want. I don't want to use OSX Lion scroll bars because I think mac's are lame, but now I have no choice.
Seems to do the same job whilst respecting lion scroll direction (Haven't tested with standard scrolling so there's a chance they could have just imitated reverse scrolling)
Section "Violating Design Conventions".
This is exactly why you shouldn't implement/use other scrollbars and similar things which change the behaviour of standard design practices.
The best technical approach is to make the scrollable element naturally scrollable with overflow: auto, and then put it inside a viewport element (overflow: hidden) narrow enough to cut off the scrollbar (there are plugins that can help you figure out exactly how wide the host's OS's scrollbars are).
Then, you're free to listen for scroll events and overlay your own custom scroller UI.
I agree that it is best to let the browser handle the scrolling mechanics. Then you simply hide the original scrollbar by having an embedded div hold the content with a width thats about 40px or so bigger than the outer, fixed width div ( and overflow: scroll-y ).
1) scrollbar disappears on drag when the mouse moves out of the container. To fix you need to have a flag when the scrollbar is dragging and not call fadeout when true.
2) convenient UI feature: scrollbar can appear on hover, then disappear if user hasn't moved mouse, and reappear on mousemove. This is done in Facebook for example. This is accomplished by setting and clearing timeouts.
(also, the bot left container for the scrollbar doesn't have a rounded corner)
otherwise great job!
Now for all people that cry about cross browser difference, you ought to put you energy at criticizing developers that create browsers that are not compatible with w3c standards.
I for one do not want to see same boring scrollbars until I die. Let's be realistic, browser scrollbars haven't changed in the past 20 years (except the option to change colors and that was wow back in the day). It's about time that they do.
Oh and, IE should be banned forever :)