Last Comment Bug 77790 - (scrollbar-colors) Style the scrollbar (binding ::-moz-horizontal-scrollbar to XBL)
(scrollbar-colors)
: Style the scrollbar (binding ::-moz-horizontal-scrollbar to XBL)
Status: NEW
DON'T COMMENT UNLESS YOU ARE FIXING I...
:
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: All All
: -- enhancement with 232 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Jet Villegas (:jet)
Mentors:
: 81397 132366 141565 146846 150255 158318 171849 174173 178651 204981 207113 214651 216820 234486 236568 245052 256444 271158 281696 285787 299456 310725 311502 405827 419058 431187 464683 547260 646960 971105 1090029 1168282 (view as bug list)
Depends on: 21890
Blocks: 164421
  Show dependency treegraph
 
Reported: 2001-04-26 14:57 PDT by Skewer
Modified: 2016-12-06 15:19 PST (History)
150 users (show)
deprecationmail: wanted1.9.2?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
?


Attachments
draft and testcase (4.17 KB, text/html)
2002-07-25 08:22 PDT, Kai Lahmann (is there, where MNG is)
no flags Details
next version of draft and testcase (4.18 KB, text/html)
2002-07-25 08:52 PDT, Kai Lahmann (is there, where MNG is)
no flags Details
Styled form elements with Toy Factory theme (53.02 KB, image/png)
2002-09-09 18:37 PDT, Bamm Gabriana
no flags Details
tomorrow.do view in FX vs Chrome (76.42 KB, image/png)
2013-01-04 11:05 PST, mihal.v
no flags Details
compare scrollbars Chrome vs Firefox (296.25 KB, image/png)
2013-11-17 05:27 PST, Mikhail
no flags Details

Description Skewer 2001-04-26 14:57:30 PDT
Proposal: Mozilla should support the scrollbar-(blah)-color properties
implemented in IE5.5. This would be a minor enhancement, but add an impressive
and unprecedented level of control for developers that currently only exists in IE.

Assigned to: Skinablity since this is the largest hurdle in adding this
functionality. I'm thinking authors should have "alternate" scollbars that are
displayed when one of these CSS properties is used, and specify an RGB color
that will be replaced by the type of scrollbar color specified in the document,
or if unspecified go to a default value (such as
"255,0,0>scrollbar-arrow-color>0,0,0" to make red arrows turn to the arrow
color, or if there is none, black). Good luck doing this, it won't be easy...
Comment 1 Garth Wallace 2001-04-26 15:49:25 PDT
I'm not sure about this. AFAIK those things aren't even CSS3--I don't think we
should really be copying proprietary CSS properties. Actually, until I found out
that the color changes were based on CSS, I'd assumed that whenever the IE
scrollbars changed color to match the background, it was a rendering bug in IE. :)
Comment 2 Matthew Paul Thomas 2001-04-26 16:43:18 PDT
Oh Hixie, invalidate?
Comment 3 Hixie (not reading bugmail) 2001-04-26 23:42:22 PDT
We already almost support this ourselves with XBL. Not quite sure how it's going
to work for scrollbars though. Check back after mozilla 1.1. I'm marking this
bug WONTFIX, we'll think about it though.
Comment 4 Skewer 2001-05-13 19:01:10 PDT
Verifying resolved bugs.
Comment 5 Boris Zbarsky [:bz] (still a bit busy) 2001-05-17 07:14:36 PDT
*** Bug 81397 has been marked as a duplicate of this bug. ***
Comment 6 Sören 'Chucker' Kuklau (gone) 2002-02-24 11:43:47 PST
We could add -moz-scrollbar-* (e.g. vendor-specific) properties and evangelize
sites to offer both. See also a discussion on n.p.m.wishlist:

http://groups.google.com/groups?hl=de&threadm=a5au07%24nmb1%40ripley.netscape.com&prev=/groups%3Fhl%3Dde%26group%3Dnetscape.public.mozilla.wishlist
Comment 7 Boris Zbarsky [:bz] (still a bit busy) 2002-03-20 18:42:43 PST
*** Bug 132366 has been marked as a duplicate of this bug. ***
Comment 8 Alfonso Martinez 2002-05-01 14:10:10 PDT
*** Bug 141565 has been marked as a duplicate of this bug. ***
Comment 9 Bamm Gabriana 2002-05-08 01:28:30 PDT
I agree with Comment #6. It would be nice to have a Mozilla extension for
this, but prefixing it with -moz- to indicate that it is not standard CSS.

So many authors would love to have this support as it would offer them
greater control over their sites's look.

I would like to give as an example an astronomy site I maintain. I gave
textareas slightly grayed backgrounds (as pure white is blinding on a black
background), and I would like the textarea's scrollbar to match by giving
it a dark color.

------

One problem I see with this though is the use of images for the scrollbar
arrows. Perhaps if we could influence the foreground color of a monochrome
image by CSS (related to Bug 140226) this would be implementable.
Comment 10 Alfonso Martinez 2002-05-24 15:13:36 PDT
*** Bug 146846 has been marked as a duplicate of this bug. ***
Comment 11 Matthias Versen [:Matti] 2002-06-08 14:02:44 PDT
*** Bug 150255 has been marked as a duplicate of this bug. ***
Comment 12 Markus Hübner 2002-07-24 11:20:15 PDT
Now we have 1.1b - what can be done about that now?
Comment 13 Max 2002-07-24 15:14:50 PDT
An option in the preferences dialogue should be added so that coloured
scrollbars can be allowed.
Comment 14 Skewer 2002-07-24 18:16:03 PDT
Wasn't this confirmed at some point? Oh well, it is now.

I don't think an option is necessary, though it would be nice to have an option
somewhere in case *somebody* finds styled scrollbars annoying. Then again it'd
be nice to have an option for everything.
Comment 15 Kai Lahmann (is there, where MNG is) 2002-07-25 07:28:02 PDT
I suppose to add:
  -moz-scrollbar-arrow-color (the arrows)
  -moz-scrollbar-face-color (the rest)
  -moz-scrollbar-track-color (the background)

..and support these on _every_ Element which has a Scrollbar, not only body,
html and textarea. Also make them inherited.
At this point it starts to make sense - the current IE implementation is rather
silly, as it has a property for erevy pixel and many bad effects.

'transparent' for -moz-scrollbar-track-color should also be allowed and results
in the background image/color extending to this area

if any of these values is set, we'll show the scrollbar in a flat view, no
matter what theme is used.
Comment 16 Kai Lahmann (is there, where MNG is) 2002-07-25 08:22:45 PDT
Created attachment 92743 [details]
draft and testcase

adding a draft about my suggestions. It also works as a testcase for the
properties which should be added.
Comment 17 Kai Lahmann (is there, where MNG is) 2002-07-25 08:52:35 PDT
Created attachment 92745 [details]
next version of draft and testcase

ok, this time with an eye friendly example - sorry for the spam...
Comment 18 Max 2002-07-25 11:05:23 PDT
I'm glad work is being done here, I really want this feature implemented.

