Closed Bug 77790 (scrollbar-colors) Opened 23 years ago Closed 5 years ago

Style the scrollbar (binding ::-moz-horizontal-scrollbar to XBL)

Categories

(Core :: Layout, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1460109

People

(Reporter: SkewerMZ, Unassigned)

References

Details

(Whiteboard: DON'T COMMENT UNLESS YOU ARE FIXING IT; see solution in comment #134 [platform-rel-Symantec])

Attachments

(4 files, 1 obsolete file)

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...
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. :)
Oh Hixie, invalidate?
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.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
Verifying resolved bugs.
Status: RESOLVED → VERIFIED
*** Bug 81397 has been marked as a duplicate of this bug. ***
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
*** Bug 132366 has been marked as a duplicate of this bug. ***
*** Bug 141565 has been marked as a duplicate of this bug. ***
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.
*** Bug 146846 has been marked as a duplicate of this bug. ***
*** Bug 150255 has been marked as a duplicate of this bug. ***
Now we have 1.1b - what can be done about that now?
An option in the preferences dialogue should be added so that coloured
scrollbars can be allowed.
Status: VERIFIED → UNCONFIRMED
Resolution: WONTFIX → ---
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Scrollbar color CSS properties (IE5.5) → Style the scrollbar (e.g. CSS color from IE5.5)
OS: Windows 98 → All
Hardware: PC → All
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.
Attached file draft and testcase (obsolete) —
adding a draft about my suggestions. It also works as a testcase for the
properties which should be added.
ok, this time with an eye friendly example - sorry for the spam...
Attachment #92743 - Attachment is obsolete: true
I'm glad work is being done here, I really want this feature implemented.

-- M. :-)
*** Bug 158318 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.2
I don't think this bug should be fixed. Web pages should not be allowed to
change browser chrome - this confuses users.
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.
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.
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.
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.
How would you color Aqua scrollbars (especially the slider) without suddenly
making them extremely ugly?
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.
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?
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.
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
> 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.
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?
Summary: Style the scrollbar (e.g. CSS color from IE5.5) → Style the scrollbar (e.g. CSS color from IE5.5+)
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?
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.
Why not 1.1 ? The sooner, the better :-)
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).
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.
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.
Blocks: 164421
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.
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!)
"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.
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).
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/
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.
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.
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.
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.
Alias: scrollbar-colors
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.
"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.
>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)
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.
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.
Skewer, I hope "native" means "native-looking" here?  Because actually using
native scrollbars in content is a really bad idea....
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?
Summary: Style the scrollbar (e.g. CSS color from IE5.5+) → Style the scrollbar (binding ::-moz-horizontal-scrollbar to XBL)
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.
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.
Im thinking this bug might depend on bug 61188 , in Windows any way
*** Bug 171849 has been marked as a duplicate of this bug. ***
*** Bug 174173 has been marked as a duplicate of this bug. ***
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 :-)
The toy factory theme has a yellow scrollbar there is no special coding in the
page that has changed the colour.
*** Bug 177174 has been marked as a duplicate of this bug. ***
So what's happening here???
Yea what is going on, nobody has posted anythin about it for a while.
Well, what's going on is that nobody has volunteered to do the work.

