Last Comment Bug 662251 - Default style and colors for the meter element
: Default style and colors for the meter element
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Layout: Form Controls (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla16
Assigned To: dularylaurent
:
Mentors:
Depends on: 687202 657953 660238
Blocks: 555985
  Show dependency treegraph
 
Reported: 2011-06-06 05:26 PDT by Yoan TEBOUL
Modified: 2012-06-06 06:21 PDT (History)
10 users (show)
mounir: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
tests_v1.0 (18.75 KB, patch)
2011-06-07 05:47 PDT, Yoan TEBOUL
no flags Details | Diff | Splinter Review
Patch v1.0 (914 bytes, patch)
2011-06-08 08:28 PDT, dularylaurent
no flags Details | Diff | Splinter Review
Tests v1.1 (17.12 KB, patch)
2011-06-08 11:41 PDT, dularylaurent
no flags Details | Diff | Splinter Review
Patch v1.0 (914 bytes, patch)
2011-06-08 11:43 PDT, dularylaurent
bzbarsky: review+
dbolter: review+
mounir: feedback+
Details | Diff | Splinter Review
Tests v1.1 (683 bytes, patch)
2011-06-08 11:44 PDT, dularylaurent
no flags Details | Diff | Splinter Review
Tests v1.1 (17.10 KB, patch)
2011-06-08 11:45 PDT, dularylaurent
mounir: feedback+
Details | Diff | Splinter Review
Tests v1.2 (17.94 KB, text/plain)
2011-06-09 07:53 PDT, dularylaurent
no flags Details
Chrome screenshot (with non-native rendering) (70.79 KB, image/tiff)
2011-06-15 03:44 PDT, Mounir Lamouri (:mounir)
no flags Details
Opera screenshot (96.47 KB, image/tiff)
2011-06-15 03:45 PDT, Mounir Lamouri (:mounir)
no flags Details
Chrome screenshot (with native rendering) (70.44 KB, image/tiff)
2011-06-15 03:47 PDT, Mounir Lamouri (:mounir)
no flags Details

Description Yoan TEBOUL 2011-06-06 05:26:27 PDT
User-Agent:       Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0
Build Identifier: 

We should have default colors to represent the differents states of this element (optimal, sub-optimal and sub-sub-optimal)

Reproducible: Always
Comment 1 Mounir Lamouri (:mounir) 2011-06-06 05:50:18 PDT
Like bug 644361, we want a correct default style for the meter element but the meter element isn't going to have a native style on GTK and maybe not on Windows so we are going to need something nice enough to be seen by most users.

I believe we should use hex colors and probably keep the same background color than the progress element and just have three different colors (green, orange, red) corresponding to the three states of the element.

Basically, that means removing the background-color property from "::-moz-meter-bar" rule and add three new rules:
:-moz-meter-optimum::-moz-meter-bar {
  background-color: green;
}
:-moz-meter-sub-optimum::-moz-meter-bar {
  background-color: orange;
}
:-moz-meter-sub-sub-optimum::-moz-meter-bar {
  background-color: red;
}
Comment 2 Mounir Lamouri (:mounir) 2011-06-06 05:54:45 PDT
Yoan, Vincent and Laurent, make sure to ask a review to David Bolter who is in charge of the accessibility for Mozilla: we want to be sure that the colors are not going to be hard to distinguish for visually impaired users.
Comment 3 Yoan TEBOUL 2011-06-07 05:47:08 PDT
Created attachment 537773 [details] [diff] [review]
tests_v1.0
Comment 4 dularylaurent 2011-06-08 08:28:20 PDT
Created attachment 538023 [details] [diff] [review]
Patch v1.0
Comment 5 dularylaurent 2011-06-08 11:41:44 PDT
Created attachment 538083 [details] [diff] [review]
Tests v1.1
Comment 6 dularylaurent 2011-06-08 11:43:16 PDT
Created attachment 538084 [details] [diff] [review]
Patch v1.0
Comment 7 dularylaurent 2011-06-08 11:44:00 PDT
Created attachment 538085 [details] [diff] [review]
Tests v1.1
Comment 8 dularylaurent 2011-06-08 11:45:02 PDT
Created attachment 538086 [details] [diff] [review]
Tests v1.1
Comment 9 Mounir Lamouri (:mounir) 2011-06-09 02:09:22 PDT
Comment on attachment 538084 [details] [diff] [review]
Patch v1.0

Review of attachment 538084 [details] [diff] [review]:
-----------------------------------------------------------------
Comment 10 Mounir Lamouri (:mounir) 2011-06-09 02:18:00 PDT
The default style here seems way more critic than with the progress element because there is no meter widget in GTK and Windows XP. We might be able to do one for Windows Vista and 7 but that would be a hack.
Webkit does use gradiants and the default style for the meter element is very close to the MacOS X native style. I don't know what Opera does but it's clearly not a simple background. Though, I don't really like using a gradiant because it might not be really intuitive to disable for authors (and a pain because you have to disable -{webkit,moz,o,}-gradiants). I just want to be sure that everyone is ok with that.
Comment 11 Mounir Lamouri (:mounir) 2011-06-09 02:25:47 PDT
Comment on attachment 538086 [details] [diff] [review]
Tests v1.1

Review of attachment 538086 [details] [diff] [review]:
-----------------------------------------------------------------

Instead of "colors", could you name the new directory "defaul-style". In addition, you have to add "include default-style/reftest.list" in meter/reftest.list.

Except that and the nit below, nice tests :)

