Hacker News new | past | comments | ask | show | jobs | submit login

There are 15-year old bugs in Firefox on scrollbar designs that are fixed under Chrome/Webkit.

Often times custom scrolling is used to fix that.




The solution here is simple -- lobby W3C to include custom scrollbar colors in the CSS specs, then call out Mozilla for not following the standards.

As it is, colored scrollbars are not part of any standard, so asking for them are like asking Google or Mozilla to support ActiveX for your webapp -- if you rely on non-standard, proprietary features, you're locked in to your non-standard browser.


Can you provide more details about what you're talking about?


https://bugzilla.mozilla.org/show_bug.cgi?id=77790

We could remove 90% of custom scrollbar javascript if this was fixed.


I'll give you three guesses which I care about more, a scroll bar that matches your site colors or responsive scrolling.


You're not the site designer, though.

Guess what the site designer cares about?

Their site is their branding, not yours, not Mozilla's.


If the "designer" only cares about the look of their site, then they're an artist, not a designer. Usability and accessibility are intrinsic parts of web design.


And if their brand is "confusing and hard to use" or worse, "glitchy" then I guess making their own scroll bars is appropriate.

Back when splash pages were popular I pretty much closed any tab that presented a splash page -- life is too short. Likewise whizzy Flash sites. What I miss about Flash is that it was an excellent bozo avoidance system.


Obvious solution is obvious. If the user is using Firefox, instead of replacing the scroll bars, replace the page with a message telling them to switch to a better browser. That way everybody wins and it's so much less work.


Or more obviously - if a browser works a certain way, and the user has chosen to use it, let it be. If the designer doesn't like it, well - the user chose to use this browser, and they choose to use your site. If you start trying to change one of their choices, they might change the other.


This is just confirmation that I'm better off with a most javascript and CSS turned off.


Maybe fix it then? Or better yet, don't fiddle with users' UI items. The scrollbar is the same everywhere on my desktop, why fiddle with a thing that the user's really used to?


Because designs on the web are different from those on desktops and big white scrollbars on a dark design look horrific? Also, because you want your design to work nicely irrespective of the browser and scrollbars and dropdowns make that really hard.

It sucks, but there's a reason that people choose to try to replace these elements (unfortunately, with mixed results).

For future reference, you can actually get rid of nasty scrollbars without ruining the normal scroll behaviour by having an outer div(overflow:hidden, width:x) containing the content div(width:x+scrollbar-width).


> Because designs on the web are different from those on desktops and big white scrollbars on a dark design look horrific?

Where do you draw the line, though? The scrollbar is not part of the website, it's part of the window where the website is being rendered, and the window is itself part of a desktop environment. Would you try to override the look and feel of the desktop environment if you could?


>Would you try to override the look and feel of the desktop environment if you could?

The answer to this question is almost always yes by short sighted designers who try to control scrolling behavior. In fact optimally they'd like to control your hardware look and feel also.


There's a difference between changing behaviour and changing the design. I'd imagine that most designers that design without scroll bars have no idea what the devs are going to do to change behaviour.

I hate it when the scrolling feels unnatural. At the same time, it's good when the design looks nice. It's possible to achieve both of those things.


Because it is also present in chromeless (aka full screen) mode.


There's a difference between the whole window and an element within the page. We have a single page app that still had scroll bars for subsections in the sidebar and quick frankly, it's embarrassing.


Fair enough. I don't think it's such a big deal, though. Probably no one cares how it looks as much as you think they do.


It truly sucks, as you said. Also, the web pages are within my browser's chrome, which occupies about a third of my screen, and behind it there's my wallpaper, and behind my screen I've a nice champagne-colour wall and some books, pens, and other stuff. What will you do if your design looks off in front of them? Change them too? Should the browser allow you to change the wallpaper?

Nasty scrollbars. OK. What if I want to scroll down about a third of a hypothetical long page? I'd either use the wheel/touchpad and make multiple gestures to reach there, or hit space/page down multiple times, or hit end and page up a bit less times, or just point the mouse cursor to about where I want to go on the scrollbar and click on the blinking thing. That nasty scrollbar is mine.


Once again, it's possible to have scrollbars that function as normal but fit with the design of the page.


> Maybe fix it then?

A 16-year old bug with 200+ comments sure looks easy to fix…


This is not really a bug but a wontfix (seemingly). Firefox has its own toolkit so it should be easier than writing a whole slew of JS to fix that bug (a.k.a. add this feature).


It could be I'm on windows and maybe you are not, but it's common for me to see different styles of scrollbars in different applications.


Well I use Emacs and Firefox and mostly nothing else, on Xubuntu, and all the scrollbars are (happily) the same.


Would not it be better to style the scrollbar with CSS only in browsers that support it? That would be an example of progressive enhancement and adaptive markup.

For me, fast scrolling is more important than colored scrollbar.


No.


Have you (or anyone else) offered a patch? Skimming that bugzilla page, it looks like in 15 years nobody has cared enough to even submit a patch.


It seems there's only a small overlap between the people suffering and the people being able to solve this.

If a "normal" web developer struggles with that, they can provide JavaScript workarounds, perhaps many, but they usually aren't that intimate with C/C++ and the whole framework on which Firefox is based.

Also, as with most projects, if a webdev can solve this problem with a workaround now, they don't invest time to provide a proper long-term solution. If if they are capable of improving Firefox, they'd still need to create the JS workaround, because short-term is what they are paid for.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: