644361 - Improve the default rendering of the progress element

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Mounir Lamouri (:mounir)]

For the moment (with the currently written patches), it's a dark grey bar with a light grey border. Pretty simple and far from beautiful.
If you have any suggestion for what could be the default rendering, my ears are all open. We could also have a default rendering when the progress is in the indeterminate state...

Comment 1

[Josh Tumath]

Is this for when the default OS style is not being used?

If so I think we should have a white rectangle with a grey, rounded border (which could probably come from system colours). Then, use the Highlight colour for the actual bar.

Comment 2

[Mounir Lamouri (:mounir)]

(In reply to comment #1)
> Is this for when the default OS style is not being used?

Yes. Whether there is no default OS style or it has been disabled (with -moz-apperance: none for example).

Comment 3

[Mounir Lamouri (:mounir)]

Can we set a border radius to have rounded corners? That would be nicer but will force authors to reset the border radius if they don't want it. Should I be concerned about this?
In addition, I wonder what should I do regarding colors. Using system colors would be better regarding accessibility but I don't believe we can really found something that match nicely. In addition, system colors are usually nuance of grey which might let the user think the progress bar is disabled.

Comment 4

[Mounir Lamouri (:mounir)]

Attachment: Current rendering

Comment 5

[alexander :surkov (:asurkov)]

(In reply to comment #3)
> Can we set a border radius to have rounded corners? That would be nicer but
> will force authors to reset the border radius if they don't want it.

it's not a11y issue but I think it's nicer and comes with windows look'n'feel.

> In addition, system colors are usually
> nuance of grey which might let the user think the progress bar is disabled.

this point makes sense

also we should keep in mind I think that different gray nuances (gray on gray) may be not friendly to certain users.

David, do you know if there's best practice for that?

Comment 6

[Mounir Lamouri (:mounir)]

Attachment: Blue bar

Given that gray on gray isn't good (look disabled and harder to distinct), I chose a blue bar (blue doesn't have any specific meaning, in opposition to some colors like green).
I didn't use 'blue' for the background color because the color isn't nice but I chose a dark enough color to be sure it's easy to distinct it from the gray background.

David, is this okay regarding a11y? Would you prefer "blue" instead of the hex color I chose?

Comment 7

[Mounir Lamouri (:mounir)]

Comment on attachment 532647 [details] [diff] [review]
Blue bar

I believe I should have a layout peer review to land that patch so, Boris, could you do that given that we just talked about it on IRC?

Comment 8

[Josh Tumath]

As I was saying in comment 1, maybe the system "Highlight" colour would be better to use, because it would fit in with the user's system better. :)

Comment 9

[Mounir Lamouri (:mounir)]

Comment on attachment 532647 [details] [diff] [review]
Blue bar

I really meant Boris...

Comment 10

[Mounir Lamouri (:mounir)]

(In reply to comment #8)
> As I was saying in comment 1, maybe the system "Highlight" colour would be
> better to use, because it would fit in with the user's system better. :)

That seems weird because Highlight is a color used to highlight a selection so it might be really inappropriate for a progress bar color. Though, it might feet better with the user's preference.
I do not really like the idea of using an inappropriate color even if it can feet better the user's preferences. Though, if Boris or David think otherwise, I will change the patch.

Comment 11

[Mounir Lamouri (:mounir)]

(In reply to comment #10)
> (In reply to comment #8)
> > As I was saying in comment 1, maybe the system "Highlight" colour would be
> > better to use, because it would fit in with the user's system better. :)
> 
> That seems weird because Highlight is a color used to highlight a selection
> so it might be really inappropriate for a progress bar color. Though, it
> might feet better with the user's preference.

FWIW, on default MacOS X and Windows 7 theme, Highlight is blue. On GTK, that's going to depend on the distribution but I would bet it's blue on most of default distribution themes.

Comment 12

[Boris Zbarsky [:bzbarsky]]

> maybe the system "Highlight" colour would be better to use

For which?  "highlight" is a secondary control selection background color.  It's not appropriate to use for what is effectively a foreground color here.

Mounir, it's not OK to use -moz-Dialog for the background and #2375b4 for the foreground; you have no idea what color -moz-Dialog actually is and the result might have no contrast at all...

Comment 13

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 532647 [details] [diff] [review]
Blue bar

This needs to either use two system colors that are supposed to work together (e.g. Highlight and HighlightText or something) or two hex colors.

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Using two system colors sounds like the right way to go.

Comment 15

[Mounir Lamouri (:mounir)]

(In reply to comment #13)
> Comment on attachment 532647 [details] [diff] [review] [review]
> Blue bar
> 
> This needs to either use two system colors that are supposed to work
> together (e.g. Highlight and HighlightText or something) or two hex colors.

Unfortunately, HighlightText is white most of the time which is not really convenient given that most of the time the background is white. So, we probably want a gray system color that works with Highlight.

Comment 16

[David Bolter [:davidb] (NeedInfo me for attention)]

I agree that two system colors that are expected to contrast would be best. What about:
-moz-default-background-color
-moz-default-color

Ccing Limi since his team should be consulted here.

Comment 17

[Mounir Lamouri (:mounir)]

(In reply to comment #16)
> I agree that two system colors that are expected to contrast would be best.
> What about:
> -moz-default-background-color
> -moz-default-color

That's basically black and white for most systems.

> Ccing Limi since his team should be consulted here.

I think the priorities are:
1. Being not too ugly (and do not make it feel disabled like it is now) ;
2. Being easy to override ;
3. Being accessible.

To follow these three rules, we will have to use Highlight and something else for the background. Though, I wonder if using system colors is really mandatory. I believe we might have to not use them for <meter> (which is going to require green/orange/red colors). What are the cons against hex colors? I believe it might be worse for a11y but if we choose good colors, we might cover most situations and for the few users that have issues with it, they could override the default rendering in their user preferences.
My assumptions might be completely wrong... I just want to be sure to understand why we want system colors.

Comment 18

[Mounir Lamouri (:mounir)]

Attachment: With Highlight and Background

I believe those two system colors have to leave together: shouldn't Background and Highlight be distinguishable?

Comment 19

[David Bolter [:davidb] (NeedInfo me for attention)]

Comment on attachment 533599 [details] [diff] [review]
With Highlight and Background

r=me, I think this is right.

Comment 20

[Boris Zbarsky [:bzbarsky]]

> shouldn't Background and Highlight be distinguishable?

I think they could be identical as long as HighlightText is different enough from them and from normal text, no?

Put another way, on Mac HighlightText and normal text are the same color.  Why couldn't some other platform do that for background, not foreground?

Comment 21

[Mounir Lamouri (:mounir)]

(In reply to comment #20)
> > shouldn't Background and Highlight be distinguishable?
> 
> I think they could be identical as long as HighlightText is different enough
> from them and from normal text, no?
> 
> Put another way, on Mac HighlightText and normal text are the same color. 
> Why couldn't some other platform do that for background, not foreground?

IMO, that would be really weird to have something highlighted with the same color as non-highlighted one with the text color as the only distinction. Though, that's possible, yes.

So, if we consider Highlight/Background as a bad pair, I see only three solutions:
- keep the current style (but are the colors ok?);
- use two system colors than are obviously opposed (which is going to lead to a black and white progress bar);
- use hex colors.

Comment 22

[Mounir Lamouri (:mounir)]

Attachment: With Blue and LightGray

Comment 23

[Mounir Lamouri (:mounir)]

Attachment: With ButtonText and ButtonFace

I think we have to take one of these three patches or mark the bug WONTFIX.

Comment 24

[Mounir Lamouri (:mounir)]

If by any chance you have a simple idea for indeterminate progress bars that would work for vertical and horizontal ones...

Comment 25

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 533634 [details] [diff] [review]
With Blue and LightGray

This would be fine by me.

Comment 26

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 533637 [details] [diff] [review]
With ButtonText and ButtonFace

As would this.

Comment 27

[David Bolter [:davidb] (NeedInfo me for attention)]

Comment on attachment 533634 [details] [diff] [review]
With Blue and LightGray

r=me. I think this should meet contrast requirements.

Comment 28

[David Bolter [:davidb] (NeedInfo me for attention)]

Comment on attachment 533637 [details] [diff] [review]
With ButtonText and ButtonFace

r=me. Great contrast, but perhaps less appealing (?)

Comment 29

[Mounir Lamouri (:mounir)]

Is using predefined colors better than using hex ones? I mean, can users redefine them?

Comment 30

[Boris Zbarsky [:bzbarsky]]

Users can often change them by changing their OS color theme.

Comment 31

[Mounir Lamouri (:mounir)]

(In reply to comment #30)
> Users can often change them by changing their OS color theme.

I meant colors like 'blue' and 'lightgray'. They can be changed by the users?

Comment 32

[Boris Zbarsky [:bzbarsky]]

> I meant colors like 'blue' and 'lightgray'. They can be changed by the users?

No.  That's a hardcoded list.  See nsColorNameList.h.

Comment 33

[Mounir Lamouri (:mounir)]

Attachment: Patch to checkin

David, I changed the colors a bit. They are close to the previous ones but a bit nicer (according to me...). Could you double-check that nothing is wrong regarding a11y?

Comment 34

[David Bolter [:davidb] (NeedInfo me for attention)]

Comment on attachment 534409 [details] [diff] [review]
Patch to checkin

r=me. thanks for the ping.

Comment 35

[Mounir Lamouri (:mounir)]

Pushed:
http://hg.mozilla.org/mozilla-central/rev/85a96ef690b4

Thanks :)

Comment 36

[Vlad [QA]]

Hi. Can you please provide a testcase in order to verify this as being Resolved Fixed. I'm asking for this testcase or some STR because I'm the QA lead for the Progress Element feature.
Thanks

Comment 37

[Vlad [QA]]

Setting resolution to Verified Fixed on:
Mozilla/5.0 (Windows NT 6.1; rv:6.0) Gecko/20100101 Firefox/6.0
Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20100101 Firefox/6.0
Mozilla/5.0 (X11; Linux i686; rv:6.0) Gecko/20100101 Firefox/6.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20100101 Firefox/6.0
I've tested the fix for Fx6 beta using the testcase from the link:
http://hg.mozilla.org/releases/mozilla-beta/file/f327eb465d32/widget/reftests/progressbar-fallback-default-style.html