Warning:
This wiki has been archived and is now read-only.

ChangeProposals/removemeter

From HTML WG Wiki

< ChangeProposals

Jump to: navigation, search

Remove meter element

Summary

Remove the meter element.

1 Remove meter element

Rationale

The rationale given by the HTML5 editor[1] for keeping the meter element is:

Rationale: We have to have meter if we have progress because otherwise people will abuse progress to get gauges, leading to bad accessibility.

It's difficult to write a change proposal asking to remove the meter element, because there's so little justification for keeping it. That we need to have a meter element because people supposedly will use the progress element incorrectly means we either have not defined the progress element well enough, or we're trying to prevent people from using what seems to them to be the natural element to use.

The problem associated with the HTML5 meter element is that it is almost identical to the progress element: a long flat rectangle that has a minimum and maximum value and a current value, with the bar filled in up to that current value. However, if you search online on the term "gauge widget" almost all cases reflect a circular gauge, not a progress bar-like object.

Most gauge widgets online are also created from various libraries and toolkits, such as Google's Visualization API[2], the Dojo Toolkit Analog Gauge[3], or the Dojo Bar Gauge[4], which does have a bar-like image. All have a more sophisticated interface that what we could expect from a built-in HTML5 widget. In fact, the HTML5 built-in gauge could be created using one div nested in another, with a different color of background, and with a sized width equal to the gauge percentage.

As for the semantics and accessibility of the widget, I would imagine that the ARIA role of "progressbar"[5] and associated state values indicating the low and high values, and the current value, could be as usable for this type of bar gauge, as they would be for a progress bar. After all, the way to tell this type of bar gauge from a progress bar is the context of the use. In fact, the text description of the gauge that's recommended for the HTML5 meter element would also work for any of the gauge libraries.

Regardless, if the current ARIA progressbar role is not appropriate, or the text description is not sufficient, it's better to work with the WAI-ARIA folks to derive the appropriate role and states, because a gauge such as the HTML5 meter specification is no different than a gauge that can be created in something like SVG, or other graphical environment. The need for accessibility in a gauge does not end with just HTML.

Details

Based on the March 4th version of the HTML5 specification, remove Section 4.10.17 and Section 10.4.12, and any references to these sections and the meter element.

Impact

Positive Effects

Removing meter removes another element from the fairly large number of elements and attributes added with HTML5. In addition, it removes an element whose sole purpose and seemingly sole use case, is to ensure that another element was not used incorrectly. This, to me, is not a strong case for adding an element to HTML5, especially considering how much work each new element generates for browsers, HTML editors, and so on.

In addition, not creating a new element encourages people to use any number of the existing libraries and packaged widgets already available for use, and that have been available for use for many years. The meter element welds structure, behavior, and style into a single purposed element. Such single purposed elements are counter to the direction the web has been going for the last decade. Especially now, when we have so many new graphical possibilities, with the new support for SVG inline in HTML, and increased support for the Canvas element. It's better to encourage people to use existing graphical technologies such as CSS, SVG, and Canvas, and existing semantics and accessibility technologies, such as ARIA, RDFa, Microformats, and Microdata, and leave the structure to HTML.