So, well, nothing is going on.
Oh dear :-(
I also would love for Moz. to implement the <style> support for scrollbars. That
wold be a great add on. 
*** Bug 204981 has been marked as a duplicate of this bug. ***
*** Bug 207113 has been marked as a duplicate of this bug. ***
I think this would be best kept fixed in Firebird, maybe?
Target Milestone: --- → Future
:(( I got told!!!

Hmm is this an enhancerment?
Target Milestone: Future → ---
Keywords: mozilla1.2
*** Bug 214651 has been marked as a duplicate of this bug. ***
*** Bug 216820 has been marked as a duplicate of this bug. ***
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.
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"...
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.
Be nice, and stop waving your advocacy willies in bugs, please.  The best course
is to find someone to implement the desired extension.

/be
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 :-)
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.
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;
}
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. 
This is independent of what app is being used.
Assignee: bugs → skinability
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?
*** Bug 234486 has been marked as a duplicate of this bug. ***
*** Bug 236568 has been marked as a duplicate of this bug. ***
*** Bug 236568 has been marked as a duplicate of this bug. ***
*** Bug 178651 has been marked as a duplicate of this bug. ***
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
*** Bug 245052 has been marked as a duplicate of this bug. ***
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.
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.
--> 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.
Let's just have this as a FireFox extension. Then everyone is happy, no?
(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!
(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.)
(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
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.
(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.
(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.
(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.
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.
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.
(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?
*** Bug 256444 has been marked as a duplicate of this bug. ***
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...
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.

should the product be changed to firefox?
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?
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.
*** Bug 271158 has been marked as a duplicate of this bug. ***
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.
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.
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 ...
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.
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.
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.
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.
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.
This helps! Do you remember the exact security bug number? I'll try thinking
whether its patch can be partially reverted.
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 :-((
Trying to add bug 21890 as a dependency.
Depends on: 21890
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.
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.
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.
Whiteboard: PLEASE DON'T ADD COMMENTS UNLESS YOU ARE VOLUNTEERING TO FIX IT
*** Bug 281696 has been marked as a duplicate of this bug. ***
*** Bug 285787 has been marked as a duplicate of this bug. ***
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.
(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)."
*** Bug 299456 has been marked as a duplicate of this bug. ***
*** Bug 299456 has been marked as a duplicate of this bug. ***
*** Bug 310725 has been marked as a duplicate of this bug. ***
*** Bug 311502 has been marked as a duplicate of this bug. ***
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.
Whiteboard: PLEASE DON'T ADD COMMENTS UNLESS YOU ARE VOLUNTEERING TO FIX IT → DON'T COMMENT UNLESS YOU ARE FIXING IT; see solution in comment #134
Blocks: 259640
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??
Product: Core → Core Graveyard
Assignee: skinability → nobody
As this is something Webkit supports too now, I think we should look into it again.
Flags: wanted1.9.2?
(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.
But as long as we use the -moz, we don't violate the specs?
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.
Please refer to the whiteboard and comment #134, unless you're volunteering to fix it please stop.
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.
Please see if the bug 590945 is related.
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).
Hi,

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

Many, Many Thanks !!!
Look at tomorrow.do view in Firefox and Chrome :)))) My first vote here for this bug!
It's really quite a shame that this isnt already added; really hope it is eventually.
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!
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.
!$
!$

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......
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.
+1 for -moz-scrollbar-*
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.
I want just demonstrate how custom scrollbars much better than default scrollbars in Firefox
(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.
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.
(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.
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. :)
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.
who would be the developer which we (the web developers) need to convince that this feature would increase the quality of the browser?
(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.
I'd love to see this feature get support in Firefox. Styling the shadow DOM elements is becoming increasingly the norm.
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.
Flags: needinfo?
(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.
Flags: needinfo?
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.
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.
Component: Skinability → Layout
Flags: needinfo?(dbaron)
Product: Core Graveyard → Core
QA Contact: bugzilla
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.
(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.
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.
any news on this?

+1 for -moz-scrollbar-* too.
I know I probably shouldn't comment but it's been eight years since comment #134..

@YuvalBar-On Any update on this?
This is the "most wanted" when it comes to Firefox features, as pc version of scrollbar is extremely ugly :)
(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)
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.
> 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.
@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.
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.
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.
(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.)
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).
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
(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.
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
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.
@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.
@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
@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 :)
"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.
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
platform-rel: --- → ?
Whiteboard: DON'T COMMENT UNLESS YOU ARE FIXING IT; see solution in comment #134 → DON'T COMMENT UNLESS YOU ARE FIXING IT; see solution in comment #134 [platform-rel-Symantec]
platform-rel: ? → ---
Restrict Comments: true
Flags: wanted1.9.2?
Gentle reminders:

* Our guidelines ask you don't argue about priority setting on bugs. Triage leads and Mozillians working on the bug set the priority. See: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

* This is not the place to discuss workarounds not specific to this bug. 

* Nor is it a place to argue for or against fixing a bug.

Extended, off-topic comments on a bug add noise to the signal. Per, https://bugzilla.mozilla.org/page.cgi?id=restrict_comments_guidelines.html, we've restricted comments on this bug to Mozillians with EDITBUGS permissions. 

If you can contribute to the resolution of this, or other bugs, please request EDITBUGS permissions. See https://bugzilla.mozilla.org/page.cgi?id=get_permissions.html for more information.
The CSS Working Group has accepted a (very rough) editor's draft for styling scrollbar colors:

https://drafts.csswg.org/css-scrollbars-1

Very much in-progress, but if you have suggestions for improving the draft, please file issues accordingly there: https://github.com/w3c/csswg-drafts/labels/css-scrollbars-1
Romain, please have product team review, esp. in light of a CSS working group looking at a spec.
Flags: needinfo?(rtestard)
(In reply to Emma Humphries ☕️ (she/her) [:emceeaich] (UTC-8) +needinfo me from comment #215)
> Romain, please have product team review, esp. in light of a CSS working
> group looking at a spec.

I have zero interest in doing anything until there is an actual spec unless someone on the platform teams is interested in prototyping the spec behind a pref.
Flags: needinfo?(rtestard)
With the XBL implementation of scrollbars being removed in bug 1431246 with plans to replace it using a native anonymous content implementation, it might be a good idea to figure out how to implement this during the planning phase, rather than trying to shoehorn it into a finished implementation, which would then likely result in this getting stalled for another 17 years or more.
Blocks: 1431246
See Also: → 1432935
No longer blocks: 1431246
Depends on: 1431246
See Also: → 1460109
Xidorn, can we close this as duplicate of bug 1460109 ?
Flags: needinfo?(xidorn+moz)
Yeah, I think we can.
Status: NEW → RESOLVED
Closed: 23 years ago5 years ago
Flags: needinfo?(xidorn+moz)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.