Re: remove the meter element

On Fri, Jan 8, 2010 at 12:30 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> On Jan 8, 2010, at 12:13 PM, Jonas Sicking wrote:
>
>> On Fri, Jan 8, 2010 at 10:30 AM, Shelley Powers <shelley.just@gmail.com>
>> wrote:
>>>
>>> Ooops, sorry, I meant meter element!
>>>
>>> S
>>>
>>> On Fri, Jan 8, 2010 at 12:27 PM, Shelley Powers <shelley.just@gmail.com>
>>> wrote:
>>>>
>>>> I filed a bug, several weeks ago, on removing the details element:
>>>>
>>>> http://www.w3.org/Bugs/Public/show_bug.cgi?id=8555
>>>>
>>>> No decision has been made on this one.
>>>>
>>>> Shelley
>>
>> I disagree with this bug. I think having an element that can be used
>> to display a gauge-like graphic will be useful for authors and will
>> result in more semantic markup being used.
>>
>> However I really don't like the name "meter". It might be because i'm
>> english is my second language, but I associate the word "meter" much
>> more with the SI unit of length, than with a gauge-like instrument. I
>> unfortunately don't have a better name for it at this time as I agree
>> that "gauge" is probably too hard to spell.
>>
>> I do however think it's critical for CSS to enable the <meter> to be
>> styled such that it gives authors a lot of control of how it is
>> displayed. Possibly pseudo elements need to be introduced to select
>> the "full" and "empty" parts of the meter.
>>
>> I do however think it would be interesting if we could merge
>> <progressbar> with <meter>. After all, a <progressbar> is just a
>> specific instance of a <meter>. Usually where the maximum is 100. This
>> would also remove concern that people would use <progressbar> where
>> <meter> should be used and the other way around. Suggestions to this
>> effect would be very welcome to me.
>
> At least on Mac OS X, the native controls equivalent to <progress> and
> <meter> are different controls with totally different native appearances and
> APIs.

I'm aware of that, though I think it's always useful to pursue
improvements in HTML, even though they haven't been done elsewhere.

> I also believe the elements as currently defined have some distinctive
> properties. <progress> can be indeterminate, while <meter> cannot. <meter>
> has the ability to indicate positions on the gauge that are low, high, or
> "optimum".

I was aware of the indeterminate state for <progress>, but not of the
high/low/optimum for <meter>. I agree that this further increases the
difference between the two elements.

> I note also that they have somewhat different semantics. A
> <progress> element is nearly always constantly changing until it finishes;
> if it's static or stays still for a very long time, then you are doing it
> wrong. A <meter>, though, is very likely to indicate a static level that is
> likely to stay steady for a long time until a user action our outside events
> cause it to change.

I can't really say that I agree that just because one is changing and
the other is not, that that meaningfully makes their semantics
different. One example of a more or less static <progress> is a
multi-page questionnaire, where each page shows at the top shows how
much progress you've made through the questionnaire. Such an element
would not change on any given page.

For the record, since I haven't been able to come up with a better
proposal than the current (and obviously neither was the designers of
the native OSX control set), I do not object to what the spec says
now.

/ Jonas

Received on Friday, 8 January 2010 21:40:59 UTC