Problem with <output> is that it is half-baked making its usage almost useless.
It would be significantly more practical for the output to have "type" attribute in the same way as in the input.
I did experiment with oputput|type in my Sciter and added these:
type="text" - default value, no formating
type="number" - formats content as a number using users locale settings,
type="currency" - formats content as a currency using users locale settings,
type="date" - as a date, no TZ conversion,
type="date-local" - as a date in users format, UTC datetime to local,
type="time" - as a time
type="time-local" - as a local time, value treated as UTC datetime.
This way server can provide data without need to know users locale.
> The output element represents the result of a calculation performed by the application, or the result of a user action.
<output> is for changing content. It's the ARIA semantics that matter. The content gets announced after page updates.
You can put whatever you want inside the <output> to represent the type. "text" is the default. You can represent dates and times with the <time> element. And while there is currently no specific number formatting element, since Intl has arrived there have been many requests for this.
For example:
<output>The new date is <time datetime="2025-10-11">Oct 11</time></output>
IOW, <output> should not have to handle all these types when it handles HTML and HTML needs to represent the types anyway.
It's sad how many elements this is still the case for in 2025. A good chunk of them can be blamed on Safari.
Probably the most extreme example of this is <input type="date"> which is supposedly production-ready but still has so many browser quirks that it's almost always better to use a JS date picker, which feels icky.
Omg yes, I thought I was crazy when I was pushing for native input type=date instead of JS date picker, it worked perfectly with minimal configuration on my phone and on my Mac, but then my coworkers said it didn't work for them on their browsers, turns out, yeah, it's not consistent.
I then proceeded to spend the next week crying trying to get JS date picker to work as well as native did on my browsers.
Safari and Firefox together seem to always be dragging their feet on things. Sure, sometimes it's "standards" chrome is ramming through, but many times it's things like this, that have been around since before chrome
You are thinking about it wrong, output is not symmetrical to input to have a type, it's a container for content that updates while you're using the page.
And it would just show you the input value. Maybe with a "type" specifier like talked about. Maybe the ::before or ::after css and it would allow content: updates or something.
Bunch of <input> types that there's a reasonable case for. Especially if it allowed for formatting. Did you put in the type="tel" the way you believed? It prints it out formatted.
'checkbox, color, date, datetime-local, file, month, number, radio, range, tel, time, url, week' might all have possible uses. Some of the text cases might have uses in specific conditions. 'email, text, url'
Also be nice if the for="" attribute actually did very much. The attachment seems mostly irrelevant in the examples seen. Most example just use a variation on:
<output for=input>
<!-- bring your own time-locale component -->
<time is=time-locale datetime=2001-02-03>2001-02-03</time>
</output>
With the component replacing the value dependent on locale. I don't think having HTML/CSS fiddling around with making fake content is a great idea, it already causes issues with trying to copy things injected by CSS's :before/:after psudoelements, let alone having a difference between the DOM's .innerText and, well, the inner text.
Not saying decisions can't be made about these things, just that, making those decisions will pretty much make a dedicated DSL out of a single element (dependent on input, desired kind of output (absolute or relative), other data sent along side (type of currency, does it need to be a "real" currency? Since instead of just calling something in mutable/overridable JS, its now part of the HTML processing, something that can't directly be touched)
I agree in general but I think for showing a date/time in the users chosen locale I’d make an exception. Just seems a lot easier than managing that in your application.
I would be on board with most of these, but...Why on earth would the server send a currency value without knowing the users locale? Are you expecting the browser to be constantly pinging services to see exchange rates?
You're talking about currency formatting while they are talking about currency value. In essence, you're both correct.
They are correct in that if you're displaying a currency value, you have to know which currency it is in, right? It wouldn't make sense for the server to be "unaware" of the locale of the value.
That said, your comment sidesteps that issue and addresses how the number itself is displayed, since ultimately the value itself is a number, but different locales display numbers differently.
So the person you're responding to is asking: since the server ostensibly already knows which currency it's in, shouldn't it already be formatting the value appropriately, and that's more a question of where one thinks localization formatting should ultimately live in web app context.
Bingo. Take the swapping of periods and commas between US and maybe Germany.
If you see a price in Euros and there's a chance the browser converts the number to my locale, then the price becomes completely ambiguous. Information is lost unless I change my locale just to see if the number changed.
If, on the other hand, the browser doesn't apply such formatting, then the number is probably the number.
What's more, wouldn't you need to specify an origin locale so the browser knows how to correctly interpret the value?
I got totally mad about it and wanted to write a snark comment, but then I checked what it does and it's just number formatting. It doesn't add a euro sign to it. That would have been a bad idea of course.
More relevantly, take the swapping of full stops and commas (and the position of the currency sign) between Ireland and Germany, which use the same currency.
A payment, bill, price, etc has a particular currency.
For example, 59.95 Australian dollars:
In en-AU locale, that is $59,95.
In en-US locale, that is 59.95 AUD or AU$59.95.
Either way, the quantity and units are the same, but they are presented differently.
In some cases, there may be currency exchange services. That will depend on the current exchange rate, and possibly exchange fees. And yes, that will take some more work. But that’s a fundamentally distinct concept than pure presentation of a monetary amount.
You shouldn’t ever need to poll from the browser. If you were using WebSockets you could send 5 stock updates to the browser per second with almost no resource costs.
How is that currency one supposed to work? Converting between currencies depends on their browser picking an exchange rate that you would never want to trust if your doing anything that involves actual transactions.
I think we got to this point because the browser was originally a tool to browse documents and media. Now it’s kind of a software distribution platform with interactivity. And we got there by quick implementations/workarounds.
Ok, but as a peer comment points out, doing this client-side is fraught / potentially nonsensical to convert a monetary number value to a different currency if you don't know the exchange rate.
Is currency exchange rate even part of the WHATWG standard? You will always need do to do something fraught / potentially nonsensical to convert between different currency, if not on the client, then on the server.
Formatting output values to the user’s locale has nothing to do with currency exchange rate. And JavaScript does the former rather excellently (except when the locale is not supported [ahm, Chromium]).
I, too, am concerned about AIs not reading the docs. What happens when a new W3C spec comes out and most people are vibe coding? If AIs don't take current specs into account and just regurgitate old code patterns, then disseminating spec updates or new specs will be harder than it already is.
LLMs generate code based on statistical patterns found in vast amounts of training data from existing projects, not by reading language specifications. If the tag is rare in the wild, it will be rare in their output.
> Update 7 Oct 2025: Some screen readers have been found not to announce updates to the tag, so explicitly emphasising the role attribute might be worthwhile for now until support improves: <output role="status">.
Waiting for support to improve on a 17 year old tag that is barely used anymore?
If adding the ARIA role fixes the problem, then it's not the fault of screen readers: it's browsers not exposing the semantics properly (unless explicitly instructed to). Please don't assign blame to the "obvious" target unless you actually know who's at fault.
If the screen reader were at fault, then explicitly specifying the implicit role (something that should be a no-op) would not fix the problem. It's the responsibility of web browsers to implement and expose implicit ARIA roles (see https://www.w3.org/TR/html-aam-1.0/#mapping-html-to-accessib...). Screen readers do not (in general) speak HTML, just like computer monitors do not (in general) speak CSS.
Have you ever used a screen reader? A lot of their failure modes are exactly as you'd expect from the model I've described: look at, for example, the differences in how definition lists are exposed to Windows Narrator between Firefox, Chrome, Edge, and Edge-in-IE-mode.
Semantic html is a novice trap, just do the thing that works and that browsers expect (aria-live)
It's fun to play around with things like this, but if you're a developer you have a responsibility to build things that work for your users using the existing tools and ecosystem. Don't use semantic HTML tags that aren't widely used, just do the thing that works.
> Like <label>, <output> has a for="" attribute. Here you list the ids of any <input> elements the result depends on
Any screen reader users able to comment on whether this is worth doing? I suspect this would be such a rarity online that screen reader users wouldn’t be familiar with it, but it depends on the UX of the software
Not a screen reader user but I have used them a lot in testing. I'd be surprised if it's meaningfully exposed to assistive tech. Not at the computer right now so I can't test.
That said, I imagine it's more useful to do the opposite, label the output itself e.g.
For static scenarios this works well with screen readers. On the output tag the "for" property helps screen readers deal with dynamic values, essentially adding reactivity to the element. I use it so infrequently I've never explored how it works but screen readers will catch that the value has been updated.
This is handy for testing with screen readers, and includes links to the appropriate spec (for output and all elements):
It's often the case that screen readers do not support the more exotic aspects of html (hell even some basics, unfortunately).
The browser may add a reference from one to the other in the accessibility tree, but whether a screenreader announces it is another matter. I'd be surprised if it's supported in any meaningful way here. Happy to be shown otherwise!
Apparently, it's about screen reader support in web pages.
Also "ARIA" stands for Accessible Rich Internet Applications and it's "a set of HTML attributes that make web content more accessible to people with disabilities."
This is like explaining what JavaScript is under a post about React. There’s no shame in not knowing accessibility basics, but there’s also no need to act like it’s ridiculous to expect the reader to know some.
I think "act like it's ridiculous" is pretty hyperbolic here. I didn't know what ARIA stood for until now (though I knew what it was).
You'd be surprised how many people barely know it exists... I was a TA for my uni's Web Engineering and Ethics in CS courses and accessibility never even came up in either course.
> I was a TA for my uni's Web Engineering and Ethics in CS courses and accessibility never even came up in either course.
That is genuinely baffling to me. How does a university teach web engineering without even mentioning accessibility? It’s not just best practice—it’s often a legal requirement for public-sector sites in many countries. Even outside government work, major companies (FAANG included) publicly invest in accessibility to avoid both reputational and legal fallout. Ignoring it entirely sends the wrong message to students about professional responsibility and real-world standards.
Didn’t come up in my ethics course either. Unless you actually know someone with an accessibility issue, it’s unlikely you have encountered it or recognized it if you did.
For example: You don’t realize how absolutely abysmal voice control is for computers until you have to use it.
There are so many assumptions about the world that causes things like neurodivergence to become a disability instead of a difference.
Many schools are not very good at teaching real world skills. Always been this way.
It’s why ‘self taught’ in many disciplines is very doable too, if someone focuses on what people actually want/need.
They might not be good at articulating the differences between fizzbuzz and bubble sort, but they can get shit done that works.
Every PhD that I know that went from Academia to Industry immediately had their stress levels decrease 10x and their pay roughly double too - because they could finally do a thing, see if it worked or not, and if it did, get paid more.
Instead of insane constant bullshitting and reputation management/politics with a hint of real application maybe sprinkled in. Few ‘knives’ have to be as sharp as the academics, in my experience.
> * I think "act like it's ridiculous" is pretty hyperbolic here.*
Fair. I might’ve read more snark in the “Apparently,” than the commenter intended to convey.
For what it’s worth, the comment you read is the toned down version of what I had initially come up with. I really don’t think being dismissive of accessibility concerns is good style.
You made me realize it's like NASA: a good chunk of the worlds knows it, but I bet most don't know what it stands for (at least outside the US I bet 99.9% don't know -- me included haha)
MDN has decent docs on this, including (and echoed by the author) this top-level guidance:
>> The first rule of ARIA use is "If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so."
I really like (not) when people read about accessibility and the first thing they decide to do is adding keydown handlers on all the buttons that have clicks handlers. Like, please, treat it like the rest of UX and design for it, instead of going with a checklist over all the places linter flagged.
Hey thanks for clarifying. I could have googled it, but lazily reading your comment on a cloudy Saturday afternoon is easier. Thanks again, appreciate it. ;)
I came to this article expecting to see <output> misused, and was pleasantly surprised. :-)
(Actually, the dodgy GenAI calculator image at the top primed me for even more failure, making the excellent content that followed even more surprising. But I soon forgot about it and only remembered when I scrolled back to the start for no particular reason when done.)
It appears human beings are already forgetting the even more dodgy images some of us created before AI allowed us to reduce said dodginess. Or actually get a picture we could post without too much shame. :)
And in this case, IMHO, the image has a significant amount of dodgy vintage tech charm.
Not every use of AI replaces a professional artist.
If you have to use `role=status` to make it work with screenreaders, I'm not sure I see the point.
Maybe I'm jaded, I was all in on semantic xhtml and microformats before we got HTML5, but this seems like being overly-pedantic for the sake of pedantry rather than for a11y.
Another is structuring your form names to help align with how it’s going to be used in the backend so you don’t have to use JavaScript to gather all the data or be doing a lot of restructuring of the request data.
This is an oversimplified example but now even if you submit with JS, you just have to submit the form and the form data is already there.
So there's useful html tags from 2008 that no one uses or knows about... How can that be the case? Because there's just so many tags? Because people don't read the docs? Because the benefits are not obvious?
Most sites today are not using HTML in the way it was originally envisioned. They use something called "DHTML" instead. The D stands for DIV, because people seldom use any other tag. E.g. in normal HTML you would use the TABLE, TR and TD tags to build a table. In modern DHTML (aka DIV-HTML) people build the table from fixed size DIVs, and calculate the column sizes via JavaScript.
I'd say DHTML was more of a thing in the early 2000s when we were still using tables for layout. The divs came later, when the abbreviation had fallen out of fashion because all HTML kinda was dynamic by default.
Be sure to correct all the people who are using the term “cool” for things other than relative temperature, as it was originally defined.
See also the dictionary fallacy, and again descriptivism vs prescriptivism.
Additionally, even leaving alone the div/dynamic language issue, there really isn’t a point in usage history where DHTML came without JS — believe me, I was doing it when the term first came into usage. JS was required for nearly all dynamic behavior.
DHTML is literally just HTML that is dynamically modified by JavaScript. DHTML became a term when JavaScript became ubiquitous. It was not an extension.
Javascript was not ubiquitous when the term DHTML was last seriously used. And yes, CSS and javascript were extensions at the time, not very widely supported across all browsers.
We had table based layouts and then divs when CSS started to take off, mostly used by artists rather than companies at first.
Javascript had vanishingly limited uses at first, too. I don't remember exactly how long it took us to get XHR but before that we had "Comet frames", before iframe security was given much focus. Javascript couldn't do that for a while. It was also dodgy and considered bad practice for quite a while, too.
I don't remember when the term javascript was even really used in regular vernacular but DHTML was not so much referring to CSS as it was the myriad of weird mechanisms introduced to make pages dynamic. It was never "Div-based HTML" or whatever, the div craze came way later once CSS was Good Enough to eschew table layouts - after which, Dreamweaver died and photoshop's slice tool finally got removed, and we started inching toward where the web sits today.
I also do distinctly recall needing a doctype for DHTML for some browsers.
> Javascript was not ubiquitous when the term DHTML was last seriously used.
It wasn't as fast or as usable as it is today, but Javascript has been in every mainstream browser since before Microsoft started pushing "DHTML".
Interestingly, in my memory, it seemed like we had JS for a long time before DHTML, but it was only a couple years between Eich writing it and IE4, which was the start of the "DHTML" moniker. Looking back at the timeline, everything seems much more compressed than it felt at the time.
DHTML was just JavaScript that mutated the DOM. That’s literally all it ever was. There was also not a DHTML doctype. There was also not anything even called “an extension”. There were Java applets, ActiveX controls, and ActionScript -> JavaScript bridges, which the concept of DHTML (dynamic HTML) eventually fully replaced.
Divs weren’t a “craze”. They were popularized by the (brand new) XHTML spec, which did have its own doctype.
> I don't remember when the term javascript was even really used in regular vernacular
2004 or 2005. Gmail and Google Maps were a "holy crap this is actually possible?" for a lot of people, both technical and non, and was when javascript switched from mostly-ignored* to embraced.
*Just minor enhancements, outside of technical people mostly only known to MySpace users who wanted to add a little flair to their page. XmlHttpRequest was almost entirely unknown even in technical spaces until gmail showcased interaction without page refreshes.
This is a legacy of old apache configurations, the common mime type configuration files used .html to send the straight file, and .shtml to turn on the server side processing instructions. Server side includes could be static files or executable scripts that generated text on STDOUT. If you were using a lot of server side includes, it was cleaner just to turn on server side parsing for the whole site.
It's also due to browser not doing anything useful with the additional tags, if I use <article>, <section> or <div> doesn't make any difference, my browser doesn't use that to generate a TOC or let me open an <article> in a new Tab. Even the, in theory, incredible useful <time> tag seems to be completely invisible to my browser and many other potentialy useful tags don't exist in the first place (e.g. <unit> would be useful).
Exactly this. I really wish browsers would use semantic html to make content more accessible for me, a sighted user! Why does my browser not give me a table of contents I can use to navigate a long page?
I think the parent has a good point: browsers don't do anything with these tags for sighted users, who are unfortunately the majority of developers. If they were to notice benefits to using semantic tags, maybe they'd use them more often.
It’s interesting, because if you imagine sites actually using these tags to be maximally compatible with reader mode and other accessibility modes, they’re setting themselves up perfectly to be viewed without ads.
I use reader mode by default in Safari because it’s essentially the ultimate ad blocker: it throws the whole site away and just shows me the article I want to read.
But this is in opposition to what the website owners want, which is to thwart reader mode and stuff as many ads in my way as they can.
It’s possible good accessibility is antithetical to the ad-driven web. It’s no wonder sites don’t bother with it.
Reader mode seems to still work if you have a div with article text in it. I would be interested to see a comparison of what works and what doesn’t if such a reference exists though!
Yes, I think that is what browser should spend money on instead of inventing new syntax. Google Chrome still doesn't support alternate stylesheets. But I refuse to not use them simply because a rich company can't be bothered to implement decades old standards.
Not true. Using semantic HTML and relying on its implicit ARIA roles allows the browser to construct an accurate AOM tree (Accessibility Object Model) which makes it possible for screen readers and other human interface software to create TOCs and other landmark-based navigation.
> Not true. Using semantic HTML and relying on its implicit ARIA roles allows the browser to construct an accurate AOM tree (Accessibility Object Model) which makes it possible for screen readers and other human interface software to create TOCs and other landmark-based navigation.
Sure, it allows the browser to do that. GP is complaining that even though browsers are allowed to do all that, they typically don't.
We just don't have enough tags that we can really take advantage of on a semantic or programmatic level, and that has lead to other tags getting overloaded and thus losing meaning.
Why don't we just have markup for a table of contents in 2025?
That'd open a whole new can of worms. Browsers are already gargantuan pieces of software even with the relatively primitive tags we have today. We don't need to further argue with each other what the <toc> tag should look and behave like, deal with unforeseen edge cases and someone's special use cases which end up requiring them to implement the whole thing with <ol>s and <li>s anyway.
Then let the edge cases use <ol> and <li>, and in some sense all those website style simplifiers that comes built-in with Safari will just have to deal with those edge cases. Similarly we have a built-in date picker, and if you don't think it's good enough then build a better one.
If you want a specific behavior for <time> then write a browser plugin which e.g. converts the <time> content to your local time.
But if you are a developer you should see value in <article> and <section> keeping your markup much much nicer which in turn should make your tests much easier to write.
a
abbr
address
area
article
aside
audio
b
base
bdi
bdo
blockquote
body
br
button
canvas
caption
cite
code
col
colgroup
data
datalist
dd
del
details
dfn
dialog
div
dl
dt
em
embed
fieldset
figcaption
figure
footer
form
h1
h2
h3
h4
h5
h6
head
header
hgroup
hr
html
i
iframe
img
input
ins
kbd
label
legend
li
link
main
map
mark
menu
meta
meter
nav
noscript
object
ol
optgroup
option
output
p
picture
pre
progress
q
rp
rt
ruby
s
samp
script
search
section
select
slot
small
source
span
strong
style
sub
summary
sup
table
tbody
td
template
textarea
tfoot
th
thead
time
title
tr
track
u
ul
var
video
wbr
> Update 7 Oct 2025: Some screen readers have been found not to announce updates to the tag, so explicitly emphasising the role attribute might be worthwhile for now until support improves: <output role="status">.
Maybe it's because like most things html/css related, it's a semi-broken implementation of a half-feature?
Maybe because most HTML tags are not well supported by browsers, because they are doing by themselves only half of what a developer would want, hard to style, hard to enhance the native behavior, ... most recently-added tags have those problems (ex: <progress>), this one from 2008 is an even better example
Because no one cares about HTML except as a payload carrier for the real website: the JavaScript output from React/Tailwind/Typescript compilation.
You have to remember, this is an industry that thinks having code without syntax errors was too unreasonable a requirement for XHTML, there is no reason to expect them to know anything beyond div and maybe a dozen other tags.
People who already have a habit of solving a problem a specific way are generally unlikely to switch when a new solution appears unless it is considerably easier. If it's not immediately easier, it will feel easier to continue the ingrained habit.
My guess would be that most people just copy (mimic) what is already there. I sometimes work as a freelance web administrator and I can assure you 95% of people who create websites for a living have never read through a list of HTML tags, have only a slight idea of the semantic web and in the end they are more like people who cobble existing things together and are out of their depth pretty quickly.
Not that this is problematic per se, everybodies milage may vary and we're all out there to learn. But if I told one of them about the output tag thry probably wouldn't even understand why that would be important.
In some cases, because there was a period of time where it might not have been in HTML in all browsers, and javascript was used instead, and then HTML had it.
Then no one checked, and the javascript train had already left the station.
For a website speaking accessibility, it does something very bad and annoying with scrolling. Not using the native browser scrolling I think.
When I use the middle wheel of my mouse to go up or down, sometimes it suddenly it ignore the command or stutter or go back a little bit instead of continue going down or some random movement.
Even with using 2 fingers scroll with the touchpad, I can feel very slightly that there a subtle lag or stutter.
Interestingly I've often seen this in Claude outputs, especially on long prompts. I've assumed this is because of Claude's XML-based instruction format, but this does make me wonder how related the two are. And if Claude may have a harder time using <output> given it's related to both accessibility and its instructions
I don't think this was ignored for no reason or simply forgotten. I don't see it bringing a great feature or value compared to input tag. You still need to code up the logic for setting its value, via a script, like any other container tags. You could pretty much use a read-only input tag to include the output with the form.
Hell html in 2025 feels so underdeveloped, semantic html should just be declared dead and we should just move on. How many years we wasted by having "experts" underlining the semantic meaning of aside, article, main etc? Good lord, perhaps we should just totally skip the dom and use a graphics, input and accessibility api the way we want
It seems to me that most semantic HTML has helped third parties extract data from web pages for their own use.
Perhaps if you are an important primary source of information like a government service that could be useful if it helps you advance your cause of sharing data, but I don’t think it is in the interest of most website operators if it reduces traffic to your site.
I understand that their are some accessibility benefits to some semantic HTML tags.
The discussion of past years instead of being focused on "what we could do next to make developing apps for the web better?" has been focused on which semantic meaning the x tag has and where it should be used, creating just a lot of confusion and disagreements, vs the reality: people just use divs, you can still specify aria attributes there, why not giving us an api to specify semantic meaning as well the way we want? I'd like to have something like flash back, html5 was a step back, partially has already been achieved by flutter and react native. Please Browser vendors just give us a goddman drawing api that doesn't feel limited as canvas is with a semantic, accessibility and input apis that don't suck!
I can see this having extreme value 20 years ago. Then it could take more than a minute to asynchronously get data back and you needed to tell people what content on the page changed.
Now, the bottleneck is entirely the database first and the framework second. Those can be switched if the framework code is extra garbage. When those are taken out of the equation I am seeing text update to the screen in about 5-15ms in response to a user interaction that requires execution on the localhost server, 45ms for networked server.
At that speed you don’t need to alert the user of any content changes. You only need to structure the content such that walking the DOM, using a screen reader, from point of interaction to area of output is direct and logical, expected, for a human.
I honestly don't know what is it for. Why is it important to have an output tag.
The output of any actions will be shoved into any N random elements. So every `<div>` will have `<output>`? Why? Waste of payload size and CPU cycles in parsing.
The designers of semantic tags truly live in ivory towers.
The article was all good until he started to use react for implementation. I would not have done that for an article about web standards, and I use react all the time.
I think the lesson here is if you want to provide an accessibility feature, you have to also make it do something useful for people that don't care about accessibility.
Problem with <output> is that it is half-baked making its usage almost useless.
It would be significantly more practical for the output to have "type" attribute in the same way as in the input.
I did experiment with oputput|type in my Sciter and added these:
This way server can provide data without need to know users locale.From the article: and spec:
> The output element represents the result of a calculation performed by the application, or the result of a user action.
<output> is for changing content. It's the ARIA semantics that matter. The content gets announced after page updates.
You can put whatever you want inside the <output> to represent the type. "text" is the default. You can represent dates and times with the <time> element. And while there is currently no specific number formatting element, since Intl has arrived there have been many requests for this.
For example:
IOW, <output> should not have to handle all these types when it handles HTML and HTML needs to represent the types anyway.> half-baked making its usage almost useless.
It's sad how many elements this is still the case for in 2025. A good chunk of them can be blamed on Safari.
Probably the most extreme example of this is <input type="date"> which is supposedly production-ready but still has so many browser quirks that it's almost always better to use a JS date picker, which feels icky.
Omg yes, I thought I was crazy when I was pushing for native input type=date instead of JS date picker, it worked perfectly with minimal configuration on my phone and on my Mac, but then my coworkers said it didn't work for them on their browsers, turns out, yeah, it's not consistent.
I then proceeded to spend the next week crying trying to get JS date picker to work as well as native did on my browsers.
On all the projects I worked that involved ui elements library, datepicker consistently was the biggest pain in the ass, rivaled only by modals.
Modals at least are a solved problem these days.
Safari and Firefox together seem to always be dragging their feet on things. Sure, sometimes it's "standards" chrome is ramming through, but many times it's things like this, that have been around since before chrome
You are thinking about it wrong, output is not symmetrical to input to have a type, it's a container for content that updates while you're using the page.
Top personal issue, be nice if it could just attach to an <input> and list the result. Like:
And it would just show you the input value. Maybe with a "type" specifier like talked about. Maybe the ::before or ::after css and it would allow content: updates or something.Bunch of <input> types that there's a reasonable case for. Especially if it allowed for formatting. Did you put in the type="tel" the way you believed? It prints it out formatted.
'checkbox, color, date, datetime-local, file, month, number, radio, range, tel, time, url, week' might all have possible uses. Some of the text cases might have uses in specific conditions. 'email, text, url'
Also be nice if the for="" attribute actually did very much. The attachment seems mostly irrelevant in the examples seen. Most example just use a variation on:
I'd prefer:
With the component replacing the value dependent on locale. I don't think having HTML/CSS fiddling around with making fake content is a great idea, it already causes issues with trying to copy things injected by CSS's :before/:after psudoelements, let alone having a difference between the DOM's .innerText and, well, the inner text.Not saying decisions can't be made about these things, just that, making those decisions will pretty much make a dedicated DSL out of a single element (dependent on input, desired kind of output (absolute or relative), other data sent along side (type of currency, does it need to be a "real" currency? Since instead of just calling something in mutable/overridable JS, its now part of the HTML processing, something that can't directly be touched)
I agree in general but I think for showing a date/time in the users chosen locale I’d make an exception. Just seems a lot easier than managing that in your application.
That is a complete separate issue from <output> though. We'd like to do that in static parts of a page that aren't changing content from user actions.
There have been a bunch of requests for Intl-driven related elements in HTML, and I expect them to be added at some point.
It's still better than <span> or <div> though, isn't it? Which is what most people are using right now...
"better" in what sense? If in hypothetical semantic meaning then another old zombie <var> is better in that sense, isn't it?
Those semantics make it more accessible for free.
Unlike <div> and <span>, <output> becomes part of the form and you can target it as a named form item, e.g.
Too late to edit, but there is a mistake s/document.elements/myForm.elements/r :
I would be on board with most of these, but...Why on earth would the server send a currency value without knowing the users locale? Are you expecting the browser to be constantly pinging services to see exchange rates?
Not sure I understand why do you need exchange rates with it.
<output type="currency"> uses the same convention as "Intl.NumberFormat/style=currency": https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
You're talking about currency formatting while they are talking about currency value. In essence, you're both correct.
They are correct in that if you're displaying a currency value, you have to know which currency it is in, right? It wouldn't make sense for the server to be "unaware" of the locale of the value.
That said, your comment sidesteps that issue and addresses how the number itself is displayed, since ultimately the value itself is a number, but different locales display numbers differently.
So the person you're responding to is asking: since the server ostensibly already knows which currency it's in, shouldn't it already be formatting the value appropriately, and that's more a question of where one thinks localization formatting should ultimately live in web app context.
Bingo. Take the swapping of periods and commas between US and maybe Germany.
If you see a price in Euros and there's a chance the browser converts the number to my locale, then the price becomes completely ambiguous. Information is lost unless I change my locale just to see if the number changed.
If, on the other hand, the browser doesn't apply such formatting, then the number is probably the number.
What's more, wouldn't you need to specify an origin locale so the browser knows how to correctly interpret the value?
<output type="currency">123456.00</output> formats output using user's settings: https://www.elevenforum.com/attachments/currency_format_cont...
If you want specific country format then you may use lang:
<output type="currency" lang="de-DE">123456.00</output>
Currency conversion is not a subject of a browser.
I got totally mad about it and wanted to write a snark comment, but then I checked what it does and it's just number formatting. It doesn't add a euro sign to it. That would have been a bad idea of course.
More relevantly, take the swapping of full stops and commas (and the position of the currency sign) between Ireland and Germany, which use the same currency.
€1,000.48 = 1.000,48€
But if it’s just formatting, how is that different from the “number” type?
Different rule set
!!!
A payment, bill, price, etc has a particular currency.
For example, 59.95 Australian dollars:
In en-AU locale, that is $59,95.
In en-US locale, that is 59.95 AUD or AU$59.95.
Either way, the quantity and units are the same, but they are presented differently.
In some cases, there may be currency exchange services. That will depend on the current exchange rate, and possibly exchange fees. And yes, that will take some more work. But that’s a fundamentally distinct concept than pure presentation of a monetary amount.
You shouldn’t ever need to poll from the browser. If you were using WebSockets you could send 5 stock updates to the browser per second with almost no resource costs.
Also, if to allow form.value to accept JSON-ish objects it will be possible to set form values in single shot:
where form isHow is that currency one supposed to work? Converting between currencies depends on their browser picking an exchange rate that you would never want to trust if your doing anything that involves actual transactions.
It formats numbers and that's it, it doesn't know what currency it is and doesn't try to guess.
That's basically the story with every browser feature. How did we get to the point that everything is built for this awful platform?
I think we got to this point because the browser was originally a tool to browse documents and media. Now it’s kind of a software distribution platform with interactivity. And we got there by quick implementations/workarounds.
It is trivial to do that with JavaScript as you fill in the content of <output> using Intt, e.g.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...Ok, but as a peer comment points out, doing this client-side is fraught / potentially nonsensical to convert a monetary number value to a different currency if you don't know the exchange rate.
Is currency exchange rate even part of the WHATWG standard? You will always need do to do something fraught / potentially nonsensical to convert between different currency, if not on the client, then on the server.
Formatting output values to the user’s locale has nothing to do with currency exchange rate. And JavaScript does the former rather excellently (except when the locale is not supported [ahm, Chromium]).
> But <output>? Most have never touched it. Some don’t even know it exists.
Yeah, count me on with those who don't even know it exists. I'm adding this to my TIL.
> When I searched GitHub public repos, it barely showed up at all.
> That absence creates a feedback loop: if no one teaches it, no one uses it.
This has triggered an instant question in my head: Do LLMs actually use it when generating code or they are not well-trained for this specific tag?
I, too, am concerned about AIs not reading the docs. What happens when a new W3C spec comes out and most people are vibe coding? If AIs don't take current specs into account and just regurgitate old code patterns, then disseminating spec updates or new specs will be harder than it already is.
Most people don't care about W3C specs as it is, nevermind with vibe coding. The React release notes are the important web standards they follow.
I was filled with a definite sadness after reading your comment. It is what it is.
Yeah llms don’t read docs. They repeat the info in docs. And swap letters around the code to make it fit.
I actually discovered <output> because Claude generated it !
LLMs generate code based on statistical patterns found in vast amounts of training data from existing projects, not by reading language specifications. If the tag is rare in the wild, it will be rare in their output.
I mean, they're trained on specs, too. I'll have to play with asking for semantic HTML and see what they come up with.
> Update 7 Oct 2025: Some screen readers have been found not to announce updates to the tag, so explicitly emphasising the role attribute might be worthwhile for now until support improves: <output role="status">.
Waiting for support to improve on a 17 year old tag that is barely used anymore?
If on Windows, opening tickets on NVDA repo works wonderfully well, as long as they find them valid.
https://github.com/nvaccess/nvda
To improve the usage of screen readers that don’t respect a tag that’s parts of the standard for 17 years.
It’s obviously the screen readers’ fault.
If adding the ARIA role fixes the problem, then it's not the fault of screen readers: it's browsers not exposing the semantics properly (unless explicitly instructed to). Please don't assign blame to the "obvious" target unless you actually know who's at fault.
The output tag has an implicit aria-role=”status”. This is 100% on the particular screen reader(s) that don’t support it.
https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
If the screen reader were at fault, then explicitly specifying the implicit role (something that should be a no-op) would not fix the problem. It's the responsibility of web browsers to implement and expose implicit ARIA roles (see https://www.w3.org/TR/html-aam-1.0/#mapping-html-to-accessib...). Screen readers do not (in general) speak HTML, just like computer monitors do not (in general) speak CSS.
If that were true, no screen readers would work, which is not the case.
Have you ever used a screen reader? A lot of their failure modes are exactly as you'd expect from the model I've described: look at, for example, the differences in how definition lists are exposed to Windows Narrator between Firefox, Chrome, Edge, and Edge-in-IE-mode.
You’re right, some screen readers work better with specific browsers. The article doesn’t mention anything about that, though.
Semantic html is a novice trap, just do the thing that works and that browsers expect (aria-live)
It's fun to play around with things like this, but if you're a developer you have a responsibility to build things that work for your users using the existing tools and ecosystem. Don't use semantic HTML tags that aren't widely used, just do the thing that works.
> Semantic html is a novice trap, just do the thing that works and that browsers expect (aria-live)
html isn't just "browsers". I've been doing alot of epub work, and semantic pages make everything easier and better.
I have completed multiple courses on front-end web accessibility and never run into <output>, somehow. Thanks so much for the awesome share.
> Like <label>, <output> has a for="" attribute. Here you list the ids of any <input> elements the result depends on
Any screen reader users able to comment on whether this is worth doing? I suspect this would be such a rarity online that screen reader users wouldn’t be familiar with it, but it depends on the UX of the software
Not a screen reader user but I have used them a lot in testing. I'd be surprised if it's meaningfully exposed to assistive tech. Not at the computer right now so I can't test.
That said, I imagine it's more useful to do the opposite, label the output itself e.g.
<label for="output">Total</label> <output id="output">£123.45</output>
That way it will be announced like "Total, £123.45" rather than a random number with no context
For static scenarios this works well with screen readers. On the output tag the "for" property helps screen readers deal with dynamic values, essentially adding reactivity to the element. I use it so infrequently I've never explored how it works but screen readers will catch that the value has been updated.
This is handy for testing with screen readers, and includes links to the appropriate spec (for output and all elements):
https://stevefaulkner.github.io/AT-browser-tests/test-files/...
It's often the case that screen readers do not support the more exotic aspects of html (hell even some basics, unfortunately).
The browser may add a reference from one to the other in the accessibility tree, but whether a screenreader announces it is another matter. I'd be surprised if it's supported in any meaningful way here. Happy to be shown otherwise!
Apparently, it's about screen reader support in web pages.
Also "ARIA" stands for Accessible Rich Internet Applications and it's "a set of HTML attributes that make web content more accessible to people with disabilities."
This is like explaining what JavaScript is under a post about React. There’s no shame in not knowing accessibility basics, but there’s also no need to act like it’s ridiculous to expect the reader to know some.
I think "act like it's ridiculous" is pretty hyperbolic here. I didn't know what ARIA stood for until now (though I knew what it was).
You'd be surprised how many people barely know it exists... I was a TA for my uni's Web Engineering and Ethics in CS courses and accessibility never even came up in either course.
> I was a TA for my uni's Web Engineering and Ethics in CS courses and accessibility never even came up in either course.
That is genuinely baffling to me. How does a university teach web engineering without even mentioning accessibility? It’s not just best practice—it’s often a legal requirement for public-sector sites in many countries. Even outside government work, major companies (FAANG included) publicly invest in accessibility to avoid both reputational and legal fallout. Ignoring it entirely sends the wrong message to students about professional responsibility and real-world standards.
Didn’t come up in my ethics course either. Unless you actually know someone with an accessibility issue, it’s unlikely you have encountered it or recognized it if you did.
For example: You don’t realize how absolutely abysmal voice control is for computers until you have to use it.
There are so many assumptions about the world that causes things like neurodivergence to become a disability instead of a difference.
Many schools are not very good at teaching real world skills. Always been this way.
It’s why ‘self taught’ in many disciplines is very doable too, if someone focuses on what people actually want/need.
They might not be good at articulating the differences between fizzbuzz and bubble sort, but they can get shit done that works.
Every PhD that I know that went from Academia to Industry immediately had their stress levels decrease 10x and their pay roughly double too - because they could finally do a thing, see if it worked or not, and if it did, get paid more.
Instead of insane constant bullshitting and reputation management/politics with a hint of real application maybe sprinkled in. Few ‘knives’ have to be as sharp as the academics, in my experience.
> * I think "act like it's ridiculous" is pretty hyperbolic here.*
Fair. I might’ve read more snark in the “Apparently,” than the commenter intended to convey.
For what it’s worth, the comment you read is the toned down version of what I had initially come up with. I really don’t think being dismissive of accessibility concerns is good style.
Not knowing about ARIA is like not knowing about requirements for ramp slopes when designing a building. You just... can't.
Yeah, I knew “aria” was “accessibility stuff”, but I couldn’t tell you what it stood for.
Tbh I really don't think it matters what the letters stand for.
You made me realize it's like NASA: a good chunk of the worlds knows it, but I bet most don't know what it stands for (at least outside the US I bet 99.9% don't know -- me included haha)
MDN has decent docs on this, including (and echoed by the author) this top-level guidance:
>> The first rule of ARIA use is "If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so."
https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
The top of a lot of the ARIA docs pages say "No ARIA is better than bad ARIA"
I really like (not) when people read about accessibility and the first thing they decide to do is adding keydown handlers on all the buttons that have clicks handlers. Like, please, treat it like the rest of UX and design for it, instead of going with a checklist over all the places linter flagged.
Hey thanks for clarifying. I could have googled it, but lazily reading your comment on a cloudy Saturday afternoon is easier. Thanks again, appreciate it. ;)
I came to this article expecting to see <output> misused, and was pleasantly surprised. :-)
(Actually, the dodgy GenAI calculator image at the top primed me for even more failure, making the excellent content that followed even more surprising. But I soon forgot about it and only remembered when I scrolled back to the start for no particular reason when done.)
This dodgy GenAI calculator is funny... You can only add, multiply and divide. No subtractions allowed!
> the dodgy GenAI calculator image
It appears human beings are already forgetting the even more dodgy images some of us created before AI allowed us to reduce said dodginess. Or actually get a picture we could post without too much shame. :)
And in this case, IMHO, the image has a significant amount of dodgy vintage tech charm.
Not every use of AI replaces a professional artist.
> Not every use of AI replaces a professional artist.
It normalises it.
There is no reality past or present where someone would have been paid to make this
I love those handmade bad sketch
If you have to use `role=status` to make it work with screenreaders, I'm not sure I see the point.
Maybe I'm jaded, I was all in on semantic xhtml and microformats before we got HTML5, but this seems like being overly-pedantic for the sake of pedantry rather than for a11y.
Chicken-and-egg. As soon as more websites start using the tag, screenreaders will catch up and role=status will not be needed.
It’s nice seeing stuff like this.
Another is structuring your form names to help align with how it’s going to be used in the backend so you don’t have to use JavaScript to gather all the data or be doing a lot of restructuring of the request data.
This is an oversimplified example but now even if you submit with JS, you just have to submit the form and the form data is already there.
<input name=“entity[id]”>
<input name=“entity[relation]”>
So there's useful html tags from 2008 that no one uses or knows about... How can that be the case? Because there's just so many tags? Because people don't read the docs? Because the benefits are not obvious?
Most sites today are not using HTML in the way it was originally envisioned. They use something called "DHTML" instead. The D stands for DIV, because people seldom use any other tag. E.g. in normal HTML you would use the TABLE, TR and TD tags to build a table. In modern DHTML (aka DIV-HTML) people build the table from fixed size DIVs, and calculate the column sizes via JavaScript.
The D in DHTML is usually short for "Dynamic".
Around the time that abbreviation became fashionable using a lot of DIV elements also did, but that wasn't what the "D" stood for.
https://en.wikipedia.org/wiki/Dynamic_HTML
I think that was known by meindnoch and was a joke.
I'd say DHTML was more of a thing in the early 2000s when we were still using tables for layout. The divs came later, when the abbreviation had fallen out of fashion because all HTML kinda was dynamic by default.
Man, I love it when I find a good <table>
https://matthodges.com/posts/2025-09-30-visidata/
Not sure if a joke but this is factually inaccurate.
Accurate to some substantial usage, whatever definitional inaccuracy or backronym action is in play.
Descriptivism usually reflects some reality no matter the intended prescriptives.
No, sorry. It's factually inaccurate. DHTML stood for Dynamic HTML, it was an extension before Javascript and whatnot was added.
Be sure to correct all the people who are using the term “cool” for things other than relative temperature, as it was originally defined.
See also the dictionary fallacy, and again descriptivism vs prescriptivism.
Additionally, even leaving alone the div/dynamic language issue, there really isn’t a point in usage history where DHTML came without JS — believe me, I was doing it when the term first came into usage. JS was required for nearly all dynamic behavior.
Man I live for takedowns like these, nice work
DHTML is literally just HTML that is dynamically modified by JavaScript. DHTML became a term when JavaScript became ubiquitous. It was not an extension.
Javascript was not ubiquitous when the term DHTML was last seriously used. And yes, CSS and javascript were extensions at the time, not very widely supported across all browsers.
We had table based layouts and then divs when CSS started to take off, mostly used by artists rather than companies at first.
Javascript had vanishingly limited uses at first, too. I don't remember exactly how long it took us to get XHR but before that we had "Comet frames", before iframe security was given much focus. Javascript couldn't do that for a while. It was also dodgy and considered bad practice for quite a while, too.
I don't remember when the term javascript was even really used in regular vernacular but DHTML was not so much referring to CSS as it was the myriad of weird mechanisms introduced to make pages dynamic. It was never "Div-based HTML" or whatever, the div craze came way later once CSS was Good Enough to eschew table layouts - after which, Dreamweaver died and photoshop's slice tool finally got removed, and we started inching toward where the web sits today.
I also do distinctly recall needing a doctype for DHTML for some browsers.
> Javascript was not ubiquitous when the term DHTML was last seriously used.
It wasn't as fast or as usable as it is today, but Javascript has been in every mainstream browser since before Microsoft started pushing "DHTML".
Interestingly, in my memory, it seemed like we had JS for a long time before DHTML, but it was only a couple years between Eich writing it and IE4, which was the start of the "DHTML" moniker. Looking back at the timeline, everything seems much more compressed than it felt at the time.
That could be. And yeah, DHTML came and went pretty quickly even by today's standards.
DHTML was just JavaScript that mutated the DOM. That’s literally all it ever was. There was also not a DHTML doctype. There was also not anything even called “an extension”. There were Java applets, ActiveX controls, and ActionScript -> JavaScript bridges, which the concept of DHTML (dynamic HTML) eventually fully replaced.
Divs weren’t a “craze”. They were popularized by the (brand new) XHTML spec, which did have its own doctype.
> I don't remember when the term javascript was even really used in regular vernacular
2004 or 2005. Gmail and Google Maps were a "holy crap this is actually possible?" for a lot of people, both technical and non, and was when javascript switched from mostly-ignored* to embraced.
*Just minor enhancements, outside of technical people mostly only known to MySpace users who wanted to add a little flair to their page. XmlHttpRequest was almost entirely unknown even in technical spaces until gmail showcased interaction without page refreshes.
What does SHTML stand for?
This is a legacy of old apache configurations, the common mime type configuration files used .html to send the straight file, and .shtml to turn on the server side processing instructions. Server side includes could be static files or executable scripts that generated text on STDOUT. If you were using a lot of server side includes, it was cleaner just to turn on server side parsing for the whole site.
The classical answer is that the S stands for Server-Side-Incude (SSI). SSI source typically uses the extension .shtml. More info:
https://en.wikipedia.org/wiki/Server_Side_Includes
SPAN-HTML, obviously.
It's short for SHiTML.
Please delete this comment. If you're being sarcastic, this is not obvious at all to people who don't know.
Because a lot of web frontend developers are addicted to <div> soup and fancy CSS and JavaScript libraries.
It's also due to browser not doing anything useful with the additional tags, if I use <article>, <section> or <div> doesn't make any difference, my browser doesn't use that to generate a TOC or let me open an <article> in a new Tab. Even the, in theory, incredible useful <time> tag seems to be completely invisible to my browser and many other potentialy useful tags don't exist in the first place (e.g. <unit> would be useful).
> It's also due to browser not doing anything useful with the additional tags,
It's clear that you are sighted and never use reader mode.
Exactly this. I really wish browsers would use semantic html to make content more accessible for me, a sighted user! Why does my browser not give me a table of contents I can use to navigate a long page?
I think the parent has a good point: browsers don't do anything with these tags for sighted users, who are unfortunately the majority of developers. If they were to notice benefits to using semantic tags, maybe they'd use them more often.
Developers of all people should be in a position to notice how tag semantics can keep them oriented in a document or target behavior and styling…
It’s interesting, because if you imagine sites actually using these tags to be maximally compatible with reader mode and other accessibility modes, they’re setting themselves up perfectly to be viewed without ads.
I use reader mode by default in Safari because it’s essentially the ultimate ad blocker: it throws the whole site away and just shows me the article I want to read.
But this is in opposition to what the website owners want, which is to thwart reader mode and stuff as many ads in my way as they can.
It’s possible good accessibility is antithetical to the ad-driven web. It’s no wonder sites don’t bother with it.
Reader mode seems to still work if you have a div with article text in it. I would be interested to see a comparison of what works and what doesn’t if such a reference exists though!
Yes, I think that is what browser should spend money on instead of inventing new syntax. Google Chrome still doesn't support alternate stylesheets. But I refuse to not use them simply because a rich company can't be bothered to implement decades old standards.
Maybe not the browser itself, but in combination with semantic CSS [1], it's incredibly useful.
[1] - eg https://picocss.com/
Not true. Using semantic HTML and relying on its implicit ARIA roles allows the browser to construct an accurate AOM tree (Accessibility Object Model) which makes it possible for screen readers and other human interface software to create TOCs and other landmark-based navigation.
> Not true. Using semantic HTML and relying on its implicit ARIA roles allows the browser to construct an accurate AOM tree (Accessibility Object Model) which makes it possible for screen readers and other human interface software to create TOCs and other landmark-based navigation.
Sure, it allows the browser to do that. GP is complaining that even though browsers are allowed to do all that, they typically don't.
The point of the reply was that they actually do. It's just not obvious that they do if you don't use that method yourself.
We just don't have enough tags that we can really take advantage of on a semantic or programmatic level, and that has lead to other tags getting overloaded and thus losing meaning.
Why don't we just have markup for a table of contents in 2025?
That'd open a whole new can of worms. Browsers are already gargantuan pieces of software even with the relatively primitive tags we have today. We don't need to further argue with each other what the <toc> tag should look and behave like, deal with unforeseen edge cases and someone's special use cases which end up requiring them to implement the whole thing with <ol>s and <li>s anyway.
Then let the edge cases use <ol> and <li>, and in some sense all those website style simplifiers that comes built-in with Safari will just have to deal with those edge cases. Similarly we have a built-in date picker, and if you don't think it's good enough then build a better one.
If you want a specific behavior for <time> then write a browser plugin which e.g. converts the <time> content to your local time.
But if you are a developer you should see value in <article> and <section> keeping your markup much much nicer which in turn should make your tests much easier to write.
Semantic tags were never widely used, even before the overuse of JavaScript.
For anybody wondering, there are 112 of them:
> Update 7 Oct 2025: Some screen readers have been found not to announce updates to the tag, so explicitly emphasising the role attribute might be worthwhile for now until support improves: <output role="status">.
Maybe it's because like most things html/css related, it's a semi-broken implementation of a half-feature?
Maybe because most HTML tags are not well supported by browsers, because they are doing by themselves only half of what a developer would want, hard to style, hard to enhance the native behavior, ... most recently-added tags have those problems (ex: <progress>), this one from 2008 is an even better example
please elaborate, how is <output> a better example for only doing half of what a developer would want? what is missing?
Because no one cares about HTML except as a payload carrier for the real website: the JavaScript output from React/Tailwind/Typescript compilation.
You have to remember, this is an industry that thinks having code without syntax errors was too unreasonable a requirement for XHTML, there is no reason to expect them to know anything beyond div and maybe a dozen other tags.
People who already have a habit of solving a problem a specific way are generally unlikely to switch when a new solution appears unless it is considerably easier. If it's not immediately easier, it will feel easier to continue the ingrained habit.
My guess would be that most people just copy (mimic) what is already there. I sometimes work as a freelance web administrator and I can assure you 95% of people who create websites for a living have never read through a list of HTML tags, have only a slight idea of the semantic web and in the end they are more like people who cobble existing things together and are out of their depth pretty quickly.
Not that this is problematic per se, everybodies milage may vary and we're all out there to learn. But if I told one of them about the output tag thry probably wouldn't even understand why that would be important.
In some cases, because there was a period of time where it might not have been in HTML in all browsers, and javascript was used instead, and then HTML had it.
Then no one checked, and the javascript train had already left the station.
I mean with modern javascript/dom manipulation tools the only tag you really need is div.
In before comments - not advocating for div only development, just that the nature of www moved from html with some js to well ... only js.
Then you might as well use a single instance of the canvas tag.
Doesn't Flutter do exactly that?
For a website speaking accessibility, it does something very bad and annoying with scrolling. Not using the native browser scrolling I think. When I use the middle wheel of my mouse to go up or down, sometimes it suddenly it ignore the command or stutter or go back a little bit instead of continue going down or some random movement. Even with using 2 fingers scroll with the touchpad, I can feel very slightly that there a subtle lag or stutter.
Interestingly I've often seen this in Claude outputs, especially on long prompts. I've assumed this is because of Claude's XML-based instruction format, but this does make me wonder how related the two are. And if Claude may have a harder time using <output> given it's related to both accessibility and its instructions
I suppose claude is trained on the spec and docs like MDN
I don't think this was ignored for no reason or simply forgotten. I don't see it bringing a great feature or value compared to input tag. You still need to code up the logic for setting its value, via a script, like any other container tags. You could pretty much use a read-only input tag to include the output with the form.
> You could pretty much use a read-only input tag to include the output with the form.
You could, but then you wouldn't be gaining any of the accessibility wins the article is discussing...
I have no idea if it was based on the HTML tag, but ColdFusion/CFML has (always?) had the <cfoutput> tag for displaying and parsing dynamic data.
Hell html in 2025 feels so underdeveloped, semantic html should just be declared dead and we should just move on. How many years we wasted by having "experts" underlining the semantic meaning of aside, article, main etc? Good lord, perhaps we should just totally skip the dom and use a graphics, input and accessibility api the way we want
It seems to me that most semantic HTML has helped third parties extract data from web pages for their own use. Perhaps if you are an important primary source of information like a government service that could be useful if it helps you advance your cause of sharing data, but I don’t think it is in the interest of most website operators if it reduces traffic to your site.
I understand that their are some accessibility benefits to some semantic HTML tags.
The discussion of past years instead of being focused on "what we could do next to make developing apps for the web better?" has been focused on which semantic meaning the x tag has and where it should be used, creating just a lot of confusion and disagreements, vs the reality: people just use divs, you can still specify aria attributes there, why not giving us an api to specify semantic meaning as well the way we want? I'd like to have something like flash back, html5 was a step back, partially has already been achieved by flutter and react native. Please Browser vendors just give us a goddman drawing api that doesn't feel limited as canvas is with a semantic, accessibility and input apis that don't suck!
I feel like you’re worked up about a hype that began in 2005 and fizzled out in 2015.
Please tell me then what I've been missing. Modals/Dialogs?
I can see this having extreme value 20 years ago. Then it could take more than a minute to asynchronously get data back and you needed to tell people what content on the page changed.
Now, the bottleneck is entirely the database first and the framework second. Those can be switched if the framework code is extra garbage. When those are taken out of the equation I am seeing text update to the screen in about 5-15ms in response to a user interaction that requires execution on the localhost server, 45ms for networked server.
At that speed you don’t need to alert the user of any content changes. You only need to structure the content such that walking the DOM, using a screen reader, from point of interaction to area of output is direct and logical, expected, for a human.
these days with llms we're back to over a minute to get a response...
I honestly don't know what is it for. Why is it important to have an output tag.
The output of any actions will be shoved into any N random elements. So every `<div>` will have `<output>`? Why? Waste of payload size and CPU cycles in parsing.
The designers of semantic tags truly live in ivory towers.
>When I searched GitHub public repos, it barely showed up at all.
Is there a way to search by code?
That's literally what search does on Github?
Turns out there is a Code Search option, but it's not the default (default is repo names and descriptions). Neat!
Only if you're signed in.
The article was all good until he started to use react for implementation. I would not have done that for an article about web standards, and I use react all the time.
I think the lesson here is if you want to provide an accessibility feature, you have to also make it do something useful for people that don't care about accessibility.
> dynamic results that are announced to screen readers by default.
> It’s been in the spec for years. Yet it’s hiding in plain sight.
Almost as if we're... blind to it?
No? Too on the nose?
Okay
> So why don’t we use it?
Because we don’t need another fucking tag, that’s why.