Re: [g-a-devel] new states for meter element

[Mario Sanchez Prada <mario prada samsung com>]

Hi all,

I know I‘m late to the discussion, but I would like to show my support for expanding the AtkValue interface. 
Furthermore, it’s not the first time I found a situation where having a more complete version of the AtkValue 
interface would be handy (see [1] and [2]), and this element seems like yet another reason to re-think 
extending it, and so doing what it seems to be the right thing ☺

> From the point of view of the implementation, it should not be an issue to expose those optimal, low and 
> high values in WebKit (besides adding some bits in WebCore’s a11y layer). The tricky thing will be of course 
> getting the textual representation of the value depending on the range it’s in. And regarding to this, I 
> personally think Joanie's first proposal (Bad, Better, Best) is better than the second one (Bad, Good, 
> Optimal), because anything out of "Optimal" doesn't have to be necessarily "good".

However, I still find it like kinda weird, and in a way I personally prefer the initial proposal of 
"optimal", "suboptimal" and "subsuboptimal", even if they don't seem to be very scalable. But I think they 
should probably be enough and hopefully, as Alex pointed out, this will probably be  avery specific 
requirement of the <meter> element.

Additionally, I also think the "optimal", "suboptimal" and "subsuboptimal" thing matches better with the 
specific situation of having the optimal subrange between [low] and [high]. According to the spec:

"""
UA requirements for regions of the gauge: If the optimum point is equal to the low boundary or the high 
boundary, or anywhere in between them, then the region between the low and high boundaries of the gauge must 
be treated as the optimum region, and the low and high parts, if any, must be treated as suboptimal.
"""

In that case, if you have a min < low < high < max range with low < optimal < high, you'll get this:

 - value < low => suboptimal
 - value > high => suboptimal
 - low < value < high => optimal

No subsuboptimal here. Also, using "suboptimal" is clearly better here, IMHO, than using "better" or "good" 
(from Joanie's proposal) here for the first too cases.

My 2 cents,
Mario

[1] https://bugs.webkit.org/show_bug.cgi?id=121477
[2] https://bugzilla.gnome.org/show_bug.cgi?id=684576