::: layout/reftests/forms/meter/style.css
@@ +27,5 @@
> +  /* #00ae00 is green. */
> +  background-color: #00ae00;
> +}
> +
> +meter::-moz-meter-bar {

::-moz-meter-bar would be enough here. Though, it's for a test and it's correct so you don't really have to worry.
Comment 12 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-06-09 03:40:20 PDT
(In reply to comment #10)
> Webkit does use gradiants and the default style for the meter element is
> very close to the MacOS X native style. I don't know what Opera does but
> it's clearly not a simple background. Though, I don't really like using a
> gradiant because it might not be really intuitive to disable for authors
> (and a pain because you have to disable -{webkit,moz,o,}-gradiants). I just
> want to be sure that everyone is ok with that.

You don't disable gradients, since gradients aren't a property; you just set background:none, surely? That should be fine.
Comment 13 dularylaurent 2011-06-09 07:53:02 PDT
Created attachment 538259 [details]
Tests v1.2
Comment 14 David Bolter [:davidb] ***PTO until 29th*** 2011-06-09 12:59:04 PDT
Comment on attachment 538084 [details] [diff] [review]
Patch v1.0

This seems fine, but to serve all our users we should never just use only color to convey information. I need to know how the meter element is used in this context. Will it normally also have some other visual indication of state, like a needle on a dial?
Comment 15 Mounir Lamouri (:mounir) 2011-06-09 15:11:02 PDT
(In reply to comment #14)
> Comment on attachment 538084 [details] [diff] [review] [review]
> Patch v1.0
> 
> This seems fine, but to serve all our users we should never just use only
> color to convey information. I need to know how the meter element is used in
> this context. Will it normally also have some other visual indication of
> state, like a needle on a dial?

The meter element has two information: the value that is represented by the bar (like a progress bar) and the value "state" which can be optimum, sub-optimum or sub-sub-optimum and this is represented by a pseudo-class, thus, a color. There is no other indication of this state for the moment. Except exposing it trough the a11y API, I don't see any way to make it clearer: if a user can't distinguish the three colors, it might be hard to find something (the element is quite small).

I will probably update the patch to use gradiants tomorrow.
Comment 16 Boris Zbarsky [:bz] 2011-06-09 19:03:04 PDT
Comment on attachment 538084 [details] [diff] [review]
Patch v1.0

Modulo the choice of colors and whatnot, this seems ok (though in general those selectors would be bad; the saving grace is that they're for a particular pseudo-element).
Comment 17 Mounir Lamouri (:mounir) 2011-06-15 03:44:20 PDT
Created attachment 539470 [details]
Chrome screenshot (with non-native rendering)
Comment 18 Mounir Lamouri (:mounir) 2011-06-15 03:45:32 PDT
Created attachment 539471 [details]
Opera screenshot
Comment 19 Mounir Lamouri (:mounir) 2011-06-15 03:47:10 PDT
Created attachment 539472 [details]
Chrome screenshot (with native rendering)
Comment 20 Mounir Lamouri (:mounir) 2011-06-15 03:59:08 PDT
Chrome non-native rendering is, IMO, too close to the MacOS X native rendering and, in case of you wonder, it's not Mac-specific: with GTK, Chromium has the same rendering. Though, it is way better than what Opera does and what we could do with plain colors.

So, I think we should use gradients given that as said Roc, setting the background property disables the gradient (but not background-color unfortunately). However, I'm wondering if we should use something similar to Webkit/Chrome or try to make it less MacOS-like (by adding a border, for example). In one hand, I feel bad to make <meter> looks too close to what MacOS X does but in the other hand, it might be stupid to make it uglier just to not make it look likes MacOS X (even more given that GTK and Windows don't have a specific widget for that).

I don't think I'm the best person to solve this issue. Does someone know who I should talk with to solve it?
Comment 21 David Bolter [:davidb] ***PTO until 29th*** 2011-06-16 11:05:06 PDT
Steve, do we already have thinking on what the browser can do to ensure good meter element accessibility? Obviously using color-only to convey information is problematic, but here we also have position.
Comment 22 steve faulkner 2011-06-21 05:17:47 PDT
(In reply to comment #21)
> Steve, do we already have thinking on what the browser can do to ensure good
> meter element accessibility? Obviously using color-only to convey
> information is problematic, but here we also have position.

If i am reading the spec [1] and the coments above correctly (big if) the plan is to use color alone to signify the different states of "optimum".
If so then there are issues in regards to using color alone to convey information [2]. Unless there is some other *visible* means other than color that will differentiate the optimum levels. I have created an example of the issue for color blind users [3]

[1] http://dev.w3.org/html5/spec/the-button-element.html#attr-meter-optimum
[2]http://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-without-color
[3] http://www.html5accessibility.com/tests/progress.html
Comment 23 Henri Sivonen (:hsivonen) 2011-06-21 05:29:29 PDT
The optimum level could be marked as a groove perpendicular to the meter itself to avoid relying on color alone.
Comment 24 steve faulkner 2011-06-21 05:51:50 PDT
(In reply to comment #23)
> The optimum level could be marked as a groove perpendicular to the meter
> itself to avoid relying on color alone.

The usefulness and accessibility of meter would also be improved by providing  methods to indicate units and type.
take the example from spec:

<p>The grapefruit pie had a radius of 12cm and a height of
2cm.</p>
<dl>
 <dt>Radius: <dd> <meter min=0 max=20 value=12>12cm</meter>
 <dt>Height: <dd> <meter min=0 max=10 value=2>2cm</meter>
</dl>

If you view it in a browser that supports meter it provides ambiguous information as it is not clear what the units are or what the values are. It is unambiguous when meter is not supported. 

Alternatively the text content of the meter element could be displayed by default above/below the meter.
Comment 25 David Bolter [:davidb] ***PTO until 29th*** 2011-06-21 05:59:31 PDT
(In reply to comment #23)
> The optimum level could be marked as a groove perpendicular to the meter
> itself to avoid relying on color alone.

I like this idea.
Comment 26 David Bolter [:davidb] ***PTO until 29th*** 2011-06-21 07:46:05 PDT
(In reply to comment #22)
Thanks for this assessment Steve. I think given this assessment and possibly with Henri's idea we can fix this bug.

(In reply to comment #24)
Regarding the placement of text, we'll tackle how we handle the various examples of this on a separate bug.
Comment 27 steve faulkner 2011-06-21 08:18:00 PDT
(In reply to comment #25)
> (In reply to comment #23)
> > The optimum level could be marked as a groove perpendicular to the meter
> > itself to avoid relying on color alone.
> 
> I like this idea.

potential issue is that if optimum is not specified the optimum will be half way [1], how are users going to distnguish it from a simple indication of half way?

[1]http://dev.w3.org/html5/spec/the-button-element.html#attr-meter-optimum
Comment 28 Mounir Lamouri (:mounir) 2011-06-24 02:51:46 PDT
(In reply to comment #27)
> (In reply to comment #25)
> > (In reply to comment #23)
> > > The optimum level could be marked as a groove perpendicular to the meter
> > > itself to avoid relying on color alone.
> > 
> > I like this idea.
> 
> potential issue is that if optimum is not specified the optimum will be half
> way [1], how are users going to distnguish it from a simple indication of
> half way?

You mean that we should make the indication clear enough to be able to see the bar and the indication when they are at the same place? You could probably put two small arrows to point the optimal value? (or only one...)

I'm wondering if we should use that indication for native widgets? Should we assume that native widgets are already accessible or should we make them less native and more accessible by adding that?
Comment 29 David Bolter [:davidb] ***PTO until 29th*** 2011-07-14 18:30:21 PDT
I think native widget accessibility is owned by the native platform. I think tampering with trying to superimpose accessibility can be problematic, especially since we don't control updates to native widget a11y.
Comment 30 David Bolter [:davidb] ***PTO until 29th*** 2011-07-14 18:34:03 PDT
Mounir are you blocked on me?
Comment 31 Mounir Lamouri (:mounir) 2011-09-16 09:49:09 PDT
After thinking of different solutions, I think the best solution would be to indicate the low and high values instead of the optimum one. The idea is that the optimum value might be a wrong indicator especially when the optimum isn't explicitly set. Having a tick mark (like a small arrow) to point the low and high value will show the users there are some delimiters. With the context, it should be easy to understand if the value has to be higher than the high marker, lower or in the middle.

David, what do you think of this?

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