I like it better as-is. As the top HN comment mentions, it's very interesting to skim the whole history, and see how times have changed. And how they haven't.
And this is basically why I hate the obstinacy of Mozilla.
It is not difficult to find discussions that spans more than one decade, where the official consensus is "web authors: get screwed, we would rather die than to add X feature".
Yet, I will never understand why Mozilla decided to implement some -webkit-prefixes to Firefox not that long ago, since their arguments can be reused in any neverending bug report like this one.
I'm against the webkit/blink monoculture that many web authors wished we had, but at this point I don't know what to expect.
One part of me applauds whenever a new website (ex. Mega or WhatsApp Web) launches without support for Firefox at day one, because ignoring Firefox is the way Mozilla will eventually stop their obstinacy.
But other part of me gets sad, because Firefox is the only feasible alternative the web has against webkit/blink, and the web can't afford to have a weak alternative against a monoculture.
I can only hope IE/Spartan to become a feasible alternative, because I can't expect Mozilla to stop their obstinacy until they have no choice.
> It is not difficult to find discussions that spans more than one decade, where the official consensus is "web authors: get screwed, we would rather die than to add X feature".
And yet, this doesn't appear to be the case here:
> People, people. We already know what the solution is to be -- binding XBL to pseudo-elements. There is no point commenting here. We all know you want it. If you're not volunteering to fix it, please don't comment at all.[0]
Rather, nobody seems to have stepped up to actually implement the feature for the past decade, wich isn't all that surprising since implementing this seems to be quite the effort:
> (1) this is a pretty involved bug; it would take weeks to months of work for a full-time engineer[1]
Should we consider an anti-bounty system where we agree to pay more to the foundation for not implementing a `feature`? I personally, don't like websites breaking the 4th wall.
The scroll bar is (or should be!) OS-controlled. Why give people the opportunity to muck up the scroll bar and add their crazy ideas. The browser belongs to the user, not the website.
Any kind of power, including the ability to style buttons, text-areas or scroll-bars, can be abused. There's always some people that (quite reasonably) feel that widespread abuse of that power justifies withdrawing it, and some people that (quite reasonably) feel that the few really good uses outweigh the potential for abuse.
When I come to a website, it's usually because I want some particular piece of information (like movie times or ticket prices) or to have some particular interaction (to find new, interesting stories or to play a game). Good design (and good designers) keep that goal in mind, and support it by keeping distracting elements (possibly including weird, mis-styled scrollbars!) to a minimum, allowing me to focus.
Less-good designers just aim for making something more-or-less cohesive, and bad designers rarely aim higher than "something cool" whether or not it supports my goal. Mediocre and bad design hinders me from achieving my goal by hiding or obscuring basic tools of interaction like buttons or scroll-bars. Even good design can be a problem, if my goals do not align with what the designer had in mind (for example, the designer wants to make a good impression for first-time customers, but I'm trying to file a customer-support ticket).
I appreciate that many of the people commenting on that ticket are just trying to make the world a more pleasant place, but some times I wish browsers had a button that would blast away all the custom styling of a page and just display the content in a standardised fashion (like the Reader mode many browsers have, but not just limited to long-form articles).
If you want such a button, search for bookmarlets. I usually install one that makes all fonts the same (large) size and one that forces all texts to B/W. Can't live without it.
I agree, and I personally really hate it when websites provide their own scrolling mechanism, as it usually doesn't support two-finger (mouse wheel) scroll, doesn't have acceleration, doesn't have my OS scroll speed, etc. IMO overriding scroll bars on your site / app is almost always a bad idea, as it leads to poor UX / usability.
Edit: I'd also extend my opinion to cover things like a strip of items which must be scrolled through using other UI elements (e.g. Arrows or bubbles). While cute (maybe), this only allows uses to scroll at the one speed you give them. Just put it in a horizontal scroll or better yet, do something completely different.
I think this may be a proposal to allow for scrollers that behave natively but are visually unrecognizable as such. While in theory that may allow for the worst offenders to rein things in a bit, I suspect it will more likely be taken as an invitation for people to make their sites less usable and accessible.
I absolutely agree that reimplementing scrolling logic is absolutely awful. It's an accessibility nightmare.
But scrollbar styling is very different to scrolling logic. We're not talking about stealing people's mousewheels here, we're talking about changing scrollbar themes.
This is important for apps which want native scrolling logic inside their app but want their app to look native. The only alternative, in fact, is to reimplement scrolling logic inside the app. Performance suffers, accessibility suffers, everyone loses.
Shouldn't you not be attempting to modify the appearance of the scrollbars and letting them be the style the OS chooses, if you want them to look "native"? These developers seem to be wanting scrollbar styling so they can make scrollbars look different from their native appearance.
There are also quite a few truly native apps which have reinvented scrollbars instead of using the OS', and they are awkward to use because they don't behave exactly like native ones do.
You said "want their app to look native", and I'm saying that, if you do not apply any styling, the most native-looking and native-behaving things in the app probably are the scrollbars.
...or are we not agreeing on what "native" means? I've long thought it referred to the default appearance/behaviour of the OS/browser.
First off, because it isn't. There are a number of things that personally shouldn't be styled. Or rather, there are a number of things that should have their styles overridable without breaking things.
There are an astounding number of things I've seen abused, badly. I mean - look at the number of websites that aren't usable without a web font because they embedded all of their icons in it. Bonus points if they load the web font via JS. Bonus points if it's third-party JS.
Secondly, you cannot style every other UI component except this one. The browser chrome. The mouse pointer. The context menu (to an extent, depending on browser).
The thing with scrollbars is that they are at the boundary between the website and the browser. There are pros and cons - allowing "good" websites to apply "good" styles, but not for inane UIs.
Personally, I think that the better approach would be for the browser to color the scrollbar dependent on the background color of the page.
Websites already implement their own scroll bars - Gmail, Google Spreadsheets, etc.
It would be nice if instead of having to reimplement _everything_ about the scrollbar to just add a feature or two, the native one was customizable. Because frankly, people are going to change it, so might as well make things less buggy.
This is a good point - users are accustomed to the scrollbar style of the system they're using (which is often an adjustable preference), so it makes sense for scrollbars in web apps to follow what the OS does.
While my scrollbar preferences are very different from yours (I prefer ones that are always-visible, large and easy-to-grab), I agree that the web apps you use should conform to your UI preferences, and not the other way around.
Gmail uses webkit scrollbar styling, they don't reimplement scrollbars from scratch. If you go to gmail in Firefox it uses the stock scrollbars, which is really a major advantage to Firefox in my mind. It's kind of like when Chrome stopped supporting the <blink> tag even though webkit still supported it.
Basically all of the times that I see this feature being used it is to make tiny, mostly transparent, or auto-hiding scrollbars that don't match the system UI at all and are a significant nuisance. I'm sure there are some sites that are styling them reasonably, but it doesn't seem to be the norm, even for the major players that have experienced design teams.
Remember, it's not just the main scrollbars at the top and bottom of the window. Some pages have internal text regions with scrollbars, and it seems reasonable to style those. Those aren't browser UI, they're UI of the page.
And, in between, there are the scrollbars on iframes and overflowed divs. They're almost always suppressed entirely... because the defaults are so ugly.
I was reading through this, just laughing and laughing at how ridiculous it was that people in 2001 thought changing the color of the scroll bar was somehow important or useful. I was all, "Hahah, people were very silly in 2001, and the web was a very silly place."
Then, as the years crept ever forward, I began to realize this isn't a blast from the past...it's not like a discussion about the blink tag. It's a real thing that people still actually give a shit about 14 years later! My whole perspective on the thread changed.
I'm just gonna say that I have never once, in my entire 20+ years of building things on the web, wanted to change the color of the browser scroll bar. Until I read this thread I wouldn't have even realized someone would want to change the scroll bar. It seems like such an odd thing to do, and I'm imagining it looking silly, like something out of a 2001 page design (but maybe it doesn't look silly when done well).
But, I'm not a designer. Maybe I just don't get it. Either way, I use Firefox, and I do not care whether the scroll bar color can be changed.
Edit: I don't mean to insult folks who do think this is a useful feature. I'm really just expressing my genuine surprise at the entire tone of the linked thread. I don't oppose inclusion of this feature, and lots of people have mentioned valid reasons why they want it. I will likely never truly understand it, or share that desire, but I'm certainly not gonna get scrappy about it. And, I probably wouldn't even notice, if it did become available in Firefox tomorrow.
We do find it useful on http://Clara.io in the editor (you have to be logged in to see them) -- we have a complex UI and the standard thick scroll bar is ugly and much too large. So we thin them down and simplify the styling so that they fit more into the overall UI. It is a very pleasing difference.
This is just my one experience (and you certainly know better the needs of your own product) but you are gaining "that looks nice" in exchange for "this is harder to use because the target is smaller and harder to click".
The action of clicking the scrollbar is more of an edge case than a significant design cornerstone these days. Most people are going to be scrolling with a mouse wheel, or a two finger swipe on their touchpad, etc. Clicking and dragging a control is slower, and a fundamentally bad experience in the first place.
The only practical purpose of the scrollbar in modern design is to serve as a visual indicator that an area can be scrolled, and to show location and scale.
If you have a reasonably complicated web app there is a good chance you are going to need a scrolling view inside your page. You still need a scrollbar to show that the area can be scrolled, but using the default control styling looks really ugly.
Really? Have you got any numbers for this, or are you actually saying "this is how I use it, and I presume most people are like me"? Because what you're saying simply isn't true for me.
When I'm reading a long block of content, I'll often click the scroll thumb and keep it clicked, using either the mouse or trackpad (or trackball, for that matter) to seek proportionally through the page. You don't get that proportionality of motion with either the mouse wheel or the two-finger trackpad gestures which mimic it.
The "most people" argument you're making is what leads to broken ideas like infinite scrolling, which appeals to one subset of the population who assume that everyone else uses their UI in precisely the same way that they do.
So given that you like to use the scrollbar in that matter which would you rather see:
1) A native scrollbar that is restyled to match the colors of the webpage it is in?
2) A janky web view with scrollbars hidden and then reimplemented in JS which doesn't function they way you want it to?
Like it or not designers usually don't spend time on the subset of the audience that clicks and drags the scrollbar. They spend time drawing a pretty looking scrollbar.
When it comes to the implementation personally I think it still better to have a scrollbar that functions the way you expect it to, even if it looks a little different, rather than ending up with many different reimplementations of the scrollbar by different programmers.
Of the two, 1) is the less bad option. This seems obvious to me. It is wrong to treat the scroll bar as only visual element and not an input element; that's what I take issue with.
> Like it or not designers usually don't spend time on the subset of the audience that clicks and drags the scrollbar. They spend time drawing a pretty looking scrollbar.
If the designers in question, who are working on a user interface element, don't consider how users will interface with it, it's fair to criticise them for not doing their jobs.
A large chunk of those edge cases are people with disabilities.
I have colleagues with a variety of learning disabilities. They strongly reject the label "disability".
"Dan, when someone gives me a document that I can't understand, and I tell them that I can't understand it, they often say 'well, of course you dont understand it, you are learnig disabled'. So what they're doing is transferring the blame for the lack of understanding from them to me. It's somehow my problem that I don't understand this document. But here's the thing: it's not my job to understand that document. I don't get paid to understand that document. It is their job to provide information in a meaningful accessible way, and they've failed. In this country they might even have a legal duty to make the information accessible. Or they might be paid from public funds to make the information accessible. I'm not disabled unless you chose to disable me."
This strong challenge echoes what some people with physical disabilities say: "my wheelchair is not the problem. You putting a step in front of your shop is the problem; you holding meetings in inaccessible buildings is the problem."
This kind of styling makes things slower, harder to use, more expensive to build and maintain. Just worse overall. The web would be a better place if people stopped doing it.
I'm not a designer either, but I can see their point of view: they're being paid to make a website internally consistent, and if they can't style scrollbars, then either they're stuck with a bland, vapid style that looks reasonable across all platforms, or they make something that's cool and awesome and makes their clients happy right up until the first scroll-bar appears, at which point it looks ridiculous (in particular, think about a <textarea> where you can style the border to match all your other form-fields, but not the scroll-bar, so you wind up with two visual styles pressed right up against one another). Being responsible for something you can't really control is frustrating for anyone, so I have a measure of sympathy for the designers who want stylable scrollbars.
If you'd like to know what a custom CSS scrollbar looks like in practice, in 2015, log in to your Google Analytics account (I noticed you use it on your website) with Chrome. Not only do people want to change the scroll bar, but probably half the internet-using population sees custom scroll bars daily, since Google uses them heavily (Gmail, Docs, etc as well).
Google's screwing with scrollbars, especially, making them so damned tiny I cannot use them, is among the reasons I looked up how to style scrollbars -- so I could set my own local default style in a user stylesheet and override idiot Web designers (or their idiot clients) who think they know better than I do what I want.
What I've ended up with is actually fairly close to the Mac OS X scrollbar, though I kind of got there by accident.
And no, in general, I wouldn't impose this on other people on a site I built. Leave stock UI interfaces alone.
I don't think it's just the browser's scrollbars one the side, and sometimes the bottom, of the page. It's all scrollbars inside the page as well. They're traditionally considered part of the OS UI so are left alone. At the moment, people who really want to change the scrollbars internal to the page can replace them with js scrollbars.
I don't necessarily want to change the color (although, why not?), I mostly just want to change the width of the bar. Having a huge, fat, white and grey scroll-bar on an overflowed `div` right in the middle of my sleek, dark-themed site with integrated 3D (both CSS and WebGL) elements just sticks out more than a huge, swollen thumb. For now I've set `direction: rtl;` so that it blends into the left-side of the page and is hopefully overlooked by most people.
I'm surprised to see this point of view upvoted so much. If you browse the web through chrome you might not notice it because you can style the scrollbar in chrome.
But if you scroll the same websites in Firefox (which is my main browser), those will stand out. It's not only the scrollbar of the page, it's also any scrollbar that you can see inside a iframe or a textarea or really any divs with overflow:scroll;
If you think this is silly then you must think CSS and styling page is silly
I think it has to do with my approach to the web, and my preferences for web design. I like minimalism, generally speaking, and I like consistency. I think Google UIs are fine. But, I don't use Chrome, so I don't know what the difference is. Maybe it would be amazing with custom-styled scrollbars. But, I'm content with them looking like my native OS scrollbars (I use Linux/Gnome 3, so they are grey, flat, and slim; quite unobtrusive on any page, whether light or dark).
I also tend to find most dark web designs (which is what a lot of these comments are talking about) just plain ugly. So, that's another factor. I've never made a dark website or web UI.
All of this is opinion, of course. My opinion should probably matter less than someone that really cares a lot about it.
I think it's silly because I think the way so many people approach web design is silly. Standardized UI components are not a bad thing. They are a very good thing. I like it when web pages look like they belong on my computer screen.
It's not only dark web designs. Actually if you look at any native application on your OS you will see "styled" scrollbars. And that never shocked you because they are styled according to the app.
> I like it when web pages look like they belong on my computer screen.
This is what "view > page style > no style" is for.
CSS was created to "style" page, and the scrollbar is part of the page. That you like CSS or not it seems silly to say that the scrollbar is the limit where you can style everything BUT the scroll bar on a page.
The scroll bar isn't part of the page. A scroll bar appearin or not is controlled by the window size, and that's controlled by the browser and window manager and those are controlled by the user.
The page designer has no control over the display size.
I understand what you are trying to say. It's hard to realize when you are not looking at it but actually, any field with "overflow:scroll" has a scroll bar. And you can control the size of those fields. If you pay attention you will see that a huge amount of websites do have scrollbars in their design, many avoid them because they can't be stylized in firefox, and many use javascript to try to style them.
I'm the guy who offered the bounty, and for us (webflow.com) it's not about styling scrollbars on ordinary websites - it's about making sure application user interfaces are consistent across browsers.
Webkit's ability to style scrollbars gives app developers a ton more control over a user interface. Some advantages of Webkit over Firefox here:
* Custom styling without hacky JavaScript "fake scroll" scripts
* Control over the width of a scrollbar
* Better usability for certain use cases by enabling Up and Down buttons
* Scrollbars actually look like they belong inside the application
* Doesn't remind users that they're in a web browser
In my 15+ years of building websites, I never wanted to change the color of the browser scroll bar either. But now I'm building a website that builds websites, so it's a whole 'nother ball game :)
"Custom styling without hacky JavaScript "fake scroll" scripts"
You've convinced me. I did have someone once send me a design patch that used a JavaScript scrolly implementation, and I found it repulsive on every level, and I immediately rolled back the change and made it clear we would never ship anything like that, ever.
I'm glad you're in a position to motivate someone to implement it with cold hard cash, and I hope it works out.
I question the necessity of having to make scroll bars consistent across browsers.
Seeing as how most people only use one browser (data collected out of thin air), wouldn't changing the native styling on a browser scrollbar be confusing for people expecting the native styling?
First off, that doesn't work without JS. I mean really: It's a couple of screenshots.
Secondly, I prefer it. Far too many websites adjust things to the point where it's impossible to actually see. (Case in point: link styling. To the point where I have bookmarklets to remove styling from pages.)
I understand having the option to do so. But at the same time, I wouldn't use said option. To me, readability > aesthetics. And far too many websites don't respect that.
You need to start differenciating between "documents" and "applications". What GP linked is a full-blown application. There's no "non-javascript" version of it.
I have been watching comments here and it is absolutely infuriating how it's very obviously armchair designers with zero experience in the field who are yelling out "aesthetics don't matter, scrollbars should always look like my system's scrollbars".
First of all, that is a ridiculous statement. On Linux for example there is no "system scrollbars", the styling is up to the toolkit and it is different in every single web browser out there. There's no consistency to be had across applications.
Second of all, every other toolkit element can be styled. Buttons. Dropdown menus. Text fields. Everything.
They can all be styled not so your "documents" will be less readable, but so that developers and designers are empowered to create applications that look good, feel fluid, native, consistent.
They can be styled because applications can be more than just 20-input field forms. Native applications have the power to style their scrollbars (and they do so all the time), so web applications need it too to match such capabilities. We're not talking about an unused feature here.
And to those complaining about scrolling behaviour, accessibility etc: Those are the exact reasons why we need scrollbar styling. Because when your company is hounding you to have scrollbars that don't look out of place on a major browser "and look, our competition does it", you're realistically not just going to tell them "well, uh, readability is important". You're going to use fake, pure-js scrollers and accessibility will suffer. Everybody loses.
This isn't about purple scrollbars for your text documents.
From my perspective, at the very least, the link was a means of showing a couple of screenshots.
Is it a full-blown application? Sure, I guess. But I could care less about that.
The actual content is a couple of screenshots - not exactly something that requires JS.
Also, I'm not speaking about designers at all. I am not a website designer, and never claimed to be one.
I'm speaking as someone who uses a web browser. As I said earlier: To me, readability > aesthetics. Especially as I'm often on-the-go. Things that look better but are lower contrast are often unreadable when you've got any amount of glare on the screen.
I use one web browser for the majority of my browsing. So yes, there is consistency. I'm not talking about across applications, I'm talking about within an application.
It may not be about purple scrollbars for your text documents, but that's what it will largely end up being used for.
And yes, native applications have a greater power to style things. But there is a distinction. Native applications inherently require greater trust. I'm not going to install any random application that comes my way.
Also, there are applications I stay away from precisely because of that - precisely because they have weird styling, and weird UIs. Case in point: Github's desktop application. Great program - or would be if I could get over the UI. But as is, I don't tend to use it.
That being said, it's a bit of a moot point regardless. It's just yet another thing I'll add to the list of bookmarklets to disable things to make websites readable. Along with many of the other things you mention as people being able to style as features.
> It may not be about purple scrollbars for your text documents, but that's what it will largely end up being used for.
Taking away freedoms from developers should only ever be done for security reasons. Not because you're scared they'll "misuse it and make ugly apps". Who cares about "ugly apps"? They are weeded out over time by natural selection.
The web today is two things: a document delivery system; and an app delivery system.
Sadly the two functions have merged and so people deliver their documents in their apps. It's incredibly restrictive and a step backwards. Content that would be fine with a bit of html and css and leave the browser to display it is now wrapped up in extra css and javascript just because PHBs and bad designers insist on pixel perfect cross browser design.
1. A media interface / playback system for audio/video content.
2. A commerce platform.
Arguably, a communications platform for both realtime interactive and asynchronous messaging. Some of that probably arguably does belong in the browser, though much could go elsewhere.
The problems that accompany this are not just the complexity you describe, but bloat, security nightmares, stability and interactivity issues, and more.
I started calling for at least a 4-way split about a year ago, and I suspect it may emerge, though through simplified tools (likely eBook readers) acquiring more web-like capabilities.
The increasing tendency of browser vendors to incorporate Readability (or similar functionality) directly into their browsers seems to be one positive sign that there's an awareness of the problem.
To the naysayers: styling scrollbars has a very valid use-case. Two IDEs that I use most at work are Visual Studio 2012 and JetBrains PyCharm. I always switch to the dark theme on both, and try to use dark styling whenever possible. Simply because the amount of light from two 24" displays can be overwhelming. Both IDEs style the scrollbars to conform to the dark theme. You cannot do that in browser, unless you resort to emulating the scrollbar, like e.g. CodeMirror did. Light grey scrollbars on otherwise dark screens are immediately noticeable and distracting.
> Simply because the amount of light from two 24" displays can be overwhelming.
Have you ever tried f.lux? Or maybe monitors with variable brightness? (Apple's Thunderbolt displays have a light sensor and adjust automatically, probably others as well)
May I also add that Redshift is an alternative on Linux and there are multiples on iOS and Android. These apps and bright light therapy have done numbers on my shift-work disorder.
Thank you for recommendation, for whatever reason I did not know (forgot) that f.lux works on Windows. f.lux changes color temperature, not brightness. I tried changing overall brightness level with controls, but that unavoidably reduces contrast which is just as bad.
I remember when we first did this on IE5.5. It fell out naturally from some improvements to the rendering system and a dev (forgot his name! Don?) prototyped it to show off his new subsystem. It eventually got supported because, at the time, we would do anything we could to differentiate.
Scroll bars stand in an uncomfortable place with one foot on the WM side and the other in the application. The user wants to be able to control the size, scale, and position of the window without asking permission from the app. (And who was the evil programmer who gave web sites the ability to disable zooming? But I digress.) But an app that's at the mercy of the operating system for drawing its scroll bars is going to lose usability if it wants to provide infinite scrolling, or simulate a slide-show with vertical position. In those cases it would be better to let the app control the appearance of the scroll bars.
Which is to say, the regular window scroll bar that we're familiar with is being overloaded for two different purposes: to interact with the app and to interact with the WM. Perhaps we should have two scroll bars to avoid this confusion?
I think the simple solution is adding a "light/dark" setting for browsers. We certainly don't need every color of the rainbow (omg gross), but this simple option could be universal and solve most requests.
Better yet, the browsers should easily be able to predict the dominant color of the page by parsing the CSS file and most of the DOM, and pick a complimentary scrollbar contrast accordingly. Maybe do that and allow override to light/dark.
Or, just allow the element to be styled like every other thing on the page. Because...why not again? Imaginary 4th wall that the bar is the only thing on the page that should not be stylable? So that it can match the scroll bars of native applications?
You think users want their browser text to change color / shape / width per web page?
Page scroll is not the only place scrollbars are useful. If you have an overflowing div in the middle of the page, a fat white/grey scrollbar is confusing.
I don't think anyone who wants this wants to change the color. They want to change the shape (border-radius), or make the scrollbar "flat" (no 3D "groove" border), or translucent, or thinner, or etc. etc. etc.
A pro designer isn't going to ask for any of those things (but bad clients will). There's no reason to confuse users with unique UI designs per page. That's just bad UX.
The reason I said only light / dark is that it's easy for users to understand. Remember: these guys are asking to change the UI of the browser on a per web page basis. That kind of customization doesn't help anyone.
Actually, that would not solve the issue that led me to offer the bounty.
Check out the difference between the scrollbars in Webflow rendered across Webkit (Safari, Chrome, Opera) and Firefox: https://cloudup.com/c8K9RMqPeDn
Note that not only does Webkit give you control over colors, it gives you control over the width/height of the scrollbar - which for us is critically important.
I understand what you're asking for, but when available those settings are usually set by the user, not the webpage.
Customization is a very, very slippery slope: can the web page only customize the slider? What about the tab? Why not the entire frame of the browser? The drop shadow of the window? Opacity? Alpha mask? Why just the sliders? Why not just the tab? Ahhhh....
If the web page can change the style, can the user have a setting to override it? If you make a custom style, will M$, Apple, iOS, or Android influence your design in a particular direction (i.e. ends up looking like something ported from iOS)? Or will you custom design for each system? Like, Blackberry? Or just the popular systems?
BTW - I did HD Widgets for Android. Tons of customization. A lot of it was barely used by our users. Sometimes I wish I had kept it much, much simpler. App updates can be hell...
> Customization is a very, very slippery slope: can the web page only customize the slider?
I can't believe what I'm reading. Honest question: Have you ever used css?
The scrollbar is one of extremely few elements living inside the browser frame which cannot be styled.
The scrollbar on the outside of the page doesn't matter. What matters is all the scrollbars that appear when you deal with iframes, scrolling divs etc.
For app builders, when scrollbar styling is not available, what do you think they do? They don't give up, they just implement scrolling in js instead, and accessibility/usability suffers.
86 comments
[ 3.3 ms ] story [ 156 ms ] threadhttps://bugzilla.mozilla.org/show_bug.cgi?id=77790#c188
And this is basically why I hate the obstinacy of Mozilla.
It is not difficult to find discussions that spans more than one decade, where the official consensus is "web authors: get screwed, we would rather die than to add X feature".
Yet, I will never understand why Mozilla decided to implement some -webkit-prefixes to Firefox not that long ago, since their arguments can be reused in any neverending bug report like this one.
I'm against the webkit/blink monoculture that many web authors wished we had, but at this point I don't know what to expect.
One part of me applauds whenever a new website (ex. Mega or WhatsApp Web) launches without support for Firefox at day one, because ignoring Firefox is the way Mozilla will eventually stop their obstinacy.
But other part of me gets sad, because Firefox is the only feasible alternative the web has against webkit/blink, and the web can't afford to have a weak alternative against a monoculture.
I can only hope IE/Spartan to become a feasible alternative, because I can't expect Mozilla to stop their obstinacy until they have no choice.
And yet, this doesn't appear to be the case here: > People, people. We already know what the solution is to be -- binding XBL to pseudo-elements. There is no point commenting here. We all know you want it. If you're not volunteering to fix it, please don't comment at all.[0]
Rather, nobody seems to have stepped up to actually implement the feature for the past decade, wich isn't all that surprising since implementing this seems to be quite the effort:
> (1) this is a pretty involved bug; it would take weeks to months of work for a full-time engineer[1]
[0] https://bugzilla.mozilla.org/show_bug.cgi?id=77790#c125 [1] https://bugzilla.mozilla.org/show_bug.cgi?id=77790#c173
I'm sorry, I can't take this sort of complaint seriously...
Are we here to fight lame design fads by preventing people from building cool apps?
Less-good designers just aim for making something more-or-less cohesive, and bad designers rarely aim higher than "something cool" whether or not it supports my goal. Mediocre and bad design hinders me from achieving my goal by hiding or obscuring basic tools of interaction like buttons or scroll-bars. Even good design can be a problem, if my goals do not align with what the designer had in mind (for example, the designer wants to make a good impression for first-time customers, but I'm trying to file a customer-support ticket).
I appreciate that many of the people commenting on that ticket are just trying to make the world a more pleasant place, but some times I wish browsers had a button that would blast away all the custom styling of a page and just display the content in a standardised fashion (like the Reader mode many browsers have, but not just limited to long-form articles).
Edit: I'd also extend my opinion to cover things like a strip of items which must be scrolled through using other UI elements (e.g. Arrows or bubbles). While cute (maybe), this only allows uses to scroll at the one speed you give them. Just put it in a horizontal scroll or better yet, do something completely different.
But scrollbar styling is very different to scrolling logic. We're not talking about stealing people's mousewheels here, we're talking about changing scrollbar themes.
This is important for apps which want native scrolling logic inside their app but want their app to look native. The only alternative, in fact, is to reimplement scrolling logic inside the app. Performance suffers, accessibility suffers, everyone loses.
Shouldn't you not be attempting to modify the appearance of the scrollbars and letting them be the style the OS chooses, if you want them to look "native"? These developers seem to be wanting scrollbar styling so they can make scrollbars look different from their native appearance.
There are also quite a few truly native apps which have reinvented scrollbars instead of using the OS', and they are awkward to use because they don't behave exactly like native ones do.
Behaviour is not the same as styling. A good app's scrollbars will behave natively but will look in line with the rest of the app.
Compare GMail's scrollbars, especially the ones for the XMPP Chat, between Firefox and Chrome.
...or are we not agreeing on what "native" means? I've long thought it referred to the default appearance/behaviour of the OS/browser.
There are an astounding number of things I've seen abused, badly. I mean - look at the number of websites that aren't usable without a web font because they embedded all of their icons in it. Bonus points if they load the web font via JS. Bonus points if it's third-party JS.
Secondly, you cannot style every other UI component except this one. The browser chrome. The mouse pointer. The context menu (to an extent, depending on browser).
The thing with scrollbars is that they are at the boundary between the website and the browser. There are pros and cons - allowing "good" websites to apply "good" styles, but not for inane UIs.
Personally, I think that the better approach would be for the browser to color the scrollbar dependent on the background color of the page.
It would be nice if instead of having to reimplement _everything_ about the scrollbar to just add a feature or two, the native one was customizable. Because frankly, people are going to change it, so might as well make things less buggy.
As an OS X user who enjoys not seeing scrollbars, I find Google's use of them downright intrusive.
While my scrollbar preferences are very different from yours (I prefer ones that are always-visible, large and easy-to-grab), I agree that the web apps you use should conform to your UI preferences, and not the other way around.
Basically all of the times that I see this feature being used it is to make tiny, mostly transparent, or auto-hiding scrollbars that don't match the system UI at all and are a significant nuisance. I'm sure there are some sites that are styling them reasonably, but it doesn't seem to be the norm, even for the major players that have experienced design teams.
Disclaimer: I'm the guy who submitted the bounty :)
http://imgur.com/a/mkbHB
Then, as the years crept ever forward, I began to realize this isn't a blast from the past...it's not like a discussion about the blink tag. It's a real thing that people still actually give a shit about 14 years later! My whole perspective on the thread changed.
I'm just gonna say that I have never once, in my entire 20+ years of building things on the web, wanted to change the color of the browser scroll bar. Until I read this thread I wouldn't have even realized someone would want to change the scroll bar. It seems like such an odd thing to do, and I'm imagining it looking silly, like something out of a 2001 page design (but maybe it doesn't look silly when done well).
But, I'm not a designer. Maybe I just don't get it. Either way, I use Firefox, and I do not care whether the scroll bar color can be changed.
Edit: I don't mean to insult folks who do think this is a useful feature. I'm really just expressing my genuine surprise at the entire tone of the linked thread. I don't oppose inclusion of this feature, and lots of people have mentioned valid reasons why they want it. I will likely never truly understand it, or share that desire, but I'm certainly not gonna get scrappy about it. And, I probably wouldn't even notice, if it did become available in Firefox tomorrow.
The only practical purpose of the scrollbar in modern design is to serve as a visual indicator that an area can be scrolled, and to show location and scale.
If you have a reasonably complicated web app there is a good chance you are going to need a scrolling view inside your page. You still need a scrollbar to show that the area can be scrolled, but using the default control styling looks really ugly.
Really? Have you got any numbers for this, or are you actually saying "this is how I use it, and I presume most people are like me"? Because what you're saying simply isn't true for me.
When I'm reading a long block of content, I'll often click the scroll thumb and keep it clicked, using either the mouse or trackpad (or trackball, for that matter) to seek proportionally through the page. You don't get that proportionality of motion with either the mouse wheel or the two-finger trackpad gestures which mimic it.
The "most people" argument you're making is what leads to broken ideas like infinite scrolling, which appeals to one subset of the population who assume that everyone else uses their UI in precisely the same way that they do.
1) A native scrollbar that is restyled to match the colors of the webpage it is in? 2) A janky web view with scrollbars hidden and then reimplemented in JS which doesn't function they way you want it to?
Like it or not designers usually don't spend time on the subset of the audience that clicks and drags the scrollbar. They spend time drawing a pretty looking scrollbar.
When it comes to the implementation personally I think it still better to have a scrollbar that functions the way you expect it to, even if it looks a little different, rather than ending up with many different reimplementations of the scrollbar by different programmers.
> Like it or not designers usually don't spend time on the subset of the audience that clicks and drags the scrollbar. They spend time drawing a pretty looking scrollbar.
If the designers in question, who are working on a user interface element, don't consider how users will interface with it, it's fair to criticise them for not doing their jobs.
A large chunk of those edge cases are people with disabilities.
I have colleagues with a variety of learning disabilities. They strongly reject the label "disability".
"Dan, when someone gives me a document that I can't understand, and I tell them that I can't understand it, they often say 'well, of course you dont understand it, you are learnig disabled'. So what they're doing is transferring the blame for the lack of understanding from them to me. It's somehow my problem that I don't understand this document. But here's the thing: it's not my job to understand that document. I don't get paid to understand that document. It is their job to provide information in a meaningful accessible way, and they've failed. In this country they might even have a legal duty to make the information accessible. Or they might be paid from public funds to make the information accessible. I'm not disabled unless you chose to disable me."
This strong challenge echoes what some people with physical disabilities say: "my wheelchair is not the problem. You putting a step in front of your shop is the problem; you holding meetings in inaccessible buildings is the problem."
This kind of styling makes things slower, harder to use, more expensive to build and maintain. Just worse overall. The web would be a better place if people stopped doing it.
What I've ended up with is actually fairly close to the Mac OS X scrollbar, though I kind of got there by accident.
And no, in general, I wouldn't impose this on other people on a site I built. Leave stock UI interfaces alone.
http://codepen.io/dredmorbius/pen/azrmZW
But if you scroll the same websites in Firefox (which is my main browser), those will stand out. It's not only the scrollbar of the page, it's also any scrollbar that you can see inside a iframe or a textarea or really any divs with overflow:scroll;
If you think this is silly then you must think CSS and styling page is silly
I also tend to find most dark web designs (which is what a lot of these comments are talking about) just plain ugly. So, that's another factor. I've never made a dark website or web UI.
All of this is opinion, of course. My opinion should probably matter less than someone that really cares a lot about it.
I think it's silly because I think the way so many people approach web design is silly. Standardized UI components are not a bad thing. They are a very good thing. I like it when web pages look like they belong on my computer screen.
It's not only dark web designs. Actually if you look at any native application on your OS you will see "styled" scrollbars. And that never shocked you because they are styled according to the app.
> I like it when web pages look like they belong on my computer screen.
This is what "view > page style > no style" is for.
CSS was created to "style" page, and the scrollbar is part of the page. That you like CSS or not it seems silly to say that the scrollbar is the limit where you can style everything BUT the scroll bar on a page.
The page designer has no control over the display size.
Take a look at this comparison between Chrome and Firefox: https://cloudup.com/c8K9RMqPeDn
Webkit's ability to style scrollbars gives app developers a ton more control over a user interface. Some advantages of Webkit over Firefox here:
* Custom styling without hacky JavaScript "fake scroll" scripts
* Control over the width of a scrollbar
* Better usability for certain use cases by enabling Up and Down buttons
* Scrollbars actually look like they belong inside the application
* Doesn't remind users that they're in a web browser
In my 15+ years of building websites, I never wanted to change the color of the browser scroll bar either. But now I'm building a website that builds websites, so it's a whole 'nother ball game :)
You've convinced me. I did have someone once send me a design patch that used a JavaScript scrolly implementation, and I found it repulsive on every level, and I immediately rolled back the change and made it clear we would never ship anything like that, ever.
I'm glad you're in a position to motivate someone to implement it with cold hard cash, and I hope it works out.
Seeing as how most people only use one browser (data collected out of thin air), wouldn't changing the native styling on a browser scrollbar be confusing for people expecting the native styling?
Assuming you were using Firefox, what would you think about those two white scrollbars that stick out like a sore thumb in a dark interface?
Secondly, I prefer it. Far too many websites adjust things to the point where it's impossible to actually see. (Case in point: link styling. To the point where I have bookmarklets to remove styling from pages.)
I understand having the option to do so. But at the same time, I wouldn't use said option. To me, readability > aesthetics. And far too many websites don't respect that.
Please read JS;DR: http://tantek.com/2015/069/t1/js-dr-javascript-required-dead
You need to start differenciating between "documents" and "applications". What GP linked is a full-blown application. There's no "non-javascript" version of it.
I have been watching comments here and it is absolutely infuriating how it's very obviously armchair designers with zero experience in the field who are yelling out "aesthetics don't matter, scrollbars should always look like my system's scrollbars".
First of all, that is a ridiculous statement. On Linux for example there is no "system scrollbars", the styling is up to the toolkit and it is different in every single web browser out there. There's no consistency to be had across applications.
Second of all, every other toolkit element can be styled. Buttons. Dropdown menus. Text fields. Everything. They can all be styled not so your "documents" will be less readable, but so that developers and designers are empowered to create applications that look good, feel fluid, native, consistent.
They can be styled because applications can be more than just 20-input field forms. Native applications have the power to style their scrollbars (and they do so all the time), so web applications need it too to match such capabilities. We're not talking about an unused feature here.
And to those complaining about scrolling behaviour, accessibility etc: Those are the exact reasons why we need scrollbar styling. Because when your company is hounding you to have scrollbars that don't look out of place on a major browser "and look, our competition does it", you're realistically not just going to tell them "well, uh, readability is important". You're going to use fake, pure-js scrollers and accessibility will suffer. Everybody loses.
This isn't about purple scrollbars for your text documents.
Is it a full-blown application? Sure, I guess. But I could care less about that.
The actual content is a couple of screenshots - not exactly something that requires JS.
Also, I'm not speaking about designers at all. I am not a website designer, and never claimed to be one.
I'm speaking as someone who uses a web browser. As I said earlier: To me, readability > aesthetics. Especially as I'm often on-the-go. Things that look better but are lower contrast are often unreadable when you've got any amount of glare on the screen.
I use one web browser for the majority of my browsing. So yes, there is consistency. I'm not talking about across applications, I'm talking about within an application.
It may not be about purple scrollbars for your text documents, but that's what it will largely end up being used for.
And yes, native applications have a greater power to style things. But there is a distinction. Native applications inherently require greater trust. I'm not going to install any random application that comes my way.
Also, there are applications I stay away from precisely because of that - precisely because they have weird styling, and weird UIs. Case in point: Github's desktop application. Great program - or would be if I could get over the UI. But as is, I don't tend to use it.
That being said, it's a bit of a moot point regardless. It's just yet another thing I'll add to the list of bookmarklets to disable things to make websites readable. Along with many of the other things you mention as people being able to style as features.
Taking away freedoms from developers should only ever be done for security reasons. Not because you're scared they'll "misuse it and make ugly apps". Who cares about "ugly apps"? They are weeded out over time by natural selection.
http://imgur.com/a/mkbHB
Sadly the two functions have merged and so people deliver their documents in their apps. It's incredibly restrictive and a step backwards. Content that would be fine with a bit of html and css and leave the browser to display it is now wrapped up in extra css and javascript just because PHBs and bad designers insist on pixel perfect cross browser design.
1. A media interface / playback system for audio/video content.
2. A commerce platform.
Arguably, a communications platform for both realtime interactive and asynchronous messaging. Some of that probably arguably does belong in the browser, though much could go elsewhere.
The problems that accompany this are not just the complexity you describe, but bloat, security nightmares, stability and interactivity issues, and more.
I started calling for at least a 4-way split about a year ago, and I suspect it may emerge, though through simplified tools (likely eBook readers) acquiring more web-like capabilities.
https://www.reddit.com/r/dredmorbius/comments/256lxu/tabbed_...
The increasing tendency of browser vendors to incorporate Readability (or similar functionality) directly into their browsers seems to be one positive sign that there's an awareness of the problem.
Have you ever tried f.lux? Or maybe monitors with variable brightness? (Apple's Thunderbolt displays have a light sensor and adjust automatically, probably others as well)
Long time ago...
Which is to say, the regular window scroll bar that we're familiar with is being overloaded for two different purposes: to interact with the app and to interact with the WM. Perhaps we should have two scroll bars to avoid this confusion?
Page scroll is not the only place scrollbars are useful. If you have an overflowing div in the middle of the page, a fat white/grey scrollbar is confusing.
Check out the difference between the scrollbars in Webflow rendered across Webkit (Safari, Chrome, Opera) and Firefox: https://cloudup.com/c8K9RMqPeDn
Note that not only does Webkit give you control over colors, it gives you control over the width/height of the scrollbar - which for us is critically important.
Customization is a very, very slippery slope: can the web page only customize the slider? What about the tab? Why not the entire frame of the browser? The drop shadow of the window? Opacity? Alpha mask? Why just the sliders? Why not just the tab? Ahhhh....
If the web page can change the style, can the user have a setting to override it? If you make a custom style, will M$, Apple, iOS, or Android influence your design in a particular direction (i.e. ends up looking like something ported from iOS)? Or will you custom design for each system? Like, Blackberry? Or just the popular systems?
BTW - I did HD Widgets for Android. Tons of customization. A lot of it was barely used by our users. Sometimes I wish I had kept it much, much simpler. App updates can be hell...
I can't believe what I'm reading. Honest question: Have you ever used css?
The scrollbar is one of extremely few elements living inside the browser frame which cannot be styled.
The scrollbar on the outside of the page doesn't matter. What matters is all the scrollbars that appear when you deal with iframes, scrolling divs etc.
For app builders, when scrollbar styling is not available, what do you think they do? They don't give up, they just implement scrolling in js instead, and accessibility/usability suffers.
http://imgur.com/a/mkbHB
https://bugzilla.mozilla.org/show_bug.cgi?id=38467