Hacker News Reader

Comment by mcv | Hacker News Reader

My first reaction seeing the oven example is: why does this element even exist? That example looks just like a progress bar. Why not use a progress bar.

Fortunately the specs make it look a lot more useful: part from min and max, you can also specify high and low ranges, and what the optimal value is.

So this is useful for all sorts of gauges about machinery: is the fuel tank full or empty? How is the pressure in a tank? How fast is the engine going? It's for situations where high/low, full/empty is more important than exact values. It's useless for specifying the temperature you need to set the oven at, but it would be useful for reporting how close to that temperature the oven currently is.

It would be nice if you could style it in different ways, like different kinds of gauges, and possibly also with numbers for various ranges. I have no idea if that's supported.

View on HN

Progress bars and meters are semantically very different even if visually they look very similar. If you have used 30% of your storage space you aren't 30% done filling your storage. (Well kinda, but you probably delete things occasionally and it isn't quite right.) Or if your GPU is at its maximum operating temperature and thermal throttling it isn't 100% done heating up.

Basically many meters don't really represent progress. Maybe it could have been one element with `type=progress` or `type=scale` or similar. But at least for screen readers I can imagine that they would want to differentiate them. I imagine that the default styling may also be different, for a progress bar you may want some sort of throbbing effect to show that something is working while for a meter that typically wouldn't make sense.

> why does this element even exist?

The deliberate explosion of the specs required to build a browser ensuring that Google has a permanent quasi-monopoly because the size of the specs outstrips all but a handful of company's ability to fund implementation.

Some HN poster shared a link that I can't find that counted the words of the browser specs. I seem to remember it being in the low hundreds of millions. Hundreds of millions of words of spec to implement a browser. It's a piece of software engineering comparable in effort to a full OS.

edit: my bad. 1,217 w3c specifications comprising 114 million words. https://drewdevault.com/2020/03/18/Reckless-limitless-scope.... So not plural, but outside of the scope of any company that can't afford to spend probably $10B on a product you can't charge for.

I have used <meter> in the past for polls, too (see https://jamesg.blog/poll/).

<meter> is nice when you want to illustrate the extent of a scale, but in many scenarios one should _also_ show the exact value represented, numerically (i.e. my poll shows both the <meter>, more for illustration, and the number of votes).

<meter> seems extremely useful for SCADA UI's, many of which are migrating to HTML5. They mostly perfectly fit the paradigm that would otherwise be custom-built.

> It would be nice if you could style it in different ways

I think a big part of the problem here boils down to much of the thinking behind specs being accessibility=screen-readers, rather than considering accessibility in terms of UX for a broader range of visitors (most using just a normal browser).

In this case, the fact that things like pseudo-elements explicitly don't work on replaced elements, even elements that have nested content such as <meter> and <picture>, is a really weird oversight in my mind. It seems to be justified by an overly prescriptive view of how DOM object models should be visualised, rather than a prescriptive view of how web content should be most helpfully rendered.

TL;DR The problem in this article could easily be solved by a simple meter::before { content: attr(value); } except that the spec. explicitly forbids that, so it does nothing.

Reply on news.ycombinator.com