This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 8555 - Remove the Meter Element
Summary: Remove the Meter Element
Status: CLOSED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: Macintosh Mac System 9.x
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: NE, WGDecision
Depends on:
Blocks:
 
Reported: 2009-12-27 00:03 UTC by Shelley Powers
Modified: 2010-12-08 03:56 UTC (History)
7 users (show)

See Also:


Attachments

Description Shelley Powers 2009-12-27 00:03:11 UTC
Evidently, the meter element came about primarily so that people don't use the Progress element incorrectly[1]. This seems a poor reason to create a new element. Either the Progress element needs to have a better definition in the spec, to prevent incorrect use, or the progress element is so confusing or is so capable of being misunderstood, it should be pulled from the spec, altogether.

Regardless of what happens with Progress, there seems little use case, interest, or need for the meter element.

The meter element is supposedly acting as some form of static gauge, but there's no way to associate exactly what it is that's being gauged, with the gauge value. There is no way to specifically tie the value contained in the meter element with the object, in such a way that the information can be useful for web bots or other user agents. In addition, it's not particularly useful for accessibility reasons, when text within a span element would be just as useful, and just as viable. 

As for a graphical display, it's just as simple to provide an image, or use CSS, SVG, or Canvas, with the associated fall back defined for each. Regardless, there is little instruction about how the element is displayed, which adds to the general confusion about what the element is, and how it should be supported. 

Even the graphical example about half way through the section, showing Usenet subscriptions, doesn't really add much information. One can see that 618 subscribers is significantly more than 22, just by reading the numbers--one doesn't to see a picture to comprehend the difference. On the contrary, without understanding why there seems to be an upper range, the gauge doesn't mean a lot. Is the upper range a Usenet limit? The largest Usenet membership? Some arbitrary number picked so one can have a cool picture? 

In addition, the section mixes instructions for authors and user agents, HTML editing and parsing in a confusing mish-mash of instructions, compounded by a list of confusing rules about the interaction of the element's attributes and values. One can almost guarantee that this element will be used incorrectly, and most likely implemented incorrectly. 

[1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/021931.html
Comment 1 Maciej Stachowiak 2009-12-27 02:17:38 UTC
(In reply to comment #0)
> Evidently, the meter element came about primarily so that people don't use the
> Progress element incorrectly[1]. This seems a poor reason to create a new
> element. Either the Progress element needs to have a better definition in the
> spec, to prevent incorrect use, or the progress element is so confusing or is
> so capable of being misunderstood, it should be pulled from the spec,
> altogether.
> 
> Regardless of what happens with Progress, there seems little use case,
> interest, or need for the meter element.

Here are a few real-life uses that would match the semantics and behavior of the <meter> element:

1) On Mac OS X Mail, if you do an "Entire Message" search, the Rank column shows a meter indicating quality of the result (on an arbitrary scale). It would be poor UI to show a number here, as the numeric value is irrelevant.

2) Many sites or applications that deal with music, movies, television shows, books, or other media, show ratings on a 5-star scale and prefer to display this visually instead of numerically. (<meter> would have to support very specific custom styling to make this work right).

3) Applications dealing with audio input or playback often have a meter showing the current sound level. GarageBand on Mac OS X is an example, it uses this both for audio input and for mixed down playback.

It's probably somewhat less common than progress indicators but not significantly less common than, say, color pickers (which are served with <input type="color">). Note: the Cocoa toolkit on Mac OS X has a specific control for this purpose, NSLevelIndicator. This is at least partial evidence that this is a reasonably common UI idiom.

> The meter element is supposedly acting as some form of static gauge, but
> there's no way to associate exactly what it is that's being gauged, with the
> gauge value. There is no way to specifically tie the value contained in the
> meter element with the object, in such a way that the information can be useful
> for web bots or other user agents

The primary use case for this element is to convey information to the user, any value to Web bots is secondary. However, a <meter> element could be marked up with Microdata or RDFa to relate its value to rich semantic information in the page.

> In addition, it's not particularly useful for accessibility reasons, when text within a
> span element would be just as useful, and just as viable. 

In the use cases cited above, I do not think displaying text to the user would be a better overall UI design choice.

> As for a graphical display, it's just as simple to provide an image, or use
> CSS, SVG, or Canvas, with the associated fall back defined for each.

To some extent, this is true of almost any UI control. Obviously HTML5 cannot have direct built-in support for every conceivable control. But it should try to cover more of the most common ones than HTML4 did, in addition to giving you the tools to build new custom controls.

> Regardless, there is little instruction about how the element is displayed,
> which adds to the general confusion about what the element is, and how it
> should be supported. 

There is extensive information about the element's expected rendering here:
http://dev.w3.org/html5/spec/Overview.html#the-meter-element-0

