11 ms·

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

151 points by butz 3y ago

Lerc 3y ago
I think the fundamental problem with semantic web content is that it is binding two things together. 1. This feature does X 2. This feature is for Y Misuse happens when people want the functionality for another purpose. I have seen some attitudes that are strongly against doing this even going back to the days of WinAmp where people were arguing passionately that custom user interfaces like that should not be permitted. On the other hand lots (I would guess millions) Opted for WinAmp precisely because of it's UI customization. It wasn't for everybody, but optional things do not need to be for everybody. Binding what an element does to what it is for pollutes the semantic space whenever someone wants the functionality for another purpose. They end up with a feature that does one thing and broadcasts that it is supposed to be doing something else. Perhaps an attribute could assist in this area (perhaps offlabel or something similar or more appropriate) <meter min="0" max="250" value="180" offlabel>???</meter> To indicate that that an element performs functionally like a meter, without any semantic assumptions. Given the greater degree of awareness that a developer should have when developing accessible content. I think it would be better to have the default to be the raw functionality and an attribute to indicate that the semantic context is valid. I don't believe that proponents of the semantic web would go for that, because not enough people would opt-in. They would prefer opt-out or no option at all.
- wodenokoto 3y ago
  The core concept of semantic web is that a “feature” _doesnt_ correspond to a behavior. You can’t use emphasis to show italics, because it is used for emphasis- not a specific type of emphasis. And you as the author of a semantic HTML document don’t know how emphasis will work on the final users rendering.
  - simongray 3y ago
    I just wanted to point out that both you and the one you're replying to keep writing "semantic web", but I think what you really mean is "semantic HTML". The semantic web is the umbrella term for the stack of technologies that include RDF, SPARQL, OWL, etc. — it doesn't really have anything to do with HTML, other than some special syntax for embedding RDF into HTML.
    - wodenokoto 3y ago
      You are right that parent and grandparent should have used semantic HTML instead of web. But I’m not sure I agree on your definition either. Looking at Wikipedia, semantic web is described, first as Web 3.0 (not to be confused with web3) but I remember it more as a dream of late 90s early 2000, where all data lived on internet accessible urls and had semantic markup, than a tech stack.
      - simongray 3y ago
        Well, it's a pretty concrete tech stack these days even if the original vision didn't take off. I actually use these technologies in my day job (and have been for several years), so it's not just a wikipedia look-up for me. Maybe that's why I think of it in more concrete terms.
      - Lerc 3y ago
        >Web 3.0 (not to be confused with web3) I find this distinction to be rather ridiculous. They both semantically(heh) proclaim to be the next version of the web. I see there's a bit of an edit war on https://en.wikipedia.org/wiki/Semantic_Web https://en.wikipedia.org/wiki/Semantic_Web over the one true web 3. It's just an arbitrary name where people have incremented a number for something they wanted to be the next big thing. Realistically I think you could only really numerically name the next thing after it has actually successfully been adopted.
    - Lerc 3y ago
      I had pretty much forgotten most of those things had existed. I see someone has sneakily added ActivityPub to the end of the list on wikipedia in 2021, retroactively giving them a success. I assume there are pockets of existence for these things but for the most part the only time the majority of people encounter anything under the semantic web umbrella is where it has influenced html. It's a tomato is a fruit or vegetable thing, it is technically fruit but to most people it is effectively a vegetable.
- pjc50 3y ago
  This is the is/ought distinction again, isn't it. > I have seen some attitudes that are strongly against doing this even going back to the days of WinAmp where people were arguing passionately that custom user interfaces like that should not be permitted. On the other hand lots (I would guess millions) Opted for WinAmp precisely because of it's UI customization. It wasn't for everybody, but optional things do not need to be for everybody. This really needs to be printed out and displayed on a billboard. The existence of options, and other people making choices, is not a threat. There needs to be space for nonfunctional whimsicality. A music player is a good place for it. An aircraft console is probably not a good place for it.
