Working Group Decision on ISSUE-97 meter

Question before the Working Group

The current HTML5 draft includes a meter element for the purpose of displaying a gauge or level indicator. Some working group members have questioned whether this use case needs to be satisfied by a dedicated element, or whether the meter element does so effectively.

The scope of this decision merely covers whether or not this functionality is required and provided effectively. A section below details what arguments were not considered, a number of which were not considered due to scope reasons.

Uncontested observations

These arguments were not decisive by themselves. There were people who supported either proposal, even after taking these facts into consideration.

Summary of Arguments


One area of disagreement was the issue of semantics. There was general agreement that semantic elements are beneficial and in particular lead to improved accessibility, but there was not total agreement on whether the meter element is semantic. Some argued that behavior is totally separate from semantics, and that semantics, behavior, and presentation should all be fully separated. Others argued that representing a specific type of interactive control is a semantic meaning. By this line of argument, meter represents the semantic of a gauge or level indicator, and these semantics are best expressed at the HTML layer, not via CSS and ARIA.

Examining the past history of HTML elements, it seems there are a number of interactive elements that are accepted as semantic. This includes both elements inherited from HTML4, such as the input element, and elements previously confirmed as part of HTML5 by Working Group decision, such as details.

Being "semantic" is not a sufficient argument to include an element in the language. However, there is evidence that the meter element is at least arguably semantic. Thus, the argument against meter on the basis that it is not semantic is not a strong objection.

Confusion with Progress

One argument in favor of the meter element is that it is needed to avoid misuse of the progress element. According to this line of argument, it is not appropriate to use a progress bar in place of a level indicator control. A progress bar should be reserved for indicating an amount of progress, not an arbitrary level.

Others say that this very argument shows meter is ill-conceived. If it is so easily confused with the progress element, then this is a sign that progress is defined incorrectly, and perhaps a single element should handle both use cases after all.

Some evidence was presented that a gauge or level indicator is considered a distinct control from a progress bar in HI design practice. Some native UI toolkits include it as a separate control, as do a number of JavaScript libraries.

Confusability alone does not seem like a strong objection to either including or omitting the meter element. Whether or not meter is considered distinct, its use case needs to be justified on its own terms.

Integrated vs. Modular

The key point of contention over the meter element can be seen as a conflict between integrated and modular approaches. Some argue that a single construct should encapsulate the semantics, behavior, presentation and accessibility aspects of a particular interactive control - an integrated approach. Others argue for a modular approach, where these aspects are kept separate. In general, most WG members accept the use case, but disagree on whether it should be addressed with an integrated approach or a modular approach.

A number of arguments were presented in favor of the integrated approach, and objecting to the modular approach. One argument is that the integrated approach makes things easier for authors. As a result, a built-in interface element would improve consistency and quality of Web applications, compared to the approach of leaving things entirely to content authors and JavaScript libraries. Built-in elements were also cited as better for authoring tools - when an authoring tool can understand the meaning of markup, it can deliver a better round-trip editing experience than when divergent script libraries do things their own way. A few more specific benefits were also cited. Integrated markup can reduce overall code size, and is more likely to survive syndication. The integrated approach also allows a platform-specific appearance as the default.

The modular approach was promoted as a matter of principle and good design - these arguments are covered in the section on semantics. Advocates for the modular approach object to the integrated approach on this basis. In addition, one specific benefit was cited. Authors often want a custom look for their UI controls, and the modular approach has a more obvious path to doing this. As a counter-argument though, it was mentioned that many existing controls are styleable with CSS, and this is an area of ongoing interest and development in the CSS WG.

On the whole, proponents of the integrated approach had stronger objections to removing the meter element. A significant set of benefits were cited which would be lost if meter was removed. Advocates of the modular approach had weaker objections. The main objections were based on interpretations of what is semantic. The one practical problem with the integrated approach seems addressable.

Decision of the Working Group

Therefore, the HTML Working Group hereby adopts the Change Proposal to retain the meter element in the language. Of the two Change Proposals before us, this one has drawn the weaker objections.

Bug 8555 is to be closed and marked as WGDecision.

Next Steps

Since the prevailing Change Proposal does not call for a spec change, no further actions are required.

Appealing this Decision

If anyone strongly disagrees with the content of the decision and would like to raise a Formal Objection, they may do so at this time. Formal Objections are reviewed by the Director in consultation with the Team. Ordinarily, Formal Objections are only reviewed as part of a transition request.

Revisiting this Issue

This issue can be reopened if new information comes up. Examples of possible relevant new information include:

Additionally, as details of this element's behavior were not in the scope of this issue, concrete suggestions for improvements, in the form of bug reports, continue to be welcome.

Arguments not considered

  1. Some argued that accessibility of the meter element has not been thoroughly verified, and that meter is unproven. However, no specific flaws were identified. To be considered, arguments must identify actual problems, not just the possibility of future problems. If problems are discovered in the future, they can be filed as individual bugs. If problems are found that are not fixable, they could potentially count as new information for reopening the issue.
  2. Some argued that the effects of meter being a form element (e.g., whether its value gets submitted) are unknown and unspecified. The scope of this issue is retaining or removing the meter element, not the quality of specification details. No specific proposal for improving the behavior of meter was put forward.
  3. It was claimed that there is no transition plan for how meter can be rolled out in new content while remaining compatible with older browsers. The general transition approach for new HTML5 elements has been outlined. No evidence was presented that it is insufficient, either generally or in the case of meter in particular.
  4. It was argued that the meter element currently lacks implementation in any browser or assistive technology, and that makes it too unproven to include in the language. This argument appears to be based on out-of-date information. The current implementation status is as follows: the meter element is implemented in the WebKit engine used by Chrome and Safari, among others.