Comment 2 Leif Halvard Silli 2009-12-27 13:10:16 UTC
(In reply to comment #0)
...
> Even the graphical example about half way through the section, showing Usenet
> subscriptions, doesn't really add much information. One can see that 618
> subscribers is significantly more than 22, just by reading the numbers--one
> doesn't to see a picture to comprehend the difference. On the contrary, without
> understanding why there seems to be an upper range, the gauge doesn't mean a
> lot. Is the upper range a Usenet limit? The largest Usenet membership? Some
> arbitrary number picked so one can have a cool picture? 
...

It might be that there could be reasons to question the "<meter>" element. However, with regard to the Usenet example,  then its code example looks like this:

<p><meter value="0.5">Moderate activity,</meter> Usenet, 618 subscribers</p>

I could be wrong, but based on the code, it seems to me that the "moderate activity" here is not related to the numbers of subscribers but to the amount of activity within the group. Clearly, the activity level, is nothing more than the amount of postings withing a certain time frame.  (Thus the activity could have been measured and presented in numbers.)  The activity level is related to the amount of subscribers, probably, but not necessarily one-to-one. There could be many members but little activity.

One could however, in my view, imagine that <meter> could be used to indicate if a group had few, on average or many members - if such a presentation would be useful for the readers.

I agree that the example however is a bit unclear: When I look at the activity meter then there is no way that I can know what it tries to tell me, as it lacks any  caption saying "Activity level last week" - or something like that.
Comment 3 Shelley Powers 2009-12-27 21:10:34 UTC
(In reply to comment #2)
> (In reply to comment #0)
> ...
> > Even the graphical example about half way through the section, showing Usenet
> > subscriptions, doesn't really add much information. One can see that 618
> > subscribers is significantly more than 22, just by reading the numbers--one
> > doesn't to see a picture to comprehend the difference. On the contrary, without
> > understanding why there seems to be an upper range, the gauge doesn't mean a
> > lot. Is the upper range a Usenet limit? The largest Usenet membership? Some
> > arbitrary number picked so one can have a cool picture? 
> ...
> 
> It might be that there could be reasons to question the "<meter>" element.
> However, with regard to the Usenet example,  then its code example looks like
> this:
> 
> <p><meter value="0.5">Moderate activity,</meter> Usenet, 618 subscribers</p>
> 
> I could be wrong, but based on the code, it seems to me that the "moderate
> activity" here is not related to the numbers of subscribers but to the amount
> of activity within the group. Clearly, the activity level, is nothing more than
> the amount of postings withing a certain time frame.  (Thus the activity could
> have been measured and presented in numbers.)  The activity level is related to
> the amount of subscribers, probably, but not necessarily one-to-one. There
> could be many members but little activity.
> 

Thanks for clarification. I assumed there was a correlation between the text value next to the graphic and the graphic, but as you say, there may not be any correlation at all. However, without any indicator of gauge values, the gauge is inherently worthless. It would be clearer just to write out the text: moderator activity, light, or heavy. 

> One could however, in my view, imagine that <meter> could be used to indicate
> if a group had few, on average or many members - if such a presentation would
> be useful for the readers.
> 
> I agree that the example however is a bit unclear: When I look at the activity
> meter then there is no way that I can know what it tries to tell me, as it
> lacks any  caption saying "Activity level last week" - or something like that.
> 

Frankly, I just can't see much value with the meter. In gauges, and in many progress bars, end point values are printed as well as the graphic. And, as you say, there's a caption for the graphic, indicating exactly what the gauge is for. 

Regardless, there's nothing about meter that can't be as easily indicated using existing technologies, such as ARIA, RDFa, PNGs, SVG, CSS, and/or existing HTML elements.  And in fact, using existing technologies would most likely do a superior job. 

The section reflects the author's interest in the element, which is not particularly strong (as noted in his email I referenced.)
Comment 4 Shelley Powers 2009-12-27 21:11:26 UTC
Sorry, moderate activity, not moderator activity. 
Comment 5 Ian 'Hixie' Hickson 2010-01-11 04:44:21 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: We have to have <meter> if we have <progress> because otherwise people will abuse <progress> to get gauges, leading to bad accessibility.
Comment 6 Shelley Powers 2010-01-11 15:49:00 UTC
(In reply to comment #5)
> EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
> satisfied with this response, please change the state of this bug to CLOSED. If
> you have additional information and would like the editor to reconsider, please
> reopen this bug. If you would like to escalate the issue to the full HTML
> Working Group, please add the TrackerRequest keyword to this bug, and suggest
> title and text for the tracker issue; or you may create a tracker issue
> yourself, if you are able to do so. For more details, see this document:
>    http://dev.w3.org/html5/decision-policy/decision-policy.html
> 
> Status: Rejected
> Change Description: no spec change
> Rationale: We have to have <meter> if we have <progress> because otherwise
> people will abuse <progress> to get gauges, leading to bad accessibility.
> 

I would say, then, that progress is badly designed, and both should be discarded.

Tracker Issue 97

http://www.w3.org/html/wg/tracker/issues/97
Comment 7 Maciej Stachowiak 2010-12-08 03:56:57 UTC
Resolved by WG decision.