readthenotes1 3y ago
I love the headline! (It is the end of adolescence - - when you realize that just because you can doesn't mean you should...)
yetanother12345 3y ago
Try styling it (CSS). I've been there. One more reason not to use it.
- patates 3y ago
  The ARIA role has the same semantic ability and full customizability: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/meter_role https://developer.mozilla.org/en-US/docs/Web/Accessibility/A... Perhaps it would make sense to use this instead of the element, but not sure if there are any downsides?
- yreg 3y ago
  Why? We haven't had much of a problem styling our. https://i.imgur.com/vrHD9np.png https://i.imgur.com/vrHD9np.png
- CM30 3y ago
  Ah, I remember doing this all too well. Or at least, with the very similar <meter> element anyway. God it was a nightmare. There was no standardised selector for various parts of the bar, so I had to use a bunch of awkward -webkit and -moz prefixed ones that weren't consistent at all. The values for these were in at least one case contradictory, so the value for one part of the bar had to be assigned to one pseudo element in Chrome and the opposite one in Firefox, and getting the thing to work as expected in Safari was as awkward as you could imagine, despite all the documentation saying it'd use the same styles as Chrome. They really need to standardise the selectors and styles for these things already...
rendall 3y ago
On Firefox anyway, I was surprised to see that the <meter> element does not have a tooltip to show the value.
- LoganDark 3y ago
  Same on Chromium.
- atoav 3y ago
  Maybe if a titlw attribute is added?
  - rzzzt 3y ago
    That does seem to work.
ZiiS 3y ago
A better example is fuel level. Using numbers would be distracting and imply more accuracy then is probably available.
- Dalewyn 3y ago
  I actually detest meters in cars and wish they would all be abolished in favor of number displays. No, I don't find the speedometer with a needle vaguely pointing somewhere easier/faster to read than a simple readout that says 40mph or whatever my speed is. No, I don't find the fuel gauge easier/faster to read, just give me that in percentage numbers. Of course, I know why meters are the go-to in car dashboard indicators: Cars hail from an era when we didn't have an easy way of dynamically printing numbers on a slab of metal or plastic yet. But we're in the 21st century. LCD screens are everywhere around us. Just give me the fucking numbers, I can read them faster than I can discern your arbitrary needles and scratch lines. And just so I'm clear in my consistency: I also hate gauges and pie charts for HDD/SSD space usage, CPU usage, RAM usage, and so on. If it can be expressed in numbers, give me the numbers. I can read them faster than I can discern arbitrary squiggles screaming across other arbitrary squiggles. Gauges and meters are strictly for when displaying dynamic numbers is impractical or impossible.
  - ZiiS 3y ago
    A speedometer is accurate to sub-mph. If you are just below the limit, it is helpful to know if you are still creeping up etc. A purely numerical display is either too course or changes too frequently to read. Many cars already have a slower changing numerical MPH readout inside the meter, so hopeful we can both be happy.
  - omeid2 3y ago
    While reading individual metrics might be easier with numbers, with gauges you can scan the whole system at low precision very quickly. It is also easier to just see "fuel red", "temperature normal" than 12.5L or 89.5C.
    - Dalewyn 3y ago
mjburgess 3y ago
Can anyone explain how HTML/CSS/etc. can be "semantic" at the syntax layer when it is largely a means of specifying a UI? The era when HTML was a markup for text documents is gone -- what sense is there in supposing it can be 'semantic' ?
- atoav 3y ago
  A h1 is still likely a heading, a meter is some value and a div could be everything. This is semantic. The opposite of semantic would be having all divs and using them for everything.
- froddd 3y ago
  Every element has a function or hierarchy in the document. The ‘semantic’ association helps define that role. This is useful for technologies that rely on something else than the visual output of the document, for instance, screen readers. As an example, a heading might contain the content: “A brief summary”. Without a semantic role, this does not convey the hierarchical position of that element within the document. Using the correct tag (in this case, `h{1|2…}` does provide this extra information and helps provide structure to the document.
  - mjburgess 3y ago
    I suspect tag names are not the right place for screen readers to be getting that information. The web isnt hypertext any more, it's hypogui. If we defined a "WebGUI Markup Language" it could be a requirement that all UI elements have semantic attributes, etc., eg., <Text type="heading" purpose="page title"> My Web Page </Text> It just seems we're hobbled by this 1992 idea that the web is wikipedia, and our markup languages should be foremost about how text documents are described.
    - notpushkin 3y ago
      https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles https://developer.mozilla.org/en-US/docs/Web/Accessibility/A... seems to be close to what you want.
forgotusername6 3y ago
Current microphone level is a pretty sound usecase
- iforgotpassword 3y ago
  Showing the density of some mass would be pretty solid.
  - skibz 3y ago
    Displaying the temperature of something might be cool.
    - TonyTrapp 3y ago
      You guys win the internet for today. Especially since we got forgotusername6 and iforgotpassword to collaborate in this thread. Only missing a contribution from forgetemailaddress42...
      - GreenWatermelon 3y ago
        I'm here just like "A pun thread? On HN?" Very rare for one of those to stay alive around here. Has yo be because they provide good examples.
    - deleted 3y ago
      [deleted]
    - hunter2_ 3y ago
      Displaying hit points of a game character would be the bomb (alternatively: health points would be sick).
  - TOGoS 3y ago
    Zero on the left and....neutron star density on the right?
asimpletune 3y ago
I didn’t actually understand the author’s problem, and if you read the mdm article they go into more detail. Seems pretty useful actually. I would use meter to represent a character’s stats. There’s even an “optimum” attribute, so you can include their oxygen concentration levels, if they’re extraterrestrial.
- madeofpalk 3y ago
  The authors problem is just that MDN had a poor example. It was unclear what temperature the oven should be set to. It's just a silly, unforced error.
- Karliss 3y ago
  The element itself isn't an issue. It's that 2/3 examples on MDN are awful, you shouldn't use the meter tag as substitute for a number in a middle of sentence. "Heat an oven to <green progressbar>" or "He got <red almost full progressbar> on the exam". It's largely an accessibility feature, since just for displaying purpose similar effect could be achieved using one or few images and appropriate styling options. Having a dedicated tag with additional metadata, potentially allows blind readers to better understand what was meant compared to "x px wide image". Ironic that the examples of accessibility feature demonstrate usage which would make the page less accessible to most of the users.
  - asimpletune 3y ago
    O yeah, that is not easy to understand at all.
zarzavat 3y ago
> While <progress> is fairly self-explanatory – it shows how far along something is, such as your progress through a form My understanding is that this is incorrect. <progress> is for a progress bar, such as downloading a file, or a loading screen. <meter> is for showing a value in linear space. The progress through a form is a value in linear space, not a task that the user is waiting for. Their progress can go forward and back. The user is in control of the value. Therefore <meter> is the correct element. Is the element there to keep the user amused while they are waiting for something? Could it conceivably be styled so as to include a waiting animation? Does it only ever move forwards and never backwards? If yes, then it's a <progress>, if no then it's a <meter>.
- oniony 3y ago
  Downloading a file or a loading screen is also a value in linear space. The only difference, in my mind, is that: • Progress is expected to go upwards as the underlying task is completed. It can, however, stall on a value or it can reset back to zero if the task fails and is restarted. But in the normal, common case, the trend is upwards towards completion. • Meters reflect the current value of some metric and so can go up and down as the underlying value changes through time, e.g. room temperature, or disk space used of a disk space quota. You could use a meter to indicates progress. As such, I think progress is a specialised meter, where we don't care so much about the underlying value, just that we're working steadily towards the goal.
  - zarzavat 3y ago
    Here's one counter example: Progress indicators can be indeterminate, when the duration of the task is unknown but you still want to communicate to the user that something is happening. You can make an indeterminate <progress> by not specifying a value attribute, and then styling it with the :indeterminate pseudoclass (TIL). It's well worth it to read the Apple Human Interface Guidelines, even if you don't develop for Apple platforms, they have some good universal UI advice: Progress indicators: https://developer.apple.com/design/human-interface-guidelines/progress-indicators https://developer.apple.com/design/human-interface-guideline... Gauges: https://developer.apple.com/design/human-interface-guidelines/gauges https://developer.apple.com/design/human-interface-guideline...
e_y_ 3y ago
In general, using semantic tags like <meter> and <progress> instead of a div has to be done carefully because browsers and screen readers often have bugs and inconsistencies especially for less commonly used tags (and even for widely used tags)
- diggan 3y ago
  If only there was a library that could abstract over those differences and provide a unified API, feel and look so I can write code that I know works and looks exactly the same in all browsers.
mcv 3y ago
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.
- zerojames 3y ago
  I have used <meter> in the past for polls, too (see https://jamesg.blog/poll/ 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).
- kevincox 3y ago
  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.
- lucideer 3y ago
  > 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.
ericyd 3y ago
Kind of a weird stance, it seems like the author is arguing for a div simply because of one bad MDN example. I don't see any downside to using a meter and a visible numerical value together, which I'm sure is the intended purpose.
User3456335 3y ago
This is just one bad example that wasn't even in a real application. Someone just tried to think of an example, happened to look at his oven and quickly wrote something down. The article then attacks this strawman example.

151 points by butz 3y ago

Lerc 3y ago

I think the fundamental problem with semantic web content is that it is binding two things together. 1. This feature does X 2. This feature is for Y Misuse happens when people want the functionality for another purpose. I have seen some attitudes that are strongly against doing this even going back to the days of WinAmp where people were arguing passionately that custom user interfaces like that should not be permitted. On the other hand lots (I would guess millions) Opted for WinAmp precisely because of it's UI customization. It wasn't for everybody, but optional things do not need to be for everybody. Binding what an element does to what it is for pollutes the semantic space whenever someone wants the functionality for another purpose. They end up with a feature that does one thing and broadcasts that it is supposed to be doing something else. Perhaps an attribute could assist in this area (perhaps offlabel or something similar or more appropriate) <meter min="0" max="250" value="180" offlabel>???</meter> To indicate that that an element performs functionally like a meter, without any semantic assumptions. Given the greater degree of awareness that a developer should have when developing accessible content. I think it would be better to have the default to be the raw functionality and an attribute to indicate that the semantic context is valid. I don't believe that proponents of the semantic web would go for that, because not enough people would opt-in. They would prefer opt-out or no option at all.

wodenokoto 3y ago
The core concept of semantic web is that a “feature” _doesnt_ correspond to a behavior. You can’t use emphasis to show italics, because it is used for emphasis- not a specific type of emphasis. And you as the author of a semantic HTML document don’t know how emphasis will work on the final users rendering.
- simongray 3y ago
  I just wanted to point out that both you and the one you're replying to keep writing "semantic web", but I think what you really mean is "semantic HTML". The semantic web is the umbrella term for the stack of technologies that include RDF, SPARQL, OWL, etc. — it doesn't really have anything to do with HTML, other than some special syntax for embedding RDF into HTML.
  - wodenokoto 3y ago
    You are right that parent and grandparent should have used semantic HTML instead of web. But I’m not sure I agree on your definition either. Looking at Wikipedia, semantic web is described, first as Web 3.0 (not to be confused with web3) but I remember it more as a dream of late 90s early 2000, where all data lived on internet accessible urls and had semantic markup, than a tech stack.
    - simongray 3y ago
      Well, it's a pretty concrete tech stack these days even if the original vision didn't take off. I actually use these technologies in my day job (and have been for several years), so it's not just a wikipedia look-up for me. Maybe that's why I think of it in more concrete terms.
    - Lerc 3y ago
      >Web 3.0 (not to be confused with web3) I find this distinction to be rather ridiculous. They both semantically(heh) proclaim to be the next version of the web. I see there's a bit of an edit war on https://en.wikipedia.org/wiki/Semantic_Web https://en.wikipedia.org/wiki/Semantic_Web over the one true web 3. It's just an arbitrary name where people have incremented a number for something they wanted to be the next big thing. Realistically I think you could only really numerically name the next thing after it has actually successfully been adopted.
  - Lerc 3y ago
    I had pretty much forgotten most of those things had existed. I see someone has sneakily added ActivityPub to the end of the list on wikipedia in 2021, retroactively giving them a success. I assume there are pockets of existence for these things but for the most part the only time the majority of people encounter anything under the semantic web umbrella is where it has influenced html. It's a tomato is a fruit or vegetable thing, it is technically fruit but to most people it is effectively a vegetable.
pjc50 3y ago
This is the is/ought distinction again, isn't it. > I have seen some attitudes that are strongly against doing this even going back to the days of WinAmp where people were arguing passionately that custom user interfaces like that should not be permitted. On the other hand lots (I would guess millions) Opted for WinAmp precisely because of it's UI customization. It wasn't for everybody, but optional things do not need to be for everybody. This really needs to be printed out and displayed on a billboard. The existence of options, and other people making choices, is not a threat. There needs to be space for nonfunctional whimsicality. A music player is a good place for it. An aircraft console is probably not a good place for it.

readthenotes1 3y ago

I love the headline! (It is the end of adolescence - - when you realize that just because you can doesn't mean you should...)

yetanother12345 3y ago

Try styling it (CSS). I've been there. One more reason not to use it.

patates 3y ago
The ARIA role has the same semantic ability and full customizability: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/meter_role https://developer.mozilla.org/en-US/docs/Web/Accessibility/A... Perhaps it would make sense to use this instead of the element, but not sure if there are any downsides?
yreg 3y ago
Why? We haven't had much of a problem styling our. https://i.imgur.com/vrHD9np.png https://i.imgur.com/vrHD9np.png
CM30 3y ago
Ah, I remember doing this all too well. Or at least, with the very similar <meter> element anyway. God it was a nightmare. There was no standardised selector for various parts of the bar, so I had to use a bunch of awkward -webkit and -moz prefixed ones that weren't consistent at all. The values for these were in at least one case contradictory, so the value for one part of the bar had to be assigned to one pseudo element in Chrome and the opposite one in Firefox, and getting the thing to work as expected in Safari was as awkward as you could imagine, despite all the documentation saying it'd use the same styles as Chrome. They really need to standardise the selectors and styles for these things already...

rendall 3y ago

On Firefox anyway, I was surprised to see that the <meter> element does not have a tooltip to show the value.

LoganDark 3y ago
Same on Chromium.
atoav 3y ago
Maybe if a titlw attribute is added?
- rzzzt 3y ago
  That does seem to work.

ZiiS 3y ago

A better example is fuel level. Using numbers would be distracting and imply more accuracy then is probably available.

Dalewyn 3y ago
I actually detest meters in cars and wish they would all be abolished in favor of number displays. No, I don't find the speedometer with a needle vaguely pointing somewhere easier/faster to read than a simple readout that says 40mph or whatever my speed is. No, I don't find the fuel gauge easier/faster to read, just give me that in percentage numbers. Of course, I know why meters are the go-to in car dashboard indicators: Cars hail from an era when we didn't have an easy way of dynamically printing numbers on a slab of metal or plastic yet. But we're in the 21st century. LCD screens are everywhere around us. Just give me the fucking numbers, I can read them faster than I can discern your arbitrary needles and scratch lines. And just so I'm clear in my consistency: I also hate gauges and pie charts for HDD/SSD space usage, CPU usage, RAM usage, and so on. If it can be expressed in numbers, give me the numbers. I can read them faster than I can discern arbitrary squiggles screaming across other arbitrary squiggles. Gauges and meters are strictly for when displaying dynamic numbers is impractical or impossible.
- ZiiS 3y ago
  A speedometer is accurate to sub-mph. If you are just below the limit, it is helpful to know if you are still creeping up etc. A purely numerical display is either too course or changes too frequently to read. Many cars already have a slower changing numerical MPH readout inside the meter, so hopeful we can both be happy.
- omeid2 3y ago
  While reading individual metrics might be easier with numbers, with gauges you can scan the whole system at low precision very quickly. It is also easier to just see "fuel red", "temperature normal" than 12.5L or 89.5C.
  - Dalewyn 3y ago

mjburgess 3y ago

Can anyone explain how HTML/CSS/etc. can be "semantic" at the syntax layer when it is largely a means of specifying a UI? The era when HTML was a markup for text documents is gone -- what sense is there in supposing it can be 'semantic' ?

atoav 3y ago
A h1 is still likely a heading, a meter is some value and a div could be everything. This is semantic. The opposite of semantic would be having all divs and using them for everything.
froddd 3y ago
Every element has a function or hierarchy in the document. The ‘semantic’ association helps define that role. This is useful for technologies that rely on something else than the visual output of the document, for instance, screen readers. As an example, a heading might contain the content: “A brief summary”. Without a semantic role, this does not convey the hierarchical position of that element within the document. Using the correct tag (in this case, `h{1|2…}` does provide this extra information and helps provide structure to the document.
- mjburgess 3y ago
  I suspect tag names are not the right place for screen readers to be getting that information. The web isnt hypertext any more, it's hypogui. If we defined a "WebGUI Markup Language" it could be a requirement that all UI elements have semantic attributes, etc., eg., <Text type="heading" purpose="page title"> My Web Page </Text> It just seems we're hobbled by this 1992 idea that the web is wikipedia, and our markup languages should be foremost about how text documents are described.
  - notpushkin 3y ago
    https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles https://developer.mozilla.org/en-US/docs/Web/Accessibility/A... seems to be close to what you want.

forgotusername6 3y ago

Current microphone level is a pretty sound usecase

iforgotpassword 3y ago
Showing the density of some mass would be pretty solid.
- skibz 3y ago
  Displaying the temperature of something might be cool.
  - TonyTrapp 3y ago
    You guys win the internet for today. Especially since we got forgotusername6 and iforgotpassword to collaborate in this thread. Only missing a contribution from forgetemailaddress42...
    - GreenWatermelon 3y ago
      I'm here just like "A pun thread? On HN?" Very rare for one of those to stay alive around here. Has yo be because they provide good examples.
  - deleted 3y ago
    [deleted]
  - hunter2_ 3y ago
    Displaying hit points of a game character would be the bomb (alternatively: health points would be sick).
- TOGoS 3y ago
  Zero on the left and....neutron star density on the right?

asimpletune 3y ago

I didn’t actually understand the author’s problem, and if you read the mdm article they go into more detail. Seems pretty useful actually. I would use meter to represent a character’s stats. There’s even an “optimum” attribute, so you can include their oxygen concentration levels, if they’re extraterrestrial.

madeofpalk 3y ago
The authors problem is just that MDN had a poor example. It was unclear what temperature the oven should be set to. It's just a silly, unforced error.
Karliss 3y ago
The element itself isn't an issue. It's that 2/3 examples on MDN are awful, you shouldn't use the meter tag as substitute for a number in a middle of sentence. "Heat an oven to <green progressbar>" or "He got <red almost full progressbar> on the exam". It's largely an accessibility feature, since just for displaying purpose similar effect could be achieved using one or few images and appropriate styling options. Having a dedicated tag with additional metadata, potentially allows blind readers to better understand what was meant compared to "x px wide image". Ironic that the examples of accessibility feature demonstrate usage which would make the page less accessible to most of the users.
- asimpletune 3y ago
  O yeah, that is not easy to understand at all.

zarzavat 3y ago

> While <progress> is fairly self-explanatory – it shows how far along something is, such as your progress through a form My understanding is that this is incorrect. <progress> is for a progress bar, such as downloading a file, or a loading screen. <meter> is for showing a value in linear space. The progress through a form is a value in linear space, not a task that the user is waiting for. Their progress can go forward and back. The user is in control of the value. Therefore <meter> is the correct element. Is the element there to keep the user amused while they are waiting for something? Could it conceivably be styled so as to include a waiting animation? Does it only ever move forwards and never backwards? If yes, then it's a <progress>, if no then it's a <meter>.

oniony 3y ago
Downloading a file or a loading screen is also a value in linear space. The only difference, in my mind, is that: • Progress is expected to go upwards as the underlying task is completed. It can, however, stall on a value or it can reset back to zero if the task fails and is restarted. But in the normal, common case, the trend is upwards towards completion. • Meters reflect the current value of some metric and so can go up and down as the underlying value changes through time, e.g. room temperature, or disk space used of a disk space quota. You could use a meter to indicates progress. As such, I think progress is a specialised meter, where we don't care so much about the underlying value, just that we're working steadily towards the goal.
- zarzavat 3y ago
  Here's one counter example: Progress indicators can be indeterminate, when the duration of the task is unknown but you still want to communicate to the user that something is happening. You can make an indeterminate <progress> by not specifying a value attribute, and then styling it with the :indeterminate pseudoclass (TIL). It's well worth it to read the Apple Human Interface Guidelines, even if you don't develop for Apple platforms, they have some good universal UI advice: Progress indicators: https://developer.apple.com/design/human-interface-guidelines/progress-indicators https://developer.apple.com/design/human-interface-guideline... Gauges: https://developer.apple.com/design/human-interface-guidelines/gauges https://developer.apple.com/design/human-interface-guideline...

e_y_ 3y ago

In general, using semantic tags like <meter> and <progress> instead of a div has to be done carefully because browsers and screen readers often have bugs and inconsistencies especially for less commonly used tags (and even for widely used tags)

diggan 3y ago
If only there was a library that could abstract over those differences and provide a unified API, feel and look so I can write code that I know works and looks exactly the same in all browsers.

mcv 3y ago

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.

zerojames 3y ago
I have used <meter> in the past for polls, too (see https://jamesg.blog/poll/ 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).
kevincox 3y ago
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.
lucideer 3y ago
> 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.

ericyd 3y ago

Kind of a weird stance, it seems like the author is arguing for a div simply because of one bad MDN example. I don't see any downside to using a meter and a visible numerical value together, which I'm sure is the intended purpose.

User3456335 3y ago

This is just one bad example that wasn't even in a real application. Someone just tried to think of an example, happened to look at his oven and quickly wrote something down. The article then attacks this strawman example.