W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > December 2009

[Bug 8555] Remove the Meter Element

From: <bugzilla@wiggum.w3.org>
Date: Sun, 27 Dec 2009 02:17:39 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1NOihP-00010M-60@wiggum.w3.org>

--- Comment #1 from Maciej Stachowiak <mjs@apple.com>  2009-12-27 02:17:38 ---
(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

> 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:

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Sunday, 27 December 2009 02:17:40 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:30:43 UTC