The default bug view has changed. See this FAQ.

Improve the default rendering of the progress element

VERIFIED FIXED in mozilla6

Status

()

Core
Layout: Form Controls
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: mounir, Assigned: mounir)

Tracking

Trunk
mozilla6
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 4 obsolete attachments)

(Assignee)

Description

6 years ago
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

6 years ago
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.
(Assignee)

Comment 2

6 years ago
(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).
(Assignee)

Comment 3

6 years ago
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.
(Assignee)

Comment 4

6 years ago
Created attachment 531079 [details]
Current rendering

Comment 5

6 years ago
(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?
(Assignee)

Comment 6

6 years ago
Created attachment 532647 [details] [diff] [review]
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?
Assignee: nobody → mounir.lamouri
Status: NEW → ASSIGNED
Attachment #532647 - Flags: review?(bolterbugz)
(Assignee)

Comment 7

6 years ago
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?
Attachment #532647 - Flags: review?(roc)
(Assignee)

Updated

6 years ago
Whiteboard: [needs review]

Comment 8

6 years ago
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. :)
(Assignee)

Comment 9

6 years ago
Comment on attachment 532647 [details] [diff] [review]
Blue bar

I really meant Boris...
Attachment #532647 - Flags: review?(roc) → review?(bzbarsky)
(Assignee)

Comment 10

6 years ago
(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.
(Assignee)

Comment 11

6 years ago
(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.
> 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 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.
Attachment #532647 - Flags: review?(bzbarsky) → review-
Using two system colors sounds like the right way to go.
(Assignee)

Comment 15

6 years ago
(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.
(Assignee)

Updated

6 years ago
Attachment #532647 - Flags: review?(bolterbugz)
(Assignee)

Updated

6 years ago
Whiteboard: [needs review]
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.
(Assignee)

Comment 17

6 years ago
(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.
(Assignee)

Comment 18

6 years ago
Created attachment 533599 [details] [diff] [review]
With Highlight and Background

I believe those two system colors have to leave together: shouldn't Background and Highlight be distinguishable?
Attachment #532647 - Attachment is obsolete: true
Attachment #533599 - Flags: review?(bzbarsky)
(Assignee)

Updated

6 years ago
Attachment #533599 - Flags: review?(bolterbugz)
Comment on attachment 533599 [details] [diff] [review]
With Highlight and Background

r=me, I think this is right.
Attachment #533599 - Flags: review?(bolterbugz) → review+
> 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?
(Assignee)

Comment 21

6 years ago
(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.
(Assignee)

Comment 22

6 years ago
Created attachment 533634 [details] [diff] [review]
With Blue and LightGray
Attachment #533634 - Flags: review?(bzbarsky)
(Assignee)

Updated

6 years ago
Attachment #533634 - Flags: review?(bolterbugz)
(Assignee)

Comment 23

6 years ago
Created attachment 533637 [details] [diff] [review]
With ButtonText and ButtonFace

I think we have to take one of these three patches or mark the bug WONTFIX.
Attachment #533637 - Flags: review?(bzbarsky)
(Assignee)

Updated

6 years ago
Attachment #533637 - Flags: review?(bolterbugz)
(Assignee)

Comment 24

6 years ago
If by any chance you have a simple idea for indeterminate progress bars that would work for vertical and horizontal ones...
Comment on attachment 533634 [details] [diff] [review]
With Blue and LightGray

This would be fine by me.
Attachment #533634 - Flags: review?(bzbarsky) → review+
Comment on attachment 533637 [details] [diff] [review]
With ButtonText and ButtonFace

As would this.
Attachment #533637 - Flags: review?(bzbarsky) → review+
Comment on attachment 533634 [details] [diff] [review]
With Blue and LightGray

r=me. I think this should meet contrast requirements.
Attachment #533634 - Flags: review?(bolterbugz) → review+
Comment on attachment 533637 [details] [diff] [review]
With ButtonText and ButtonFace

r=me. Great contrast, but perhaps less appealing (?)
Attachment #533637 - Flags: review?(bolterbugz) → review+
(Assignee)

Updated

6 years ago
Attachment #533599 - Flags: review?(bzbarsky)
(Assignee)

Comment 29

6 years ago
Is using predefined colors better than using hex ones? I mean, can users redefine them?
Users can often change them by changing their OS color theme.
(Assignee)

Comment 31

6 years ago
(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?
> I meant colors like 'blue' and 'lightgray'. They can be changed by the users?

No.  That's a hardcoded list.  See nsColorNameList.h.
(Assignee)

Updated

6 years ago
Summary: Have a nice default rendering for the progress element → Improve the default rendering of the progress element
(Assignee)

Comment 33

6 years ago
Created attachment 534409 [details] [diff] [review]
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?
Attachment #533599 - Attachment is obsolete: true
Attachment #533634 - Attachment is obsolete: true
Attachment #533637 - Attachment is obsolete: true
Attachment #534409 - Flags: review?(bolterbugz)
Comment on attachment 534409 [details] [diff] [review]
Patch to checkin

r=me. thanks for the ping.
Attachment #534409 - Flags: review?(bolterbugz) → review+
(Assignee)

Comment 35

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

Thanks :)
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla6

Comment 36

6 years ago
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

6 years ago
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
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.