-- M. :-)
Comment 19 Jesse Ruderman 2002-07-29 10:16:38 PDT
*** Bug 158318 has been marked as a duplicate of this bug. ***
Comment 20 Christian :Biesinger (don't email me, ping me on IRC) 2002-08-18 11:12:59 PDT
I don't think this bug should be fixed. Web pages should not be allowed to
change browser chrome - this confuses users.
Comment 21 Skewer 2002-08-18 22:30:51 PDT
How is a colored scrollbar not acceptable if JavaScript windows without any
chrome (or even completely borderless) are? Both can allow the developer very
nice effects, both can be misused, and the latter is much worse when misused
than the former.
Comment 22 Christian :Biesinger (don't email me, ping me on IRC) 2002-08-19 01:43:33 PDT
beause it's one thing if chrome isn't there, but it's a wholly other thing if
some random page changes the chrome.

I mean, websites can't install skins w/o user permission either. neither should
they be able to change the scrollbar color.
Comment 23 Markus Hübner 2002-08-19 02:17:44 PDT
I think we should integrate this, btw. this is far more used than marquee, and 
is a good thing for web-designers/developers who are trying to create a 
thorough look & feel. If some users don't want this we could have a preference 
flag to be able to turn this off if desired.
Comment 24 Max 2002-08-19 05:52:24 PDT
I completely agree, this is what I said before. It doesn't even have to be a
default option on. Konqueror currently allows styling of the scrollbar and it
does it very nicely. I'm sure Mozilla could do too. 

The option would be in the 'Appearences' section of the preferences dialog:

Scrollbar colouring:

- Allow the current web page to control the scrollbar colour instead of the
current theme.



-------

May I also point out that it cannot be difficult to implement this feature -
themes can already do so so basically it's already all there waiting to be used.
Comment 25 Sören 'Chucker' Kuklau (gone) 2002-08-19 08:34:12 PDT
How would you color Aqua scrollbars (especially the slider) without suddenly
making them extremely ugly?
Comment 26 Niklas Dougherty 2002-08-19 14:43:27 PDT
Per Apple Aqua user interface guides, Aqua elements are not subject to change --
at all. So changing the scroll bars in Aqua is really out of the question. IE
doesn't do this either, AFAIK. Rather, IE changes its icons and the URL bar to
different colors, either through the menu or by "CSS". This resembles what
happens in Mozilla when switching themes.

Now, if you want to make it possible to make the PC a veritable christmas tree,
go ahead, but please leave the Mac alone.

Applications share the same GUI details in order to make it easier for the user
to be productive. The place where things happen in apps, any app, is on the
canvas. Anything outside the canvas is off limits. Unrequested changes of the
GUI is hijacking my workplace.

It would also mean that there would be tweaks to the native API:s, so whenever
these change, there will be a problem. A long time ago menus in Mac OS were
white. Then this was changed to gray, but since some apps (notably from
Microsoft) had proprietary API:s, there were a mix of gray and white menus when
running these older apps on a new system.
Comment 27 Max 2002-08-20 08:22:31 PDT
Where there's a will, there's a way. And looking at the cc list above, there's
some interest in this proposal.

I don't think this feature should be implemented straight away, obviously there
has to be some trying out to see if it's possible (and I'm sure it is) etc. etc. . 

Then once everything seems ok then (hopefully) it can be tried out in a release.
Quite frankly, I think it's mad not for Mozilla to take advantage of this, and
with an option to switch it off, what the hell is the problem?
Comment 28 Andrew Pakula 2002-08-20 08:39:43 PDT
Why not implement it straight away or at least soon?

Look at all the comments for this CSS feature request, they date back over a 
year. How much longer until some work finally gets done on this?

The ability for the web page to be able to change the colors of the scroll bar 
is one of the main things I have wanted to see added to Mozilla for the longest 
time. I really hope some work will get done on this soon.
Comment 29 Sören 'Chucker' Kuklau (gone) 2002-08-20 08:43:28 PDT
Re: Comment #27 From ukmeatisrubbish@yahoo.co.uk 2002-08-20 08:22

> Where there's a will, there's a way. And looking at the cc list above, there's
some interest in this proposal.

Most will add themselves to a cc list because they want to know when a
particular bug gets fixed.

Many will add themselves because they want to know when it finally is marked
"WONTFIX" or "INVALID".

And some do it for other reasons.

I belong to the second group.

> Quite frankly, I think it's mad not for Mozilla to take advantage of this

What's the advantage of inconsistent system UI? Oh wait, most OS'es already have
it anyway, so let's just make it worse, nobody cares.

> , and
> with an option to switch it off, what the hell is the problem?

The problems with options are:

- we have many, many, many already
- 1% of the users *care* about options at all
- 1% of *those* 1% will actually *change* options
Comment 30 Skewer 2002-08-21 21:33:38 PDT
> Many will add themselves because they want to know when it finally is marked
> "WONTFIX" or "INVALID".

If it's marked INVALID I will be forced to reopen it, simply because INVALID
means that the bug doesn't actually happen (or in this case the enhancement was
already implemented, which it wasn't). Or it might apply if there turned out to
be an standard or restriction that prohibits user agents from supporting colored
scrollbars.

As far as inconsistent UI, I don't see how a colored scrollbar would create that
problem. As it is the scrollbars can be skinned to different colors anyway; the
only difference CSS would make is it would give control to the site author
instead of the skin designer. Our scrollbars aren't good enough for
mouse-scrolling apps anyway, so we can't do much more harm than we've already done.

The document scrollbars aren't even my biggest concern; I would just like to be
able to style the scrollbars in my textboxes, listboxes, frames, etc. Since I
can already change the borders and background on those things it seems natural
for the scrollbars to follow.
Comment 31 Alex Hosking 2002-08-22 11:39:27 PDT
It says Mozilla 1.2 in the keywords does that mean that this will be fixed by 
1.2 or was it put there by somone for no good reason?
Comment 32 Alex Hosking 2002-08-22 11:41:06 PDT
It says Mozilla 1.2 in the keywords does that mean that this will be fixed by 
1.2 or was it put there by somone for no good reason?
Comment 33 Christian :Biesinger (don't email me, ping me on IRC) 2002-08-22 13:30:03 PDT
mozilla1.2 as a keyword means that someone wants this to be fixed for 1.2.

to see when the assignee intents to fix this bug, see the target milestone field.
Comment 34 Max 2002-08-24 03:52:55 PDT
Why not 1.1 ? The sooner, the better :-)
Comment 35 Christian :Biesinger (don't email me, ping me on IRC) 2002-08-24 13:58:49 PDT
there's zero chance that a patch for this would at this point be accepted for
1.1 (well, sure, drivers decide that, but I wouldn't see why that'd get approval).
Comment 36 Jesse Ruderman 2002-08-26 16:53:45 PDT
http://www.useit.com/alertbox/20020819.html:
"Sometimes technological progress backfires, and the 'better' technology turns
out to be worse for users. The Web is no stranger to this problem, and has
experienced many innovations that would have been best avoided. Examples include
frames, changing the color of browser scrollbars, and scrolling text."

I vote for wontfix.
Comment 37 Markus Hübner 2002-08-26 17:55:22 PDT
Well, and still from a users / web-designers view they are highly appreciated.
Just browser state-of-the-art websites & portals - especially those that have 
a high design level. I don't think it's wise leaving out that big number 
people.
Comment 38 Andrew Pakula 2002-08-26 18:42:35 PDT
In reguards to what Markus Hübner said, I totally agree with what you said, that 
sums it up nicely and to what Jesse Ruderman said I would have to dissagree with 
you about which technology is good or bad, Frames for example are still used on 
a number of sites maybe not a lot of the larger sites however it used still and 
has its own advantages/dissadvantages just like any other feature. All we are 
asking is to have the option for scrollbar, those who want to use it on their 
sites and like wise those who don't want don't have to. I simply like the 
feature from a design prespective because it can give your site a more unique 
look.
Comment 39 Skewer 2002-08-27 07:25:07 PDT
The browser scrollbars don't have to be touched. I just want control over form
and frame scrollbars. Browser scrollbars would be nice (and make more sense for
controlling frame/iframe scrollbars, because they can fit the document that is
loaded instead of being assigned to the frame), but you can leave the main
scrollbars alone and still satisfy me. I just find it unpleasant to be changing
the border and background on form elements while we're still stuck with
ordinary, ugly Mozilla scrollbars. (And, in theory, an ugly browser skin could
ruin a good site!)
Comment 40 Niklas Dougherty 2002-08-27 10:34:27 PDT
"Ugly Mozilla scrollbars" is a bug in itself. Scrollbars and other UI elements
should of course be native. Fortunately, they are on Mac OS X, and I simply
don't want any so called web designer trying to change that. I am already using
a filtering proxy to get rid of all the "smart" stuff "web designers" sprinkle
onto my computer, since Mozilla's blocking methods are far from enough.

The web is defined by the W3C standards. Mozilla and others implement that with
applications. Extending the stuff from W3C to control the actual application
implementing the standards is a completely absurd thought. As absurd as the idea
of a skinnable Adobe Photoshop...

"state-of-the-art websites & portals" are usually highly tabled sites, with tons
of sliced pictures and Flash animations, essentially using the 1998 Netscape 4
paradigm with invalid code, inline scripting and excessive browser control.
Their popularity is based on content, not on design.

The *real* state-of-the-art sites are essentially all Mozilla advocacy sites out
there, with clean and strict code, resolution-independent liquid layout, and no
efforts to implement pixel-wise control for x browsers on y platforms (thereby
ignoring z cases of special needs).

It is when those designers finally migrate to the portals and other big content
sites that the revolution is complete and Mozilla has reached its goal.
Comment 41 Skewer 2002-08-27 14:32:25 PDT
You've completely ignored what I said about form controls and frames, so now
your argument is basically moot.

The scrollbar is something that should be as much controlled by the author as
background colors and border styles. Since scrollbars are an operating
system-dependent thing they were left out of the CSS recs. Such a style property
should exist both for the purpose of styling those scrollbars and to be prepared
in the event W3C picks up scrollbar styles (which I expect it will eventually).
Comment 42 Bamm Gabriana 2002-08-30 02:48:57 PDT
If we could change the background color of TEXTAREA, and then I don't see why we
can't do the same for its scrollbars. In a dark background, a white textarea
background is blinding, so a dark gray background and dark scrollbar keeps the
theme of the website consistent and is easier on the eyes.

http://www.upastrosoc.org/contact/
Comment 43 Bamm Gabriana 2002-08-30 02:59:29 PDT
If anyone has a patch for this, please let me know. I am preparing a
mozilla-based browser that will be included in the Bayanihan Linux project
(http://bayanihan.asti.dost.gov.ph/) in the Philippines where I am a volunteer.
I would love to have the colored scrollbar feature in my distribution.
Comment 44 Skewer 2002-09-04 13:48:38 PDT
There are two ways this could be implemented. We could use properties, like IE,
or use pseudo-classes. If we were to use pseudo-classes it would be much more
complex, introduce more opportunities for bugs, and be generally wasteful. So
it's basically given that we will use properties.

I would be against any property that starts with -moz. By doing that we would
just discourage authors who are already coloring their scrollbars for IE to also
color them for Mozilla (most developers don't add one-browser fixes for anything
less than #1 in the market). Instead we should either work out a solution with
W3C, or mimic the behavior in IE. I would try to do both; use the IE behavior
now, and when a new standard is formed with scrollbar properties, switch to that.
Comment 45 Hixie (not reading bugmail) 2002-09-04 18:14:15 PDT
Actually it would be easiest to implement this as two pseudo-elements which were
used to bind the scrollbar XBL to the relevant content area.
Comment 46 Bamm Gabriana 2002-09-09 01:58:32 PDT
Skewer/Hixie: So how do we implement this using either pseudo-elements or
properties? What are the specific steps/changes I have to make? I am not
knowledgeable in this area; I just want to know how to get it done.
Comment 47 darinf 2002-09-09 04:16:10 PDT
There was a discussion on CSS support for colored scrollbars (as well as other
UI elements) here:

<http://www.mozillazine.org/talkback/read.php?f=3&i=1318&t=1278>

I put myself on the CC list to be notified when it goes to WONTFIX.
Comment 48 Skewer 2002-09-09 06:53:23 PDT
"These UI items are in the content area, they pertain to the content that is
being manipulated by CSS to make something more readable, usable, or match a
theme. Scrollbars mostly exist outside of the content area..."

False. Most scrollbars exist within the document.

"The same goes for frames and iFrames."

Why? The author gives no rationale for this statement. I disagree.
Comment 49 Christian :Biesinger (don't email me, ping me on IRC) 2002-09-09 07:07:01 PDT
>False. Most scrollbars exist within the document.

do you have any proof for the "Most" here? most scrollbars I see exist at the
very right edge of my browser window (or at the bottom)
Comment 50 Sören 'Chucker' Kuklau (gone) 2002-09-09 08:01:23 PDT
The only case of scrollbars *within* a document are the scrollbars in several
kinds of form elements. In IFrames / Objects, scrollbars are visually within the
main document, but they do not belong to it.

So - imho - only the former sentence actually counts as a real case. And I still
HOPE that if this happens to get checked in at all, then NOT for Mac OS builds.
Comment 51 Skewer 2002-09-09 14:04:08 PDT
If you only count each element that has a scrollbar, you have HTML, and then you
have INPUT, SELECT, TEXTAREA, and IFRAME and FRAME (Not to mention the fact that
*ANY* non-<HTML> element can have a scrollbar if you use overflow: scroll;). I
think for design purposes those last two ought to be included as "within" the
document, and you would set scrollbar colors on these elements instead of the
document that loads within them since you already set whether or not scrollbars
appear on these elements. Of course an ! important rule on the document in the
frame would override the frame style.

Can authors misuse scrollbar coloring to change the HTML scrollbar colors? Yes,
and they should be able to do it (otherwise we would be forking and only
enforcing CSS properties on *some* elements, both bad ideas). But we can pref
this, and what's more, we shouldn't punish authors who would use scrollbar
coloring responsibly because of the actions of others. It's disappointing that
we can literally style *anything* in a document, including all the various
aspects of form elements, but scrollbars remain the clashing gray color (or
worse, whatever color the skin author chooses). Mac users, if this would upset
you, contribute a patch that adds a pref to turn scrollbar coloring off. Since
we added marquees I figure we're in the club of "If it helps someone, do it, if
you don't like it, add a pref." And besides, I personally think that you can
color the document scrollbars tastefully without necessarily interfering with
usability. There's definitely no need to make a slippery slope out of this and
assume that webmasters will be tinkering with chrome and system colors tomorrow,
that's more false than it is true.

BTW, speaking of skins, since this is on the Skinability component... We should
use the skinned scrollbars if no scrollbar style is set (this applies to form
elements also; in part XBL form controls is necessary for this whole concept to
work), and if there is a scrollbar style set, we should use a native scrollbar
(one that is similar to the current OS's scrollbar).

Soon enough I'll have a testcase/example put together that demonstrates how the
lack of scrollbar coloring hinders style ability.
Comment 52 Boris Zbarsky [:bz] (still a bit busy) 2002-09-09 15:47:09 PDT
Skewer, I hope "native" means "native-looking" here?  Because actually using
native scrollbars in content is a really bad idea....
Comment 53 Hixie (not reading bugmail) 2002-09-09 18:11:06 PDT
The way to implement this would be to add two pseudo-elements:

   ::-moz-horizontal-scrollbar
   ::-moz-vertical-scrollbar

...which match the elements generated for the scrollbars. Then we could bind
them to scrollbar widgets like so:

   ::-moz-horizontal-scrollbar { -moz-binding: url(scrollbar.css#horizontal); }

...and style them like that. This would also mean we could move the C++-level
binding of scrollbar XBL to content, and move that all into the skins.

Hyatt: comments?
Comment 54 Bamm Gabriana 2002-09-09 18:37:59 PDT
Created attachment 98527 [details]
Styled form elements with Toy Factory theme

Skewer: I believe this is what you're talking about. Yes, the scrollbar should
be styleable for consistency with other elements of the form. This way authors
could prevent it from being an eyesore.

I would prefer a -moz prefix though. Vendors who do not want the -moz prefix
can just patch their copy.
Comment 55 Skewer 2002-09-09 20:46:48 PDT
Boris: Yes, of course. It would be impossible to change the color of true native
scrollbars. Something similar to the classic skin for Windows, but appropriately
handled with other OSes. (Oh, and of course, we wouldn't even think about trying
to draw the WinXP scrollbars... we'd draw the classic skin style.)

Everyone else: I've already stated my opinion on using -moz for this, I really
would suggest using something different if we want this functionality to
actually be used. However, if we must go with -moz, we can still use it as an
example for the CSSWG to implement scrollbar styles in a recommendation.
Comment 56 Alex Hosking 2002-09-10 07:24:42 PDT
Im thinking this bug might depend on bug 61188 , in Windows any way
Comment 57 Christopher Aillon (sabbatical, not receiving bugmail) 2002-09-30 21:50:47 PDT
*** Bug 171849 has been marked as a duplicate of this bug. ***
Comment 58 Boris Zbarsky [:bz] (still a bit busy) 2002-10-12 19:34:58 PDT
*** Bug 174173 has been marked as a duplicate of this bug. ***
Comment 59 Max 2002-10-13 09:50:54 PDT
Regarding the 'Styled form elements with Toy Factory theme' attachment, if you
have got coloured scrollbars working in Mozilla, even partially, could you
please attach a patch so that it can be tried out.

Thanks :-)
Comment 60 Alex Hosking 2002-10-13 14:07:42 PDT
The toy factory theme has a yellow scrollbar there is no special coding in the
page that has changed the colour.
Comment 61 Matthias Versen [:Matti] 2002-10-28 14:00:01 PST
*** Bug 177174 has been marked as a duplicate of this bug. ***
Comment 62 Max 2002-12-10 12:31:43 PST
So what's happening here???
Comment 63 Andrew Pakula 2002-12-10 12:42:44 PST
Yea what is going on, nobody has posted anythin about it for a while.
Comment 64 Hixie (not reading bugmail) 2002-12-10 19:16:47 PST
Well, what's going on is that nobody has volunteered to do the work.

So, well, nothing is going on.
Comment 65 Max 2002-12-13 14:03:39 PST
Oh dear :-(
Comment 66 Steve 2003-02-11 21:27:00 PST
I also would love for Moz. to implement the <style> support for scrollbars. That
wold be a great add on. 
Comment 67 Olivier Cahagne 2003-05-09 00:22:28 PDT
*** Bug 204981 has been marked as a duplicate of this bug. ***
Comment 68 José Jeria 2003-05-26 02:29:03 PDT
*** Bug 207113 has been marked as a duplicate of this bug. ***
Comment 69 Alex Hosking 2003-05-26 03:10:54 PDT
I think this would be best kept fixed in Firebird, maybe?
Comment 70 Alex Hosking 2003-05-27 04:01:50 PDT
:(( I got told!!!

Hmm is this an enhancerment?
Comment 71 Bill Mason 2003-07-31 10:59:50 PDT
*** Bug 214651 has been marked as a duplicate of this bug. ***
Comment 72 Bill Mason 2003-08-20 17:07:01 PDT
*** Bug 216820 has been marked as a duplicate of this bug. ***
Comment 73 Manko 2003-08-21 05:01:36 PDT
Scrollbar is a part of OS or browser interface and shouldn't be controlled by
webpage designers. Users might be confised seeing scrollbars with unwonted look.

My vote: wontfix.
Comment 74 Galileo Vidoni 2003-08-21 15:00:13 PDT
are_you_stupid??
it is obvious that there would be a prefrences check to enable/disable it.
nobody is talkin of forcing users to accept coloured scrollbars. personally, I
hate them... but M-A-R-K-E-T-I-N-G- is the point. and even this stupidities can
cause an M$-assimilated user to return to "lovely M$IE"...
Comment 75 M. LaPlante 2003-08-21 17:42:57 PDT
I fully agree with Galileo...the bottom line is IE supports it.  So its not 
part of the standard...so its not something *everybody* likes.  The fact is, 
its out there, and its rather popular, and if you shun trends in design, 
you'll simply push away users.  The best way to get a big market share is to 
give people options.  IE wins when Moz/Netscape are too stubborn to give users 
these options.
Comment 76 Brendan Eich [:brendan] 2003-08-21 19:02:27 PDT
Be nice, and stop waving your advocacy willies in bugs, please.  The best course
is to find someone to implement the desired extension.

/be
Comment 77 Max 2003-08-22 09:20:47 PDT
Hopefully because Mozilla is now targetted at the end-user rather than the 
developer, this will be implemented some time soon? Even Konqueror supports 
coloured scrollbars so I don't see why Mozilla can't even have a setting 
somewhere for it.

Have a nice day :-)
Comment 78 Dwight Brown 2003-12-15 08:49:07 PST
Personally I see this area as an opportunity for Mozilla to, yet again, surpass
IE in developer and end-user features.

Let's face it, better browsers and more features largely benefit web developers
first and foremost.  I am able to create a similar web site on browsers from NS4
to IE6, but NS4 is a developer nightmare.  Mozilla has no exceeded IE in
supporting developers and is why I now use it as my primary browser and
development platform.

The issue of scrollbar 'skinning' is important to a web designer because it
detracts from the ability we have from creating designs that are consistent
throughout.  As has been said previously it is not so important that the primary
browser scrollbars be skinned but rather on those the exist within a page,
whether that be a textarea or a div with overflow:auto;

The arguement that it ruins a consistent user interface is irrelevent since we
all know styles can be changed completely on nearly all form elements (minus
some annoynaces with select elements).  As well as the fact that Mozilla can be
skinned (including scrollbars) and the default 'Modern' skin does not match that
of any OS.

I propose a much more detailed approach by treating scrollbars as elements
within CSS as follows:

-moz-scrollbar-track {
   width:
   border:
   background:
}

-moz-scrollbar-face {
   width:
   border:
   background:
}

-moz-scrollbar-arrow {
   width:
   height:
   border:
   background:
}

Those are what I would consider the primary attributes of the elements and allow
for not only changing the colors of the elements but also the ability to use
images as a background as well.
Comment 79 Dwight Brown 2003-12-15 09:02:25 PST
After my initial proposal I gave the concept more thought and think inherency
would be needed and that this may be a more proper solution:

-moz-scrollbar {
	-moz-scrollbar-width:
	-moz-scrollbar-border:
	-moz-scrollbar-background:
	-moz-scrollbar-face-border:
	-moz-scrollbar-face-background:
	-moz-scrollbar-track-border:
	-moz-scrollbar-track-background:
	-moz-scrollbar-arrow-border:
	-moz-scrollbar-arrow-color:
	-moz-scrollbar-arrow-background:
}

The -moz-scrollbar attributes would be inherited by the other optional specific
attributes. -moz-scrollbar-arrow-color: would define the arrow color and if set
to "transparent" would allow for developers to use the background attribute to
create their own.


For example:

-moz-scrollbar {
	-moz-scrollbar-width: 0.15in;
	-moz-scrollbar-border: 1px solid black;
	-moz-scrollbar-background-color: white
	-moz-scrollbar-track-background-color: silver;
	-moz-scrollbar-arrow-background-color: silver;
	-moz-scrollbar-arrow-color: blue;
}
Comment 80 Max 2003-12-15 11:05:36 PST
To be honest, I don't think this is going to be fixed.  Or shouldn't the product at least 
be changed to FireBird? FireBird is eventually going to be replacing Mozilla, and 
they've already implemented autoscroll in it, so maybe they'll do this as well. But at the 
moment, the only open source browser that has this feature is Konqueror. 
Comment 81 David Baron :dbaron: ⌚️UTC-10 2003-12-15 11:14:24 PST
This is independent of what app is being used.
Comment 82 Galileo Vidoni 2003-12-20 11:41:58 PST
And nearly all of the code which goes into Seamonkey goes to Firebird. I think
the biggest problem is an aesthetic one... How will themes rect with coloured
scrollbars? Qute takes system colors, so does Classic, but for example,
Modern/2... Will the gray scrollbar became green?
Comment 83 Bill Mason 2004-02-15 23:53:57 PST
*** Bug 234486 has been marked as a duplicate of this bug. ***
Comment 84 Bill Mason 2004-03-05 08:16:34 PST
*** Bug 236568 has been marked as a duplicate of this bug. ***
Comment 85 Anne (:annevk) 2004-03-05 08:48:09 PST
*** Bug 236568 has been marked as a duplicate of this bug. ***
Comment 86 Anne (:annevk) 2004-03-05 08:49:35 PST
*** Bug 178651 has been marked as a duplicate of this bug. ***
Comment 87 velvetwitch 2004-05-26 11:25:09 PDT
The Fact, that I cannot color the scrollbars is the most unliked thing in
Mozilla. To deal with this problem, I often use layers without a scrollbar, but
a complex JavaScript to make them scrollable. I don't use IFrames, because of
those nasty grey scrollbars that would kill my layout. And I cannot see, why
colored scrollbars would confuse a user.
But I think, this shouldnt be done with an extra Tag for Mozilla, cause most
developers wouldn't use this (they even dont care about the functionality of
their scripts, that work with wrong code of cause only in IE).
We can set scrollbars on or off (an 'attack' to the native UI?). 
We can make layers scroll automatically ('attack'), we can change pictures on
mouse events ('an attack to the system itself!'); we can sniff a users client,
weather it has a specific plugin and so on. Much more effects to the system than
a colored scrollbar could ever be.

Maybe those, who complain about this, must in consequense disable JavaScript in
their browsers to get rid off all those bad things "so-called-webdesigners" put
into their pages to make it more nice. And of cause they must disable their
browsers to show author-set background colors and force their browsers to show
always the default client colors for links, the default font and so on.
You say thats nonsense? Its not. It would be consequent.

A scrollbar belongs of cause to the content it is caused by (scrolling="auto" /
textareas/ IFrames), so I want to be able to color it to fit with the rest of
the content. And it doesnt make a difference to me, if it is a main scrollbar or
a scrollbar of a form element, it annoys my chosen colors. Content is a nice
thing, but a content presented in a nice way would be even nicer. ;)

velvet
Comment 88 Bill Mason 2004-05-29 12:51:19 PDT
*** Bug 245052 has been marked as a duplicate of this bug. ***
Comment 89 Christ Schlacta 2004-07-07 14:03:36 PDT
I am new to this forum.  this is my first post, But I must say, This feature is
he penultimate decision.  Ither give people native colored scroll bars, or
people will be forced to use Javascript, VB Script (shudders), or PHP to block
non-IE browsers.  Wait..  ASP.
Do you want that ?  I know how to do this with PHP and Javascript.  I won't do
this..  I'm too soft.  But I know that it can be done, and so I know someone
will do it.
If I had my webcam on, You'd see me on my knees begging while I type this.. 
GIVE US COLLORED SCROLL BARS PLEASE!!  AND USE THE IE METHOD!!
I'm going to write to the W3C as well..
If you look at the facts, If we were to open an online petition on the main
page..  Say "give us your name and E-mail and we'll count your signature" you
post that on the main page, and if you get 5000 signatures, Implement it..  You
would have those 5000 signatures.  as for the people who hate it, make it an
option, off by default.
as for who would do the work..  I am willing.
I will muck thru the code, line by line and MAKE THEM WORK!!
Problem is, at my present skill level, it would take about 3 years to get an
Uber buggy alpha of it..  So I propose that someone else do it.
Comment 90 Sergey «Mithgol the Webmaster» Sokoloff 2004-07-10 07:59:21 PDT
I strongly oppose the above proposed (comment #15) idea of tricolour scrollbars.
Not only because Mozilla would not be able to import the whole pack of seven
property values of MSIE's proprietary CSS properties (scrollbar-arrow-color,
scrollbar-face-color, scrollbar-highlight-color, scrollbar-3dlight-color,
scrollbar-shadow-color, scrollbar-darkshadow-color, scrollbar-track-color). But
also because (I emphasize that!) some visual effects are virtually impossible to
implement -- and the easiest to understand, among them, are FLAT SCROLLBARS,
which do not cast any shadow or 3D light on themselves.

Example? All right, here it goes... the BODY element of
http://mithgol.pp.ru/Mozilla/ is styled with the following MSIE's CSS rules:

	scrollbar-face-color: #e1e1e1;
	scrollbar-highlight-color: #e1e1e1;
	scrollbar-shadow-color: #595959;
	scrollbar-3dlight-color: #595959;
	scrollbar-darkshadow-color: #e1e1e1;
	scrollbar-arrow-color: #595959;
	scrollbar-track-color: #f0f0f0;

Launch your copy of MSIE 6 SP1, and visit my page of splashes. You'll see that
the vertical scrollbar is much more flattened (than usual) into the plane of
webpage, it has no cubic content now, it has neither 3D light nor self-cast
shadows, it becomes a real part of the page, and if the browser window is
maximized, then we have UI only above and below the page, and all the central
part of CRT (or LCD) now belongs to the site. That was my intention. It really
makes it easier (for a reader of the site, for a user of the browser) to
abstract the site content (webmaster's realm) away from the control elements
(the UI): there are only two border lines left, both horizontal.

(How are you gentlemen!! All your scrollbar are belong to us.
http://www.catb.org/~esr/jargon/html/A/all-your-base-are-belong-to-us.html ;-)

If some more complex styling scheme (comment #78, comment #79) is going to be
implemented, then we need either an extension or an internal piece of code to
import the above described MSIE-alike pseudo-CSS code into the new scheme,
though with lowest priority (as, for example, non-CSS presentational hints are
still imported as if they were CSS rules, but with zero specificity).

And also do not forget ot make these scrollbar styles (both MSIE-alike and
Mozilla's) changeable via JavaScipt. Example: try to mouse-hover any hypelink on
http://mithgol.pp.ru/Mozilla/ -- and if my piece of HTC+JS goes right (however,
it does not on some Win32 platforms or MSIE versions), then the scrollbar turns
into a kind of red blaze. Well... I know that any HTC, made for MSIE, does not
work on Mozilla Gecko platform directly; however, there is an XBL wrapper
(http://dean.edwards.name/moz-behaviors/) in our avail.

And. of course, those who want OS or browser UI instead of website UI -- those
should be provided with a pref (in about:config, or in extension) to decolorize
their scrollbars back.

This bug should not be fixed in a MSIE-incompatible way, though it may extend
MSIE's abilities: do not plan to loose the existing web design solutions. And
this feature should be switched on by default, because it must be user's choice
whether to deny.

I wish I could check out the code from CVS repository and start hacking a fixing
patch for this bug by my own, but I just don't have enough time to hack, and I'm
also not sure about my ability of "being on the hook" from the eastern
hemisphere of the planet; I have to sleep at least sometimes, after all.

So I'll just take one of my precious 10 votes off some other bug, and place it
on this one. There's nothing more I can do. A example of usefulness, and a
simple vote.
Comment 91 Justin Wood (:Callek) 2004-07-10 10:36:32 PDT
--> c#90

Firstly we cannot do this with IE's tags and still claim any sort of support to
W3C specs, we need the -moz- prefix!

Secondly, imo we need to keep the *main* scrollbar, such as the one on your page
for accessability reasons, _that_ scrollbar needs to mesh with the UI of the
page/site.  Where-as any detatched scrollbars, such as those on textarea's,
overflow-scroll etc. need to be styleable by the CSS of the website they are in,
to better merge with that websites content, 

as *in-site* the website author is responsible for accessability, in-browser
"we" (Mozilla Foundation, of which I technically am not part of) are responsible.

If a user, with poor sight/visibility needs the UA scrollbar a certain way to
help themselves, who are we to allow a website the chance at "Hey I want it
these colors".  Where the visit to said website may have been by mistake, or
part of a research, and because of poor accessability design, said user wont
stay long, but they need a way to scroll the page at all times, should the pages
content overflow.

Now I would ask that before anyone else make comments "Hey this would be great"
and "Hey we need this, ...because..." that they read all reports on it.  and
unless they have something to add to the actual development of this, take it to
newsgroups/forums...all that continued spam here will do is make it harder for
the devs to work.
Comment 92 Max 2004-07-11 06:19:24 PDT
Let's just have this as a FireFox extension. Then everyone is happy, no?
Comment 93 Sergey «Mithgol the Webmaster» Sokoloff 2004-07-11 09:27:30 PDT
(in reply to comment 91)

Firstly, be so kind to provide me with a hyperlink to a specification (that you
meant) that forbids a browser from supporting a proprietary set of CSS
properties, if it does not start with "-vendorID-". I am going to evaluate the
degree of its strictness, whether it is a recommendation, an advice, a
definition, a habit, a rule, or some usual practice.

Secondly, let me politely decline your advice of cancelling the discusion,
because I am not completely sure that people in "CC:" list are aware of all
available opinions, and read all reports that really matter. Especially I mean
the question of accessibility. Several questions around this bug (questions that
are particularly related to accessibility) were dicussed on irc.mozilla.org (in
#firefox) yesterday, and now I've got a bunch of really good arguments, which I
feel should be attached to this bug as a comment.

Let me start with a simple question: what the above discusssed bugfix proposal
is about? Is it to introduce the only way that is able to provide a
webmaster-defined scrollbars for document? No, it is not. On the current level
of Web application technologies, there are other means already. An enough
skilled webmaster can easily draw a scrollbar, make a three separate image files
out of it (two foreground arrows and a background track), place them on the
rightmost edge of the document, make the two arrows mouse-clickable, attach a
JavaScript function to handle mouse clicks, and change the absolute position of
some DIV element on the page (that DIV element, in this case, should contain all
other page content and site navigation, except for the scrollbar). An enough
skilled webmaster can also hide browser UI scrollbar, either by putting the
whole page into a scrollbarless frame in site frame structure or by keeping his
content divided into several DIVs, their position and visibility carefully
mantained not to exceed vertical size of the viewport.

I've seen a couple of screenshots (three or four years ago) that convinced me to
think that pseudo-scrollbars are already used in several Web RPG interfaces.
Though these were only screenshots (and I missed an opportunity to look into the
code) -- I believe the solution is real.

And, if the webmaster is not so inclined to use only the most supported Web
standards (frames, absoule positioning, JavaScript, and images), he can also
render all the content into a single Macromedia Flash object, and include
(within the file) any scrollbars he wishes.

Then, if there are already working solutions that provide a webmaster-defined
scrollbars, why bother fixing this bug? Would that fixing allow us to gain any
new web functionality? Yes. Any real fix for this bug is going to simplify the
things greatly, and the benefits of such a simplification is obvious.

Let me enunciate them.

Primary benefit is that overall size of code is reduced: it will now take only a
few CSS property values to do a work of former numerous JavaScript operators and
several external files (or even a Flash object). Webmasters will benefit,
because the need for a complex and potentially bogus (and always time-consuming)
solution will vanish -- but users will benefit also, due to greatly reduced
download time.

And also an increase of accessibility will be noticable. The patch for this bug
will allow the pure CSS solution. It means that informational and presentational
layers will become enough separate, and any web search engine robot, or a
completely blind human, or someone else who can see but anyway prefers an audio
reader device, won't have a need neither to filter out JavaScript handlers, nor
to depend on non-guaranteed emptiness of ALT text for arrow images, nor to
navigate into the scrollbarless frame, nor to reconstruct a proper order of text
flow for absolute positioned text, nor even to decompile a Flash. They all is
going to get the same HTML; it's CSS that makes an effect.

In the middle of the whole spectrum between blind an seeing, we have lots of
poor sight, visibility impaired, colour-blind, and otherwise challenged users,
who still are going to read themselves and don't bother using an automatic
text-to-audio converters. For them, we'll also have accessibility greatly improved.

Why?..

The answer is coming.

Some people already have problems with using any of scrollbars, because it's
difficult for them to position a mouse or any other tracking device, or to hold
a button, or to drag UI elements. That's why they use keyboard navigation
instead, or some hardware emulating keyboard arrowclicks. But we know that the
above mentioned JavaScript or Flash solution (the only solution supported by
Mozilla with this bug unfixed) requires some additional event handling to
support keyboard scrolling, while the CSS solution does not require it, so let's
make this bug fixed and the CSS solution will immediately become cross-platform
(i.e. not MSIE-only), and will eventually become more popular than
JavaScript+images solution (which is already cross-platform, but its nature is
no more than a perverted workaround for this very bug 77790). So keyboard
scrolling fans will benefit.

But what about daltonism? Let's come up to it also...

Some people face great problems when colors are redefined. (These are cases of
colour blindness, dim vision, some forms of epilepsy, and so on.) But their mere
existence never prevented web developers from implementing BODY
BGCOLOR/TEXT/LINK/VLINK/ALINK, of FONT COLOR, or numerous other COLORs and
BGCOLORs (and BACKGROUNDs), into HTML 3.x. Neither it prevented from adding
color and background properties into CSS specifications. Why? Are web developers
cruel to minorities? No, they aren't. Because there are usual lots of options
specially dedicated to those who value full control over webpage colours.
Options to ignore HTML attribute values. Options to use custom, user's CSS
sheets, overriding document's.

So does fixing this bug impose any burden, any additional unsurmountable
problems in getting full control over colours? No, it would require an
additional checkbox checked, and (or) not more than seven "!important" property
values in custom CSS. Be aware that JavaScript or Flash scrollbars are not so
easy to disable without harming other partss of document, and having this bug
unfixed makes JavaScript or Flash the only supported solution.

But is there any intrinsic benefit, not requiring a comparison between this
bugfix and JavaScript or Flash workarounds?

Yes, there is; because, in fact, fixing this bug does also introduce a real
solution for already existent problem of some colour-impaired people -- I mean
those men and women who already look around for a way to change scrollbar
colours. Surely you know that these colours already differ from OS settings,
because of themes. Right now, without having this bug fixed, those impaired
users have to change the whole browser theme (or even an application suite
theme!), or (even more difficult way!) to learn an enough amount of XUL to code
their own theme. Having this bug fixed, they will be able to change only their
scrollbars, leaving other theme skin intact, and through a much simpler way
(just seven "!important" CSS property values in user CSS sheet, that's all).

(By the way, we see now that this bugfix is going to give webmasters some
freedom that theme authors already have, am I right?)

For each of the above examined cases, the accessibility effect of fixing this
bug is positive, because the pure CSS solution of recoloured scrollbars impose
much lesser problems than other already existent JavaScript or Flash solutions,
which I consider to be spontaneously invented (and thus perverted) workarounds
for this bug. Of course (as it once was with "color" and "background" CSS
properties and HTML attributes), the overall accssibility effect of implementing
"scrollbar-XXXXX-color" is positive only if such an implementation has an option
to be either completely turned off by user or altered via user's custom CSS
sheet. However (as it already is with "color" and "background" CSS properties
and HTML attributes), the fix for this bug should be enabled by default, waiting
for user possibly disabling it at will... enabled by default, unless it is a
Mozilla bulid specially compiled for some minority of visually impared users.

Or, to rephrase in shorter form, this bug (when it comes to accessibility)
hasn't to be dealt specially, with difference to already existent "color" and
"background" CSS properties and certain HTML attributes. From my point of view,
it is just another fair and acceptable demand for freedom... the freedom of
choice between three options. These options are:

1. Scrollbar looks are defined by browser theme author.

2. Scrollbar looks are defined by website author.

3. Scrollbar looks are defined by the user of the browser, the reader of the
website.

And, having considered user CSS with only a few property values redefined (less
than seven), there's also quite a spectrum between options 2 and 3.

And a few final words: remember that "color" properties/attributes were also not
an accessibility heaven, but they've obviously made the Web much more accessible
if you think of the other available alternatives (coloured text rendered as
GIFs, just for example). The "scrollbar-XXXXX-color" property is also not ideal
by itself, but it is a way less perverted than available JavaScript or Flash,
and so it is the most acceptable scrollbar colorizer (unless you can think of an
even better solution). The worse ones are already supported; let's start
supporting this one, the most beneficial for Web accessibility!
Comment 94 Sergey «Mithgol the Webmaster» Sokoloff 2004-07-11 09:44:01 PDT
(in reply to comment 92)

Unfortunately, there's a thing that makes me doubtful about whether an extension
is possible that simple... I remember comment #53 from Ian 'Hixie' Hickson: the
C++-level binding of scrollbar XBL to content is involved, so could it be
changed by an extension? (If that extension does not include 4-5 Mb of
recompiled Gecko, that is.)
Comment 95 Christian :Biesinger (don't email me, ping me on IRC) 2004-07-11 10:08:09 PDT
(In reply to comment #93)
> Firstly, be so kind to provide me with a hyperlink to a specification (that you
> meant) that forbids a browser from supporting a proprietary set of CSS
> properties,

http://www.w3.org/TR/CSS21/syndata.html#parsing-errors

> if it does not start with "-vendorID-".

http://www.w3.org/TR/CSS21/syndata.html#q4
Comment 96 Max 2004-07-11 10:34:29 PDT
Themes are able to change the colour of the scrollbars. Therefore, this
extension perhaps could somehow act as at least a partial theme overlayed on top
of the theme currently being used.
Comment 97 Sergey «Mithgol the Webmaster» Sokoloff 2004-07-11 11:24:39 PDT
(in reply to comment 95)

It is said (on http://www.w3.org/TR/CSS21/syndata.html#parsing-errors) that user
agents must ignore a declaration with an unknown property; but, once this bug
fixed, "scrollbar-XXXXX-color" properties for BODY element will become known to
Mozilla as well as, for example, -moz-margin-start already is known for DD element.

And it is said (on http://www.w3.org/TR/CSS21/syndata.html#q4) that an initial
dash or underscore is guaranteed never to be used in a property or keyword by
any current or future level of CSS. But each one of the seven
"scrollbar-XXXXX-color" identifiers is really long, so it's unlikely to be
_accidentally_ used in a property or keyword by any current or future level of
CSS, almost as unlikely as -moz-XXXXX; though a "scrollbar-XXXXX-color" could be
used there _deliberately_, to codify recoloured scrollbars. So "-moz-XXXXX" is
just a convenient way to get a 100% guarantee from W3C, no more, no less.
Comment 98 Christian :Biesinger (don't email me, ping me on IRC) 2004-07-11 11:39:00 PDT
(In reply to comment #97)
> though a "scrollbar-XXXXX-color" could be
> used there _deliberately_, to codify recoloured scrollbars. 

nothing guarantees you that the semantics, or even the syntax, of such a
property are the ones that MSIE uses now.
Comment 99 Sergey «Mithgol the Webmaster» Sokoloff 2004-07-11 12:08:15 PDT
(in reply to comment 98)

I am aware of this possible problem in future.

I agree that if the semantics, or the syntax, of such a property in W3C standard
differs from the ones that MSIE uses now, then we'd use a W3C one. (It's like
"cursor: hand" and "cursor: pointer" in bug 40298.)

But now there's no W3C standard for that, so (for the sake of compatibility)
it's better to avoid creating a property name not known to MSIE or Konqueror. We
are not going to ignore a real current usual practice just because its change is
theoretically possible (though not very probable) in future, are we?

Implementing MSIE "scrollbar-XXXXX-color" semantics does not violate any current
CSS2.x specification, because implementing MSIE "scrollbar-XXXXX-color"
semantics will not violate any CSS specification until W3C implements
"scrollbar-XXXXX-color". (And if it implements, that would be a Good Thing, so I
won't call it a high price if a need of changing Mozilla's behaviour once more
arises.) Fixing this bug does not harm W3C now, and it's unlikely to harm W3C
even in future, because if they wished, they could have already codified
"scrollbar-XXXXX-color" in W3C standard.
Comment 101 Craig Kovatch 2004-07-11 21:35:27 PDT
I think the whole discussion about accessible scrollbars is rather moot. Most
sites that use colored scrollbars are not catering to accessibility users
anyway. The responsibility to provide accessible websites is that of the web
designer, not the web browser. The browser's job is simply to support those
users. Lame analogy: it is not a car's responsibility to get someone from point
A to point B safely, that's up to the driver, the car should simply perform the
way the driver tells it to.

I agree with comment #75. There is obviously demand out there for colored
scrollbars - they are everywhere on the web. By being stubborn, Mozilla is
simply making it more difficult for users to switch. If Mozilla is serious about
becoming a truly usable and switch-toable browser, it ought to adopt the 7-pack
of IE scrollbar values and have a checkbox (default off perhaps) allowing them.
Comment 102 Bamm Gabriana 2004-07-15 00:29:12 PDT
Regarding accessibility, Moz already gives users the ability to use their own 
styles or turn off CSS altogether. Surely this will not affect users who 
already use their own stylesheet? (A user with special needs probably already 
does.)

The question here is: do we choose to literally obey the spec, or do we choose 
to be compatible with existing web pages?

Further, it is not just about being compatible with MSIE. It is also about 
being compatible with Opera, Konqueror, and Safari.

My two cents worth.
Comment 103 Sergey «Mithgol the Webmaster» Sokoloff 2004-08-01 02:38:56 PDT
(replying to comment 102)

Ah yes! According to http://www.howtocreate.co.uk/tutorials/scrlbar.html
article, the coloured scrollbars are also supported by Opera (though coloured
only by HTML <style> element, not by an external stylesheet).

That article also describes the currently existing behaviour of coloured
scrollbars on different platforms. Very, very useful. Please read that before
fixing this bug.

However, I'm not currently aware of how these scrollbars are supported in
Safari. Are there any specs? Or did they just leave original KHTML behaviour intact?
Comment 104 Peter van der Woude [:Peter6] 2004-08-21 14:11:59 PDT
*** Bug 256444 has been marked as a duplicate of this bug. ***
Comment 105 Simone Chiaretta 2004-10-08 02:12:07 PDT
I read almost all messages in this long bug report, but I don't understand if
the -moz-scrollbar-* is really being taken into account, if it is already being
developed (but since it's still NEW I think it's not),or it will never be
implemented.
My opinion is that since all other browser support this graphic enanchement,
even if it's not W3C standard, FireFox and Mozilla should have this, too...
Comment 106 Simone Chiaretta 2004-10-08 05:13:15 PDT
a little add-on to my previous post:
Many thinks that changing the chrome of the browser from inside web page is not
a nice thing.
Also I think that people use colored scrollbars for iframes or div with
overflow, textarea, but don't think they really need the color for the main
scrollbars.

So, sytle scrollbars could be implemented for everything except the main scroll
bars.

Comment 107 Max 2004-10-08 09:31:09 PDT
should the product be changed to firefox?
Comment 108 Nathan 2004-11-09 21:09:25 PST
I am a brand spanking new user to Firefox and this was the very first thing I
noticed.  PLEASE PLEASE PLEASE allow for scrollbar styles. I am finding myself
becoming quickly annoyed when visiting my daily web design portals, 95% of whom
have recommended that their visitors dump IE for Firefox, only to see that
Firefox doesn't support a feature that is so widespread among these sites.  

I also see by this post that this feature has been requested for over 2 years
now in Mozilla browsers.  May I ask why the refusal to comply to what seems like
a failry simple request?
Comment 109 Sergey «Mithgol the Webmaster» Sokoloff 2004-11-10 01:39:12 PST
There's no refusal, Nathan. It's just because no-one volunteered. If, for you,
it seems like a failry simple request, go on, volunteer your services -- make a
source code patch fulfilling the request, and attach it here.
Comment 110 Phil Ringnalda (:philor) 2004-11-21 19:52:28 PST
*** Bug 271158 has been marked as a duplicate of this bug. ***
Comment 111 Jason 2004-11-24 19:13:09 PST
Totally agree with comment 101... this is critical to Firefox user acceptance.

I had 2 clients ask me last week to make their sites Firefox compatiable. Both
use coloured scrollbars extensively for "theme". When told that this feature
wasn't available they quickly lost interest and re-focussed back on MSIE support.

If I could program in C++ I would consider doing this myself. However, my job
here is to help make open source and Firefox a success through feedback.
Comment 112 Simone Chiaretta 2004-11-25 01:12:27 PST
I'm in the same postion as comment 111, I know scrollbars color are not standard
but many sites implement it and now it has become a standard feature for site
design.
I'm a developer, know a bit of C, but never hacked through Firefox code, so
could not know where to look for implementation.
Comment 113 Thomas Forster 2004-12-09 11:42:17 PST
Just a word for the "not-the-main-window" party:

I would simply use a scrollable DIV filling the entire window, so I can
collorize them. As  Sergey "Mithgol the Webmaster" Sokoloff wrote in comment
#93, there are way to customize scrollbars, it just shouldn't be a dirty hack.

Along with the &shy;-problem, this is the bug i'm dying for to be fixed. In the
meanwhile, i will hack dirty ...
Comment 114 Max 2004-12-11 07:28:02 PST
This is getting silly, when is this going to be fixed? Can someone at least 
create an extension in the mean time which fixes this? - and then, hopefully 
like the stylesheet-switcher extension, it will be integrated.
Comment 115 Sergey «Mithgol the Webmaster» Sokoloff 2004-12-11 13:23:13 PST
Well, I'm not a hardcore Mozilla hacker, but: in comment #53 Hixie told us that
(as far as I can understand) the fix cannot avoid involving C++.

Therefore any extension is not useful, because scrollbars are rendered somewhat
deeper than XUL+CSS level used by extensions. One should hack into underlying
Gecko code to change this. Someone enough skilled to avoid making the engine
partially bogus.

I could possibly install CVS and try thinking of a starting patch myself during
New Year celebration and the following Christmas holidays, but I'll be busy
expanding my own Mithgol.Ru website, porting http://Mithgol.Ru/Mozilla/
extensions to Firefox, and so on. Later, maybe.
Comment 116 Sergey «Mithgol the Webmaster» Sokoloff 2004-12-11 13:51:31 PST
However, the required Gecko support may be already existent.



In classic.jar/skin/classic/global/scrollbars.css, we see the following code:

/* ::::: scrollbar ::::: */

scrollbar {
  -moz-appearance: scrollbartrack-horizontal;
  -moz-binding: url("chrome://global/content/bindings/scrollbar.xml#scrollbar");
  cursor: default;
  background: url("chrome://global/skin/scrollbar/slider.gif") scrollbar;
}

scrollbar[orient="vertical"] 
{
   -moz-appearance: scrollbartrack-vertical;
}



In toolkit.jar/content/global/bindings/nativescrollbar.xml, we see the following
code:

<?xml version="1.0"?>

<bindings id="scrollbarBindings"
   xmlns="http://www.mozilla.org/xbl"
   xmlns:xul="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
   xmlns:xbl="http://www.mozilla.org/xbl">
  
  <binding id="scrollbar">
    <content>
      <xul:nativescrollbar flex="1"
xbl:inherits="curpos,maxpos,pageincrement,increment,orient,sborient=orient"/>
    </content>
  </binding>
    
</bindings>



In toolkit.jar/content/global/bindings/scrollbar.xml, we see the following code:

<?xml version="1.0"?>

<bindings id="scrollbarBindings"
   xmlns="http://www.mozilla.org/xbl"
   xmlns:xul="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
   xmlns:xbl="http://www.mozilla.org/xbl">
  
  <binding id="thumb" extends="xul:button">
    <content>
      <xul:gripper/>
    </content>
  </binding>
  
  <binding id="scrollbar-base">
    <handlers>
      <handler event="contextmenu" preventdefault="true"/>
      <handler event="click" action="event.preventBubble();"/>
      <handler event="dblclick" action="event.preventBubble();"/>
      <handler event="command" action="event.preventBubble();"/>
      <handler event="contextmenu" action="event.preventBubble();"/>
    </handlers>
  </binding>
  
  <binding id="scrollbar"
extends="chrome://global/content/bindings/scrollbar.xml#scrollbar-base">
    <content>
      <xul:scrollbarbutton sbattr="scrollbar-up-top" type="decrement"
xbl:inherits="sborient=orient"/>
      <xul:scrollbarbutton sbattr="scrollbar-down-top" type="increment"
hidden="true" xbl:inherits="sborient=orient"/>
      <xul:slider flex="1"
xbl:inherits="curpos,maxpos,pageincrement,increment,orient,sborient=orient">
        <xul:thumb sbattr="scrollbar-thumb" xbl:inherits="orient,sborient=orient" 
                   align="center" pack="center" flex="1"/>
      </xul:slider>
      <xul:scrollbarbutton sbattr="scrollbar-up-bottom" type="decrement"
hidden="true" xbl:inherits="sborient=orient"/>
      <xul:scrollbarbutton sbattr="scrollbar-down-bottom" type="increment"
xbl:inherits="sborient=orient"/>
    </content>
    
    <implementation>
      <constructor>
        if (navigator.platform.indexOf("Mac") != -1)
          this.initScrollbar();
      </constructor>

      <method name="initScrollbar">
        <body>
          <![CDATA[
            try {
              var scrollbarStyle =
this.boxObject.getLookAndFeelMetric("scrollbarStyle");
              var thumbStyle = this.boxObject.getLookAndFeelMetric("thumbStyle");
              var downTop;
              var upBottom;
              if ( scrollbarStyle == "double" ) {
                downTop = document.getAnonymousElementByAttribute(this,
"sbattr", "scrollbar-down-top");
                upBottom = document.getAnonymousElementByAttribute(this,
"sbattr", "scrollbar-up-bottom");
                downTop.removeAttribute("hidden");
                upBottom.removeAttribute("hidden");
              }
              else if ( scrollbarStyle == "doubletop" ) {
                downTop = document.getAnonymousElementByAttribute(this,
"sbattr", "scrollbar-down-top");
                var downBottom = document.getAnonymousElementByAttribute(this,
"sbattr", "scrollbar-down-bottom");
                downTop.removeAttribute("hidden");
                downBottom.setAttribute("hidden","true");
              }
              else if ( scrollbarStyle == "doublebottom" ) {
                var upTop = document.getAnonymousElementByAttribute(this,
"sbattr", "scrollbar-up-top");
                upBottom = document.getAnonymousElementByAttribute(this,
"sbattr", "scrollbar-up-bottom");
                upTop.setAttribute("hidden","true");
                upBottom.removeAttribute("hidden");
              }
              if ( thumbStyle == "fixed" ) {
                var thumb = document.getAnonymousElementByAttribute(this,
"sbattr","scrollbar-thumb");
                if ( thumb )
                  thumb.removeAttribute("flex");
              }
            }
            catch ( x ) {
              //throw "Scrollbars in this skin are not properly supporting mac
smart-scrolling prefs!";
            }
          ]]>
        </body>
      </method>
    </implementation>
  </binding>
</bindings>



That probably means (though I'm not certain) that required elements are added,
and the elements are generated for the scrollbars and bind to scrollbar widgets
and they may be styled.

This may as well mean that code is a rudiment of Mozilla Suite (where scrollbars
 were styleable at least by themes; in Firefox they're not). However, if the
rudiment's support is not lost in Firefox Gecko, it may be toggled back on by an
extension. Seems promising.

I'll gain some more experience in XUL while porting my extensions to Firefox.
Then I'll return to investigate and explore this code more thoroughly.
Mid-summer of 2005, if time permits.
Comment 117 Sergey «Mithgol the Webmaster» Sokoloff 2004-12-12 00:25:45 PST
This morning I spent some time at #firefox on irc.mozilla.org. Got some useful
bits of information, I'll drop some here.



1) Firefox scrollbars are skinnable, and some themes (Whitehart -- see
http://www.ac.wwu.edu/~conberj/Whitehart.html -- is an example) can change
scrollbar's look'n'feel.



2) Default theme and many other themes (Pinball, for example) use a code like this:

scrollbar {
  -moz-appearance: scrollbartrack-horizontal;
  -moz-binding: url("chrome://global/content/bindings/scrollbar.xml#scrollbar");
  cursor: default;
  background: url("chrome://global/skin/scrollbar/slider.gif") scrollbar;
}

scrollbar[orient="vertical"] 
{
   -moz-appearance: scrollbartrack-vertical;
}

and so the appearance becomes system native. (That's what -moz-appearance is
for; see http://www.xulplanet.com/references/elemref/ref_StyleProperties.html
for details.)



3) Whitehart theme happily drops -moz-appearance property from CSS, the code
looks like that:

scrollbar {
  -moz-binding: url("chrome://global/content/bindings/scrollbar.xml#scrollbar");
  cursor: default;
  background: url("chrome://global/skin/scrollbar/slider.gif") #DDD;
}

scrollbar[orient="vertical"] {
}



4) http://lxr.mozilla.org/mozilla/source/layout/style/nsCSSProps.cpp#164 has
lots of actually possible -moz-appearance values, as defined in C++.



I am still not certain whether -moz-appearance of scrollbars can be changed on
per-window basis. This needs further investigation.
Comment 118 scratch 2004-12-12 00:31:28 PST
they can.  in fact, websites used to be able to theme scrollbars.  this was
considered to be a security bug (websites could make scrollbars invisible, for
example), and is actually purposely disabled and more-or-less blacklisted.  what
needs to happen is for a restricted version to be re-implemented, i think.
Comment 119 Sergey «Mithgol the Webmaster» Sokoloff 2004-12-12 00:54:50 PST
This helps! Do you remember the exact security bug number? I'll try thinking
whether its patch can be partially reverted.
Comment 121 Sergey «Mithgol the Webmaster» Sokoloff 2004-12-12 02:43:13 PST
Damnit! There's no patches attached to bug 21890 (and to bug 46505, which seems
somewhat related to scope problem).

David Hyatt fixed bug 21890, so he's one of a few who know what was done.
Without that knowledge, we may only guess by exclusion: for example, there's no
"-moz-xbl" in chrome, so it was at least not that pseudo-element method...

However, https://bugzilla.mozilla.org/show_bug.cgi?id=21890#c59 clearly states
that the scrollbars are not created using XBL.  The content of the scrollbars
themselves is XBL, but the creation of scrollbars is hardcoded in C++, and XBL
doesn't get involved at all.

It is also clear (after reading bug 21890 and its comments) that scrollbars are
actually anonymous content, and I even can't see them via DOM inspector, so I'm
still doubtful whether any further progress can be made here. You may not style
<scrollbar> dynamically if don't have access to it via JavaScript DOM :-((
Comment 122 Sergey «Mithgol the Webmaster» Sokoloff 2004-12-23 10:51:30 PST
Trying to add bug 21890 as a dependency.
Comment 123 Manko 2004-12-26 23:37:36 PST
I agree, we need of styled scrollbars. But I completely disagree that IE does it
with right manner.

I would propose a CSS3-like properties for styling scrollbars. This can afford a
noticeable opportunities to style scrollbars, notably greater than in IE.

::scrollbar-track
Scrollbar background. May contain any CSS3 defititions such as: width (for
vertical), height (for horizontal), padding, backgroud-image, border-radius etc.

::scrollbar-button
Button with arrow. May have additional pseudoclasses: :top, :bottom, :left,
:right. Button content (arrow) may be overwritten via content() property.

::scrollbar-pad
Button at middle of scrollbar.

In addition, these sub-pseudoclasses may be specified:
:vertical
For vertical scrollbar.

:horizontal
For horizontal scrollbar.

:disabled
For disabled scrollbar.

Such sub-pseudoclasses may be combined:
div::scrollbar-track:horizontal:disabled {
  ...
}
Describes style of disabled horizontal scrollbar background for any <div> element.

tbody::scrollbar-button:bottom:disabled {
  content:url(/img/down.png);
}
Describes image of disabled bottom arrow button for any <tbody> element.
Comment 124 Anne (:annevk) 2004-12-27 00:59:36 PST
FYI: a pseudo-element is always that last one in a selector. Thinks like
'::before:hover' are invalid and make the selector end up being ignored.
Comment 125 Hixie (not reading bugmail) 2004-12-27 02:07:45 PST
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.
Comment 126 Kevin Brosnan 2005-02-09 13:37:10 PST
*** Bug 281696 has been marked as a duplicate of this bug. ***
Comment 127 Kevin Brosnan 2005-03-11 13:06:10 PST
*** Bug 285787 has been marked as a duplicate of this bug. ***
Comment 128 Sergey «Mithgol the Webmaster» Sokoloff 2005-05-15 14:32:29 PDT
However, to back my reasons with something material, I'll post here an example
of what I call a perverted workaround for this bug -- an example of
JavaScript+<div> scrollbar, with <img> arrows and track. A work of art, but no
accessibility... and its colours cannot be easily redefined by user styles,
though Greasemonkey (and a lot of image editing) may finally help.

And that artificial scrollbar cannot be scrolled by mouse wheel or keyboard
controls; it requires mouse clicks on itself.

That example I met there:
http://silver.ru/news.phtml

I am inlined to think that one can multiply instances of such a workaround, and
their numbers will constantly increase -- and examples of CSS-like accessible
solution dwindle -- with the spread of Firefox.

Until this bug is fixed.
Comment 129 Christian :Biesinger (don't email me, ping me on IRC) 2005-06-14 15:24:22 PDT
(In reply to comment #99)
> Implementing MSIE "scrollbar-XXXXX-color" semantics does not violate any current
> CSS2.x specification,

Note that (in the latest version) CSS 2.1 now disallows implementing
scrollbar-XXXXX-color:
http://www.w3.org/TR/CSS21/syndata.html#parsing-errors
"CSS2.1 reserves for future versions of CSS all property:value combinations and
@-keywords that do not contain an identifier beginning with dash or underscore.
Implementations must ignore such combinations (other than those introduced by
future versions of CSS)."
Comment 130 Kevin Brosnan 2005-07-02 07:56:07 PDT
*** Bug 299456 has been marked as a duplicate of this bug. ***
Comment 131 Kevin Brosnan 2005-07-02 08:02:45 PDT
*** Bug 299456 has been marked as a duplicate of this bug. ***
Comment 132 Dave Townsend [:mossop] 2005-10-01 14:25:38 PDT
*** Bug 310725 has been marked as a duplicate of this bug. ***
Comment 133 Gilles Durys 2005-10-07 07:34:36 PDT
*** Bug 311502 has been marked as a duplicate of this bug. ***
Comment 134 Peter Kasting 2006-06-07 15:00:26 PDT
After much conversation with Hixie, darin, bryner, and dbaron, I think I at least understand what the proposed solution is, even if I can't yet implement it:

* The current XBL scrollbars are partly implemented in C++ and tied directly to the bits where they need to go
* Instead this bug proposes to add two pseudo elements, such as ::-moz-horizontal-scrollbar and ::-moz-vertical-scrollbar, which would become the bound elements for the XBL scrollbars
* The XBL scrollbars could then do something intelligent with inherited properties from these pseudo-elements
* This also allows users to write new scrollbars in XBL and bind them to these pseudo-elements to completely replace the scrollbars.  Example: instead of a slider with buttons, a miniature image that serves as a panning control.  Or whatever.

The new capability this requires is that AFAIK, XBL can't currently bind to pseudo-elements, because XBL expects to bind to something in the DOM.  I don't know what would be required to change that.
Comment 135 Theresa 2007-09-27 07:38:25 PDT
Not sure if I am in the right spot here but this Color scrollbar issue.

I am a developer and I designed a page that in it's content has a colored scroll bar attached to a table. I don't want to change the window scrollbar color but just the one in my web page...Why can't you make it so that Mozilla will at least display my page scrollbar?

If you do not want people to change the window scrollbar color at least let us developers change our web page scroll bar.

There must be something you can do for that??
Comment 136 Dave Townsend [:mossop] 2007-11-28 10:27:18 PST
*** Bug 405827 has been marked as a duplicate of this bug. ***
Comment 137 Matthias Versen [:Matti] 2008-02-22 09:05:53 PST
*** Bug 419058 has been marked as a duplicate of this bug. ***
Comment 138 Phil Ringnalda (:philor) 2008-04-28 13:20:09 PDT
*** Bug 431187 has been marked as a duplicate of this bug. ***
Comment 139 Dave Townsend [:mossop] 2008-11-13 07:14:41 PST
*** Bug 464683 has been marked as a duplicate of this bug. ***
Comment 140 d 2009-06-27 02:22:12 PDT
As this is something Webkit supports too now, I think we should look into it again.
Comment 141 Josh Tumath 2009-06-27 11:08:25 PDT
(In reply to comment #140)
> As this is something Webkit supports too now, I think we should look into it
> again.

Just because WebKit supports it, doesn't give us the right to do so as well. It is not part of a W3C specification.
Comment 142 d 2009-06-27 12:07:52 PDT
But as long as we use the -moz, we don't violate the specs?
Comment 143 d 2009-06-27 12:12:36 PDT
I have to add, I'm all for following the specs, but the demand for this feature is high, and if we use the -moz, this can be considered a browser feature, instead of something that W3C have to spec. And, as at least two browsers has implemented it, it's on it's way to become a suggestion to be standardized. If it was implemented here, it might as well be considered by the W3C to become a standard.
Comment 144 Jared McAteer 2009-06-27 12:20:56 PDT
Please refer to the whiteboard and comment #134, unless you're volunteering to fix it please stop.
Comment 145 Daniel.S 2010-12-28 04:43:02 PST
*** Bug 547260 has been marked as a duplicate of this bug. ***
Comment 146 j.j. 2011-03-31 14:05:12 PDT
*** Bug 646960 has been marked as a duplicate of this bug. ***
Comment 147 Zéfling 2011-04-14 13:38:23 PDT
The proposal of Webkit is really not interesting?
http://www.webkit.org/blog/363/styling-scrollbars/

For example, with -moz-transform, the system scrollbars are very horribles with Windows Classic Theme.
Comment 148 Sergey «Mithgol the Webmaster» Sokoloff 2011-06-19 05:53:46 PDT
Please see if the bug 590945 is related.
Comment 149 DSH 2011-12-02 21:49:18 PST
I've read quite a few proposals here on how a custom scrollbar could be implemented.  Instead of going with the IE example, though, why couldn't we use webkit?

IE allows for customizing a scrollbar, but it looks...well, ugly when customized (though still better the default).

Both Safari and Chrome accept webkit codes, and the solution only requires customizing the CSS/HTML for the web-designer.

Example: http://desolosubhumus.webs.com

(In IE, my colors are set mostly to black, except the highlights and arrows.  In webkit, my scrollbar track background is set to transparent and the slider is a simple 10x10 px .jpg.  The scrollbar for the 'buttons' div is the default and looks horrible in FF and Opera.)

The scrollbar should be coded to only work for scrollbars within the page (divs, forms, etc., and not for the browser scrollbar (the one that scrolls the whole page).  Also, a new entry in settings could be added.  The user can choose fonts, font size, etc.; why not allow them to turn on custom scrollbars, with the default pre-selected to off?

I'm typically anti-Apple, but webkit looks to be a good thing (http://www.webkit.org/).  Feel free to look at my source code on my page to see how I implemented it (External Stylesheet: http://desolosubhumus.webs.com/ess.css).
Comment 150 Ruslan 2012-07-04 15:31:58 PDT
Hi,

Dear Developers, please, please and please add this feature, it will be really awesome(and needed :() addon.

Many, Many Thanks !!!
Comment 151 mihal.v 2013-01-04 11:05:44 PST
Created attachment 698002 [details]
tomorrow.do view in FX vs Chrome

Look at tomorrow.do view in Firefox and Chrome :)))) My first vote here for this bug!
Comment 152 sirninjamonkey 2013-02-21 14:35:50 PST
It's really quite a shame that this isnt already added; really hope it is eventually.
Comment 153 i 2013-03-03 22:11:11 PST
This would be a godsend to us simpletons which don't know or want to use javascript to STYLE the scroll bar. This would be incredibly appreciated if implemented!
Comment 154 Brian FitzGerald 2013-05-23 08:56:46 PDT
As one of the most well-respected open source software companies in the world, I know you are aware that the needs of users drive the direction of great software. As your users, we need this feature for all the reasons I am about to describe.

I think usability purists (i.e. "the scrollbar should never change for the sake of pure consistency") are not looking at this situation the "right way". As UI designers, we don't want to style scrollbars to make our users’ experience confusing or difficult - in fact, exactly the opposite is true.

We don't want styleable scrollbars so that we can style the main scrollbar on the right hand side of the screen (although at times that would certainly also be handy), but rather, we want styleable scrollbars because of the in-page "widgets" and "containers" that are are now commonplace in today's world of increasingly sophisticated web apps.

As UI designers, we only have a certain amount of screen real estate to work with, and often times, while we may want to load a larger set of data, it doesn't make sense to display the entire data set on the screen at the same time.

Take the example of a list of "friends available for chat" widget in the left sidebar of a web app. At any given time, a user may have 50 friends available for chat, but in order to display all those users at once, you would need a ridiculously long vertical sidebar! Such a long sidebar would obstruct the layout and lead to an imbalanced design. In order to solve this problem, the designer may choose to show only 10 users and let the rest of the users overflow - hence the need for a scrollbar. At this point, if we are forced to use the browser's default scrollbar we end up with a large, grey, clunky scrollbar in the middle of our layout that is in fact very distracting to our users. If we have another widget above or below our "friends available for chat" widget, we end up with two (or more!) excessively large scrollbars cluttering up our layout and distracting users from our content.

This leaves us with two options, live with the distracting scrollbars, or go find a javascript plugin to achieve the desired effect. Upon the demands of our bosses and clients (and our own good design sense) for a cleaner user interface, however, we discover that we are not left with two choices at all, we are left with one: write from scratch or research and find, learn, and implement a javascript plugin.

Aside from the amount of time this takes away from the core focus of our projects, this poses an entirely new set of problems in that we now introduce an additional external dependency into our code base which opens the door for bugs and slows down our apps by requiring additional http requests, among other side effects. This is especially dangerous now when one considers that the selected javascript plugin must support so many different browsers, operating systems, screen sizes, devices, etc. *Writing a great scrollbar is hard! It takes a lot of knowledge and code. You guys have already put in the work and have an excellent scrollbar system that is built into the browser - why not let us use it?

This bug has been submitted on bugzilla.mozilla.org on 30 distinct occassions, all the way from 2001 to 2013. There are close to 100 bugzilla users subscribed to this thread hoping for a resolution. There are stackoverflow posts with 50+ upvotes hoping to see this feature in Firefox. There are countless forum posts and questions regarding solutions and workarounds.

Speaking on behalf of your users, we would really, really like to see this feature added to Firefox.
Comment 155 rae.long@gmail.com 2013-06-13 10:14:01 PDT
!$
!$

I am wondering when too...Seems like js is overkill.

Overflow is understood by firefox, and firefox can draw boxes...hmmmm....

...seems like a pretty big deal to everyone......
Comment 156 Alex Shilov 2013-06-20 07:19:28 PDT
The new devtool's "Responsive design mode" (in nightly) currently using Firefox Mobile scrollbars, which looks great, doesn't lags and could be acceptable solution as webpage custom stylable scrollbars.
http://hg.mozilla.org/mozilla-central/file/a67425aa4728/browser/devtools/responsivedesign/responsivedesign.jsm

At least - they already looks good enough (perfect for me) or at least far far better than Windows default gray scrollbars. It just requires a trigger for us web-developers to turn them on on web-page like calling this.switchToFloatingScrollbars or etc. like in:
http://hg.mozilla.org/mozilla-central/file/a67425aa4728/browser/devtools/shared/FloatingScrollbars.jsm

At most - I beleive they can be stylable. If you have one gray block element - you can color it how you want. You can add some child or pseudo elements inside it, bind some actions etc. Thats similar how webkit is currently does. I beleave page could toggle floating scrollbars ON when detect ::-moz-horizontal-scrollbar rule in CSS.

Today most web-applications use some scrollable widgets. (See gmail, youtube). And standart Windows scrollbar actually looks bad on them. I, as a web-developer and UX/UI designer I want to create a rich web-applications, may be even using fullscreen, without single page scrollbar but with many scrollable widgets. And I want to style many browser controls, such as checkboxes, selects and scrollbars. It could be done by javascript, but as soon as native css implementation will appear I defenetely would use it instead of js. 

I hope that custom scrollbars in Responsive design mode is a step forward in fixing this bug. Thanks.
Comment 157 David Winiecki 2013-11-16 08:50:26 PST
+1 for -moz-scrollbar-*
Comment 158 sirninjamonkey 2013-11-16 13:01:38 PST
I dont really know much about the programming side of this but I don't see why people are worried about it being misused; personally, I'd much rather be able to view and create webpages with scrollbars that match the theme. Yes, it's possible that it /could/ be used badly, but /anything/ could be used badly - the browser isn't responsible for making people good at website design. I could go make a website with a neon yellow background and white text. It'd be pretty much unusable, even without the ability to customize scrollbars. On the other hand, as it is, scrollbars look awful on dark backgrounds and there's no way to change that. Even if a couple people make scrollbars look bad, the vast majority would actually be improving their sites.

As for the people who are saying it should be like in IE: that would be better than nothing, but something more along the lines of Google Chrome's approach to it would allow for much more customization, which I think is always a good thing.
Comment 159 Mikhail 2013-11-17 05:26:04 PST
I want just demonstrate how custom scrollbars much better than default scrollbars in Firefox
Comment 160 Mikhail 2013-11-17 05:27:19 PST
Created attachment 833460 [details]
compare scrollbars Chrome vs Firefox
Comment 161 flying sheep 2013-11-17 05:43:49 PST
(In reply to Mikhail from comment #160)
> Created attachment 833460 [details]
> compare scrollbars Chrome vs Firefox

i’m all for that proposal, but in this example, i actually didn’t notice the custon scrollbars in chrome for a long time.

the case where this is most important to have imho is when the default scrollbars are used in a scollable container in the middle of a styled page, not for the whole <body>. such as like, the textbox i’m just typing in.
Comment 162 Arpad Borsos [:Swatinem] 2013-11-17 05:57:23 PST
You guys do know you can implement that thing very easily yourself? Like this: https://github.com/Swatinem/scrollbars

And you can use https://github.com/component/grow to avoid scrollbars in textareas alltogether. But those are important for usability.
Comment 163 flying sheep 2013-11-17 07:27:57 PST
(In reply to Arpad Borsos (Swatinem) from comment #162)
> You guys do know you can implement that thing very easily yourself? Like
> this: https://github.com/Swatinem/scrollbars

javascript? to statically style scrollbars?

thanks, not interesting.
Comment 164 flying sheep 2013-11-17 07:30:10 PST
PS: didn’t want to sound rude. what i mean ist that embedding jQuery & your script is just too much work for sth. that should be as easy as adding a new CSS rule. :)
Comment 165 Evan 2014-01-13 19:43:22 PST
Any scroll bars created inside the HTML document should be able to be styled. This bug comes from a fix from 1999 - today web apps are increasing in complexity and as such require overflowed elements, widget boxes, etc to have their scroll bar styled away from a large nasty default block to a something thin or even invisible.

The fact that this discussion has been ongoing since 2001 should show how important this change is. Currently all major browsers now support this to some extent except Firefox.
Comment 166 u496860 2014-01-28 04:03:25 PST
who would be the developer which we (the web developers) need to convince that this feature would increase the quality of the browser?
Comment 167 Liz Henry (:lizzard) (needinfo? me) 2014-02-12 09:22:19 PST
*** Bug 971105 has been marked as a duplicate of this bug. ***
Comment 168 Evan 2014-02-27 22:11:16 PST
(In reply to paul from comment #166)
> who would be the developer which we (the web developers) need to convince
> that this feature would increase the quality of the browser?

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

First comment in the original 'issue'. Hixie says its not a good idea. Maybe this was not a good idea in 1999 but it's a standard now.
Comment 169 Ben Frain 2014-03-27 09:02:18 PDT
I'd love to see this feature get support in Firefox. Styling the shadow DOM elements is becoming increasingly the norm.
Comment 170 Yuval Bar-On 2014-04-08 12:22:38 PDT
I'm volunteering to fix this. 

I've gone over most of the discussion here, and as per comment #134 and later discussions it is my understanding that the fix would require changes to C++ level binding of the scrollbar XBL, and the general consensus is to use pseudo elements similar to the ones used by webkit, i.e. ::-moz-scrollbar.

Since this is a decade long issue, and seems to have been solved and removed at some point due to security issues, I would love to receive some input and information from anyone who has tried to tackle or investigate this before me. From my research thus far, this issue is currently not being handled by anyone else. 

Furthermore, I am rather new to the community, so I'd also love to know who might be willing to help me and on what channels of communications can we cooperate. I have very basic knowledge of C++, but I have a lot of programming experience (and web development experience in particular), and I think I can figure it out. It's also something I terribly want to see fixed, it's high time we stop using JavaScript to resolve such a basic design requirement every site should be able to modify.
Comment 171 Matthew N. [:MattN] (PM me if requests are blocking you) 2014-04-08 12:34:28 PDT
(In reply to Yuval Bar-On from comment #170)
> Furthermore, I am rather new to the community, so I'd also love to know who
> might be willing to help me and on what channels of communications can we
> cooperate.

I would recommend joining irc.mozilla.org #introduction to get setup with builds and fixing some mentored or good first bugs first. Then join #developers to discuss implementation of this bug. Maybe try ask dbaron, ehsan or roc (as a start) on advice to fix this.
Comment 172 Yuval Bar-On 2014-04-08 13:01:05 PDT
Thank you Matthew! I have already followed the instructions to setup a build environment and got everything ready on that end. I have just joined the IRC channel, and I will ask them. I know I should probably take something simpler first but this is kind of a pet peeve, and would like to fix it if possible.
Comment 173 David Baron :dbaron: ⌚️UTC-10 2014-04-09 00:35:40 PDT
So a few thoughts:

 (1) this is a pretty involved bug; it would take weeks to months of work for a full-time engineer

 (2) it's important not just to implement something, but to implement something that has a path towards standardization.  A first step towards that is to have a brief description of what other browsers do for styling scrollbars.  Then it's worth discussing what people would be willing to standardize on www-style.  I think any impression that there's a consensus about what to do here is premature.  Also see https://wiki.mozilla.org/WebAPI/ExposureGuidelines

   (2a) You need to figure out what styling looks like, which means figuring out whether styles attempt to modify the native appearance or whether styles cause the native appearance to go away and be replaced by a generic style.  This might vary depending on the style.  (I think some of the previous discussion assumed replacement by a generic style, but I think a lot of the previous discussion may have *predated* native-appearance scrollbars.)

   (2b) If there's a generic style, you need to figure out what that style looks like and get it to a high enough quality that authors/developers would be happy to use it in their pages/applications.  The existing hidden elements that underlie our native scrollbars probably aren't good enough; they haven't been used for nearly a decade.

   (2c) If the styling applies to native scrollbars, you need to figure out how that works for each platform.

   (2d) You need to figure out the syntax for specifying styles.  This likely depends on the answers to (2a)-(2c).

 (3) Adding the ability to style scrollbars involves weighing the needs of authors/developers vs. those of users.  Many users likely prefer a scrolling UI that matches their platform's.  But when authors implement their own scrolling UI entirely just so that they can style it, that's often worse for both authors and users.  Do you have any way to estimate what portion of the uses of styled scrollbars would replace authors writing their own scrolling UI, and what portion would replace unstyled scrollbars?  And do you have any way to measure user preferences for native-looking scrolling UI and user ability to interact with unexpected scrolling UI?

 (4) Since fixing this will involve substantive changes to our scrollbar code, it's worth considering other future plans for that code.  The most important such plan that I'm aware of is that we'd like to avoid creating the underlying element structure for native-drawn scrollbars, since we don't need those elements for presentation.  Currently we depend on them for some of the mechanics (though probably less so over time).  So we shouldn't make changes that would add new dependencies on the inner elements in cases where we don't need them.
Comment 174 Bobby Mozumder 2014-04-09 01:15:47 PDT
For (3), 100% of front-end web designers support having all pixels within their user environment under their control.  There are zero designers that prefer the user experience to be defined by the user. 

Any "user preference" is irrelevant, since designers should always override user preferences.  You never want to give the user control, since the user does not know what's good for him, and a designer knows what the user wants more than the users themselves.   It is their job to know what the user wants, more than the user.
Comment 175 Yuval Bar-On 2014-04-09 01:41:03 PDT
(1) I'm patient like that. Whatever time it will take. My one reservation is actually about too much C++ (which isn't my strongest part). I'm currently not even sure where I need to look for it (I've scanned the src files, but I still can't exactly tell where I need to focus the most).

(2) I think styling scrollbars, while years ago was an IE oddity, has become a very common standard. As a web developer and designer, I know what other browsers do. It's exactly why for me it feels missing on Firefox.

(2c) My thoughts are to start with fixing this for Firefox only. Both because this is a lot more important there, but also because if a fix for FF will cause bugs with the scrollbar in the other platforms, then that's a new issue entirely (that's the way I see it at least).

(2a, 2d) The styles should replace the native appearance. But it's more than just that - a developer should be able to create different scrollbar styles for different dom elements on the same page. Syntax-wize it should be considered as a psudo class, similar to the way webkit does. Eventually, a developer should be able to do something like this:


    ::-moz-scrollbar {
         background-color: purple;
    }

    ::-moz-scrollbar-thumb {
         background-color: red;
    }

    div.darkarea::-moz-scrollbar {
        background-color: white;
    }

    div.darkarea::-moz-scrollbar {
        background: gray;
    }


That being said, though, that the styling should be rather limited. you can change width (and the handle max-height I guess), but other than that it's mostly about changing colors and borders. It should also include a "content" attribute similar to other pseudo elements, thereby allowing both to use either images or font icons or similar.

(3) I completely agree with @BobbyMozumder, I don't think there's any issue here regarding user experience. Providing a good UI isn't the responsibility of the web browser, and it would be easier to provide an extension that ignores scrollbar styling for those few out there who really want it to always stay the same.
Comment 176 flying sheep 2014-04-09 01:58:34 PDT
generally: there are two main styles for scrollbars: overlay (optionally fading out) and occupying space. we should support both.

there should be a way to toggle if the scrollbar occupies space or not (maybe by doing ::-moz-scrollbar {display:none}?)

also for the fading, we need to add a pseudo-class to the element or the scrollbar pseudo-element. then something like…

::-moz-scrollbar {display:none}
::-moz-scrollbar-thumb {opacity:0; transition:opacity}
:-moz-scrolling::-moz-scrollbar-thumb {opacity:1}

…would leave the native thumb, just hovering and fading.

i’d say we give :-moz-scrolling to the element, make the scrollbar buttons (arrows) children of the scrollbar track, and the thumb not (in order to be able to hide the track, but not the thumb)

2) i’d say we do native styling like for the buttons: once a background-color/image is applied or the border(-radius) is changed, the scrollbars lose their native styling and fall back to a default style.

i’d say we don’t use 90’s bevelled borders for that fallback style, though, but a more flat one.

3) i’d say even less to motivate stylable scrollbars: scrollbars are part of the content area and as such stick out like a sore thumb when they are unstyled in an otherwise styled environment. just look at any element with overflow:auto on a dark website.

i’m all about native appearance, but only for the chrome, not websites. on websites, whatever the designer did should be considered native.

---

beyond this: we should also be able to seamlessly style all form elements. the form elements are in a sad state of being halfways stylable (e.g. when styling <select>, it gets a ugly bevelled dropdown handle that’s unstylable and really needs to become a pseudo-element). i hope the work being done here will be applicable to them later.
Comment 177 chris 2014-10-28 04:56:57 PDT
any news on this?

+1 for -moz-scrollbar-* too.
Comment 178 j.j. 2014-10-28 14:43:20 PDT
*** Bug 1090029 has been marked as a duplicate of this bug. ***
Comment 179 Lewie 2014-11-01 05:00:08 PDT
I know I probably shouldn't comment but it's been eight years since comment #134..

@YuvalBar-On Any update on this?
Comment 180 maciekpaprocki 2014-12-08 02:55:20 PST
This is the "most wanted" when it comes to Firefox features, as pc version of scrollbar is extremely ugly :)
Comment 181 Yuval Bar-On 2014-12-08 03:15:46 PST
(In reply to Lewie from comment #179)
> I know I probably shouldn't comment but it's been eight years since comment
> #134..
> 
> @YuvalBar-On Any update on this?

Hi @Lewie. Sadly, no, no update. 

I tried digging into it but the more I tried the more I realized this is related to C++ core code - you need to create XUL bindings, an area I don't have any expertise in (I'm a good programmer, but C++ and a dedicated language like XUL are still beyond me). I also tried asking around in the IRC but the people who understand this sort of thing usually weren't around to help. 

It seems to me that until a core developer who's already well acquainted with the code decides to do it, there's not much the community can do (unless there's some C++ ninja hiding here who wants to spend a month or two on it). 

It's sad really, because I truly think it's one of the biggest things that bother me about Firefox (no, really. To most devs, changing the scrollbar seems negligent, but it's actually extremely important to a website's design, and using javascript libraries instead of css for it is a goddamn nightmare)
Comment 182 collinjames81 2015-02-11 10:27:41 PST
I would also love to see this. JS scrolling is a pain and taxes resources... but it's incredibly ugly to have system scrollbars hanging around in a very clean design, especially when nested scrolling is a factor.
Comment 183 Makc 2015-02-28 08:25:59 PST
> incredibly ugly to have system scrollbars hanging around in a very clean design

but it makes firefox users feel powerful. they decided to have ugly scrollbar and the webpage is helpless to do anything about it. take that, webpage! suck it, designer! oh wait, it's not users, it was developer decision. oh well.
Comment 184 Ruben Vuittonet 2015-03-05 18:50:24 PST
@Christian:Biesinger: Content producers produce. Content consumers consume. If you don't like a producer's site, feel free not to visit it. 
 
Here is an example of an ingenious site (flash), that hinks up the UI in a fantastically amazing way. 

http://www.screenvader.com/

Maybe they should put the cuffs on him because he doesn't subscribe to some stilted idea of UI development. 

IMHO, no aspect of the page should be left out of the developer's control.
Comment 185 Ruben Vuittonet 2015-03-05 18:53:37 PST
Also, FF is sort of a laughing stock in regard to customizing the the scroll bars. 

While using JavaScript libraries is all very nice, it does pose a security risk, unless you have time to interrogate every line of code in a given library. 

CSS, on the other hand, just lets us configure our UI elements in a simple, elegant way.

Without such features, Mozilla becomes Lesszilla.
Comment 186 Amy 2015-03-07 14:00:49 PST
So, I think after fourteen years of patiently waiting around for you to FINALLY get around to incorporating this into your browser, I am officially walking away from Mozilla. Google Chrome now offers everything I want and is a much better alternative than Mozilla now.

I registered with a Bugzilla account just so that I could post this comment and never use Mozilla Firefox again. Hope that you guys can get your head in the game and start offering this, because I can tell you right now that I am going to encourage EVERYONE I know in web design to use Chrome instead.
Comment 187 David Baron :dbaron: ⌚️UTC-10 2015-03-07 14:29:24 PST
(In reply to Yuval Bar-On from comment #175)
> (2c) My thoughts are to start with fixing this for Firefox only. Both
> because this is a lot more important there, but also because if a fix for FF
> will cause bugs with the scrollbar in the other platforms, then that's a new
> issue entirely (that's the way I see it at least).

By "each platform", I meant Windows, Mac, Linux, Android, Firefox OS.  (In some cases, there might be different considerations for different versions as well.)  But given your answer to the following question, that matters less.

> (2a, 2d) The styles should replace the native appearance. But it's more than
> just that - a developer should be able to create different scrollbar styles
> for different dom elements on the same page. Syntax-wize it should be
> considered as a psudo class, similar to the way webkit does. Eventually, a
> developer should be able to do something like this:

If they replace the native appearance, they still need to start from somewhere.

Or maybe they don't; maybe the mechanism for styling scrollbars should be a mechanism for replacing scrollbars with something like Web Components.  That would remove a bunch of the concern about figuring out all the interactions.

> (3) I completely agree with @BobbyMozumder, I don't think there's any issue
> here regarding user experience. Providing a good UI isn't the responsibility
> of the web browser, and it would be easier to provide an extension that
> ignores scrollbar styling for those few out there who really want it to
> always stay the same.

That's the answer I'd expect from designers, but that doesn't mean it's the only answer.  There's still a real tradeoff.

(In reply to Yuval Bar-On from comment #181)
> I tried digging into it but the more I tried the more I realized this is
> related to C++ core code - you need to create XUL bindings, an area I don't
> have any expertise in (I'm a good programmer, but C++ and a dedicated
> language like XUL are still beyond me). I also tried asking around in the
> IRC but the people who understand this sort of thing usually weren't around
> to help. 
> 
> It seems to me that until a core developer who's already well acquainted
> with the code decides to do it, there's not much the community can do
> (unless there's some C++ ninja hiding here who wants to spend a month or two
> on it). 

I don't think that's true of figuring out how the feature should work -- effectively, writing a specification for the feature.  Perhaps that's true of implementing it.  But figuring out what the feature should be doesn't require that knowledge, although it does require interacting with and sometimes listening to people who do.  And getting a specification for what ought to happen is a significant part of the work here.  (Or even getting a clear description of what other browsers do.)
Comment 188 Vlad Magdalin 2015-04-05 16:06:18 PDT
This issue is the #1 reason that Webflow doesn't support Firefox natively. Not having the ability to style scrollbars makes our entire application UI look very janky, for lack of a better word. When the entire interface is dark, white scrollbars stick out like a sore thumb - and remind the user that they are on a website, not a web application.

We would be willing to set up a $2,500 bounty (or higher, depending on completion timeline) to get this feature implemented. Ideally, the implementation would follow Webkit's syntax closely (which works well in Chrome, Safari, and Opera): https://css-tricks.com/custom-scrollbars-in-webkit/ 

If there's any interest, please contact me (email in profile).
Comment 189 rishi sharma 2015-04-09 11:56:31 PDT
there has been an update every week, its so annoying, and yet no style-able scrollbars. 

y u no let style scrollbars?

ps - just created an account to leave this comment from chrome browser. tee hee hee
Comment 190 flying sheep 2015-04-11 04:50:13 PDT
(In reply to rishi sharma from comment #189)
> there has been an update every week, its so annoying, and yet no style-able
> scrollbars.

read a few of the comments: it’s hard to implement.

take up coding and try yourself if you don’t believe it.
Comment 191 Victor 2015-04-11 10:43:15 PDT
Hi,
Would bountysource be a good way to put some money where our collective whinging mouths are?

They seem to track bugzilla, here's a link to this bug:

https://www.bountysource.com/issues/10530078-style-the-scrollbar-binding-moz-horizontal-scrollbar-to-xbl

I have never used them, and I have no idea if Mozilla is cool with it.  
I'd like to know it will do some good before spending the money...

Thanks,
Victor
Comment 192 Mats Palmgren (:mats) 2015-05-26 06:22:44 PDT
*** Bug 1168282 has been marked as a duplicate of this bug. ***
Comment 193 Ruben Vuittonet 2015-06-19 10:27:54 PDT
I've posted before on this topic... cases in point for why styling scroll bars should be permitted. 
Consider the two images below. One from FF, the other from Chrome...

http://bit.ly/1IoPV2F
Notice how poorly the page looks with those ugly scroll bars. Considering the widespread support for this with other browsers, I don't think I should have to do extra work to support it in FF (and I won't, I'll simply stop using FF, one day).

http://bit.ly/1ITw9zd
Chrome is much nicer.
Comment 194 Makc 2015-06-19 10:32:31 PDT
@Ruben, it is unlikely that you or any other user will stop using firefox over scrollbars. But it is likely that users will stop visiting the website, if it is ugly.
Comment 195 Ruben Vuittonet 2015-06-19 10:45:48 PDT
@Makc: that's fine. I developed the site for fun. If I have to spend hundreds of hours tweaking HTML, CSS, et al or use a bunch of libraries to get around basic deficiencies, it will not become fun. 

It is amazing - if you look at my examples - how much more cohesive the image from chrome appears. 
And that's the point. 

As I said, I developed the site for FUN, not to support browser developers with dogmatic attitudes. 
I believe dogmatism is fine right up to the point where the dog bites you. 

And yes, I am already on the verge of dispensing with FF. 

As proof of what I say, you should try my site in IE. 
http://www.conceptual-nachos.com/images/1000Cranes/Final_Bamboo/1000Cranes.html
Comment 196 Ruben Vuittonet 2015-06-19 10:46:52 PDT
@Makc: further, why is it that Mozilla doesn't care about how much effort goes into what I do. 

THEY should be in the business of making sure their browser is full-featured. They seem to get a pass while the rest of us slave on dealing with their browser's inadequacies.
Comment 197 Makc 2015-06-19 11:00:00 PDT
@Ronen: as a website author, you make a choice, do you want your site to look great in Firefox or not. You could simply show "get a better browser" with Chrome link, as firefox fans did back in IE days, as an excuse to not invest enough in polishing your content :)
Comment 198 Brian FitzGerald 2015-06-19 11:13:47 PDT
"Polishing your content" ....... means including an extra js library load, ensuring that library behaves as expected in all browsers, ensuring that library behaves as expected on tablets, ensuring that library behaves as expected on smartphones, ensuring that library behaves as expected when loading many instances of itself on the same page to support multiple scrollers, ensuring that library behaves as expected with nested scrolling, ensuring that library loads conditionally based on browser type so I'm only loading it for Firefox, hmmmz.... yeah good idea I think I'll just forward them to a Chrome download link.
Comment 199 Ruben Vuittonet 2015-06-19 11:23:21 PDT
@Makc: I now understand your position very, very clearly. 

You support the dogmatic idea that developers (of which there are millions, spending millions of man hours) are making "excuses," while Mozilla, who could fix this easily (with a fraction of the aforementioned man-hours), gets a pass.

Do you actually work for Mozilla? 

@Brian Fitzgerald: Exactly.
Comment 200 Makc 2015-06-19 11:30:13 PDT
@Ruben, in a perfect world, Mozilla would fix this. in our real world, they are not going to. you need to accept it and decide your course of action. pretty simple.
Comment 201 Ruben Vuittonet 2015-06-19 11:33:47 PDT
@Makc: I did that and will continue to do that. Since I am doing that, I am confused as to why you keep bringing it up. You act live I have to simply take it (what mozilla does) when, in fact, I can leave it.

Oh, I get it: you seem to think I should make the same decisions as you or I am wrong. 

Fortunately for me, it's a larger world than that.
Comment 202 Makc 2015-06-19 11:40:25 PDT
@Ruben, that's flawed conclusion and you know it. My reading of it is that your decision was to start the flame war in this bug report comments? Why do you think it will give you style-able scrollbars?
Comment 203 Matthew Bogosian 2015-06-19 12:16:57 PDT
The whiteboard asks to refrain from commenting unless contributing to a fix. I would like to remain CC'ed so I can be alerted to any progress, but there is a lot of noise. Instead of commenting, please consider voting for this issue[1], offering a bounty[2], and/or finding someone willing capture an existing bounty[3]. In any event, please consider reading Poul-Henning Kamp's famous e-mail[4] before continuing to comment. Thank you.

[1] https://bugzilla.mozilla.org/page.cgi?id=voting/bug.html&bug_id=77790
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=77790#c191
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=77790#c188
[4] https://docs.freebsd.org/cgi/getmsg.cgi?fetch=506636+517178+/usr/local/www/db/text/1999/freebsd-hackers/19991003.freebsd-hackers
Comment 204 Ruben Vuittonet 2015-06-19 14:03:36 PDT Comment hidden (off-topic)
Comment 205 SteveC 2015-08-19 09:29:18 PDT
Getting this back on track... Updates please....

Is anything happening in Firefox community to add styles to scrollbars?

I, as a end user app developer, think it is mandatory for future user screens. We can code here and might jump in on this is we can get a good feel on what's been done and where to start.

To be consistent with the Whiteboard request please reserve comments to actual reports of activity on this subject. Thank you.
Comment 206 ge8211 2015-09-10 02:54:50 PDT
Since Mozilla is deprecating XUL/XBL (if I've understood it right) do we need to work out an alternative solution to XBL as suggested in comment 187? (blog post https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/)
Comment 207 acerspyro 2015-10-13 16:11:24 PDT Comment hidden (abusive, me-too)

Note You need to log in before you can comment on or make changes to this bug.