Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“We would be willing to set up a $2,500 bounty to implement scrollbar styling”

bugzilla.mozilla.org

Post reply on HN
Print view View original

61–70 of 87 posts

Re: “We would be willing to set up a $2,500 bounty to implement scrollbar styling”

#61

Post by callmevlad »

radley wrote: post #28

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.

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.

Re: “We would be willing to set up a $2,500 bounty to implement scrollbar styling”

#62

Post by userbinator »

scrollaway wrote: post #54
userbinator wrote: post #53

Earlier quoted context omitted.

but want their app to look native. 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'…

Sometimes I feel as if I'm talking to programmers who have zero design experience. 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.

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.

Re: “We would be willing to set up a $2,500 bounty to implement scrollbar styling”

#63

Post by radley »

callmevlad wrote: post #61
radley wrote: post #28

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.

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...

Re: “We would be willing to set up a $2,500 bounty to implement scrollbar styling”

#64

Post by userbinator »

bluthru wrote: post #15
OmarIsmail wrote: post #13

Earlier quoted context omitted.

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.

>Websites already implement their own scroll bars - Gmail, Google Spreadsheets, etc. As an OS X user who enjoys not seeing scrollbars, I find Google's use of them downright intrusive.

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.

Re: “We would be willing to set up a $2,500 bounty to implement scrollbar styling”

#65

Post by SwellJoe »

callmevlad wrote: post #59
SwellJoe wrote: post #9

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 t…

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. 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 ov…

"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.

Re: “We would be willing to set up a $2,500 bounty to implement scrollbar styling”

#67

Post by DanBC »

NathanKP wrote: post #35
esrauch wrote: post #17

Earlier quoted context omitted.

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…

> edge case

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.

Re: “We would be willing to set up a $2,500 bounty to implement scrollbar styling”

#68

Post by DanBC »

SwellJoe wrote: post #9

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 t…

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.

Re: “We would be willing to set up a $2,500 bounty to implement scrollbar styling”

#69

Post by dredmorbius »

dangrossman wrote: post #21
SwellJoe wrote: post #9

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 t…

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.

http://codepen.io/dredmorbius/pen/azrmZW

Re: “We would be willing to set up a $2,500 bounty to implement scrollbar styling”

#70

Post by dredmorbius »

DanBC wrote: post #68
SwellJoe wrote: post #9

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 t…

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…

Actually, there are at least two more functions:

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.

Post reply on HN