Just because you can doesn't mean you should: the <meter> element

Original Article ↗ Hacker News Discussion ↗

HTML’s `<meter>` element is intended as a semantic way to represent scalar values within a known range (like fuel level or CPU usage), but developers argue it’s often misunderstood, poorly exemplified in documentation, and hard to style consistently across browsers. Commenters debate when meters are preferable to raw numbers or progress bars, how semantics affect accessibility tools like screen readers, and whether HTML should prioritize strict meaning or flexible UI behavior. Many conclude that `<meter>` can be useful when paired with visible numeric values and clear context, but that current guidance and browser support make it easy to misuse.

Scope and semantics of <meter>

  • Many see <meter> as useful when conveying a value within a known range plus thresholds (min/max, low/high, optimum), e.g., fuel level, temperature zones, machinery gauges, character stats, polls, or microphone level.
  • <progress> is viewed as specialized: a task moving toward completion, sometimes indeterminate, mostly moving forward. <meter> is for arbitrary metrics that can move up and down.
  • Several argue that MDN’s oven-temperature and exam-score examples misuse <meter> by replacing clear numeric text with ambiguous bars.

Semantic HTML vs functionality

  • One line of argument: HTML elements bind function (“what it does”) to semantics (“what it’s for”), causing misuse when devs want the behavior but not the meaning.
  • Suggestions include an attribute to signal “off-label” use or flipping the default so raw functionality is default and semantics require opt-in.
  • Others stress that semantic elements are defined precisely by their intended meaning, not by visual behavior.

Accessibility and ARIA

  • <meter> is framed as largely an accessibility feature; without it, devs would approximate with styled images or <div>s, which are less meaningful to assistive tech.
  • ARIA role="meter" is proposed as an alternative that retains semantics while allowing full custom styling.
  • Some caution that less common semantic tags can expose browser/screen-reader bugs and inconsistencies.

Styling and implementation pain

  • Multiple comments describe <meter>/<progress> styling as a “nightmare”: non-standard, vendor-prefixed pseudo-elements, conflicting behaviors across browsers.
  • The inability to apply pseudo-elements like ::before to replaced elements is criticized as blocking simple enhancements (e.g., showing numeric value via CSS).

Meters vs numeric displays in UI design

  • Long subthread debates analog gauges vs numeric readouts (cars, fuel, tachometer, disks, CPU/RAM):
    • Pro-gauge: quick peripheral scanning, clear thresholds (green/red zones), sense of rate-of-change, good for “is this OK?” checks.
    • Pro-number: precise, direct comparison to numeric limits (e.g., speed limit), quicker for some people to parse, especially those more used to numbers than analog dials.
    • Many advocate combined displays (gauge + number) and user customization; some note neurodiversity and that not all brains process visuals the same way.

HTML semantics in a UI-heavy web

  • One commenter questions whether HTML can be “semantic” when the web is largely GUI, not hypertext.
  • Replies argue that semantics still matter: headings, links, buttons, and roles define structure and behavior, enabling keyboard navigation and assistive tech.
  • ARIA roles and attributes are cited as a way to layer explicit semantics on top of UI components.

Standards and complexity

  • A critical note suggests proliferating elements like <meter> contribute to huge, complex specs that only large companies can realistically implement, reinforcing browser monopolies.

Overall sentiment

  • Broad agreement that the MDN example was poor, not that <meter> is inherently bad.
  • Many favor using <meter> alongside a visible numeric value, rather than choosing between bar and number.