Closed Bug 644361 Opened 10 years ago Closed 10 years ago

Improve the default rendering of the progress element

Categories

(Core :: Layout: Form Controls, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla6

People

(Reporter: mounir, Assigned: mounir)

References

Details

Attachments

(2 files, 4 obsolete files)

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...
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.
(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).
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.
Attached image Current rendering
(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?
Attached patch Blue bar (obsolete) — Splinter Review
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)
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)
Whiteboard: [needs review]
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 on attachment 532647 [details] [diff] [review]
Blue bar

I really meant Boris...
Attachment #532647 - Flags: review?(roc) → review?(bzbarsky)
(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.
(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.
(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.
Attachment #532647 - Flags: review?(bolterbugz)
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.
(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.
Attached patch With Highlight and Background (obsolete) — Splinter Review
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)
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?
(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.
Attached patch With Blue and LightGray (obsolete) — Splinter Review
Attachment #533634 - Flags: review?(bzbarsky)
Attachment #533634 - Flags: review?(bolterbugz)
Attached patch With ButtonText and ButtonFace (obsolete) — Splinter Review
I think we have to take one of these three patches or mark the bug WONTFIX.
Attachment #533637 - Flags: review?(bzbarsky)
Attachment #533637 - Flags: review?(bolterbugz)
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+
Attachment #533599 - Flags: review?(bzbarsky)
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.
(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.
Summary: Have a nice default rendering for the progress element → Improve the default rendering of the progress element
Attached patch Patch to checkinSplinter Review
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+
Pushed:
http://hg.mozilla.org/mozilla-central/rev/85a96ef690b4

Thanks :)
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla6
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
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.