[HN Gopher] The <output> Tag
___________________________________________________________________
The <output> Tag
Author : todsacerdoti
Score : 682 points
Date : 2025-10-11 08:27 UTC (14 hours ago)
(HTM) web link (denodell.com)
(TXT) w3m dump (denodell.com)
| eps wrote:
| 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."
| skrebbel wrote:
| 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.
| akk0 wrote:
| 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.
| bena wrote:
| Yeah, I knew "aria" was "accessibility stuff", but I
| couldn't tell you what it stood for.
| ChrisSD wrote:
| Tbh I really don't think it matters what the letters
| stand for.
| kaoD wrote:
| 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)
| acka wrote:
| > 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.
| lazide wrote:
| 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.
| kayodelycaon wrote:
| 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.
| skrebbel wrote:
| > * 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.
| Muromec wrote:
| Not knowing about ARIA is like not knowing about
| requirements for ramp slopes when designing a building. You
| just... can't.
| rambambram wrote:
| 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. ;)
| skeeter2020 wrote:
| 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...
| small_scombrus wrote:
| The top of a lot of the ARIA docs pages say "No ARIA is
| better than bad ARIA"
| Muromec wrote:
| 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.
| froobius wrote:
| 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?
| j45 wrote:
| 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.
| atoav wrote:
| 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.
| Timwi wrote:
| 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.
| gregoriol wrote:
| 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
| em-bee wrote:
| please elaborate, how is <output> a better example for only
| doing half of what a developer would want? what is missing?
| ReptileMan wrote:
| 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.
| 1718627440 wrote:
| Then you might as well use a single instance of the canvas
| tag.
| throw-the-towel wrote:
| Doesn't Flutter do exactly that?
| vaylian wrote:
| Because a lot of web frontend developers are addicted to <div>
| soup and fancy CSS and JavaScript libraries.
| grumbel wrote:
| 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).
| kitd wrote:
| Maybe not the browser itself, but in combination with
| semantic CSS [1], it's incredibly useful.
|
| [1] - eg https://picocss.com/
| 1718627440 wrote:
| 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.
| threatofrain wrote:
| 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?
| fleebee wrote:
| 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.
| threatofrain wrote:
| 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.
| sodapopcan wrote:
| > 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.
| crabmusket wrote:
| 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.
| wwweston wrote:
| 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...
| ninkendo wrote:
| 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.
| sefrost wrote:
| 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!
| cluckindan wrote:
| 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.
| lelanthran wrote:
| > 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.
| Vinnl wrote:
| 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.
| runarberg wrote:
| 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.
| diego_sandoval wrote:
| Semantic tags were never widely used, even before the overuse
| of JavaScript.
| Devasta wrote:
| 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.
| meindnoch wrote:
| 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.
| asjo wrote:
| 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
| 1718627440 wrote:
| I think that was known by meindnoch and was a joke.
| throw-the-towel wrote:
| 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.
| bapak wrote:
| Please delete this comment. If you're being sarcastic, this
| is not obvious at all to people who don't know.
| junon wrote:
| Not sure if a joke but this is factually inaccurate.
| wwweston wrote:
| Accurate to some substantial usage, whatever definitional
| inaccuracy or backronym action is in play.
|
| Descriptivism usually reflects some reality no matter the
| intended prescriptives.
| junon wrote:
| No, sorry. It's factually inaccurate. DHTML stood for
| Dynamic HTML, it was an extension before Javascript and
| whatnot was added.
| k33n wrote:
| DHTML is literally just HTML that is dynamically modified
| by JavaScript. DHTML became a term when JavaScript became
| ubiquitous. It was not an extension.
| junon wrote:
| 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.
| k33n wrote:
| 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.
| randallsquared wrote:
| > _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.
| junon wrote:
| That could be. And yeah, DHTML came and went pretty
| quickly even by today's standards.
| Izkata wrote:
| > 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.
| wwweston wrote:
| 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.
| jama211 wrote:
| Man I live for takedowns like these, nice work
| epcoa wrote:
| What does SHTML stand for?
| chuckhoupt wrote:
| 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
| andrewflnr wrote:
| SPAN-HTML, obviously.
| DonHopkins wrote:
| It's short for SHiTML.
| m-hodges wrote:
| Man, I love it when I find a good <table>
|
| https://matthodges.com/posts/2025-09-30-visidata/
| 1718627440 wrote:
| For anybody wondering, there are 112 of them:
| 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
| b_e_n_t_o_n wrote:
| > 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?
| chrismorgan wrote:
| 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.)
| Nevermark wrote:
| > 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.
| Kudos wrote:
| > Not every use of AI replaces a professional artist.
|
| It normalises it.
| llbbdd wrote:
| There is no reality past or present where someone would
| have been paid to make this
| uonr wrote:
| I love those handmade bad sketch
| aruggirello wrote:
| This dodgy GenAI calculator is funny... You can only add,
| multiply and divide. No subtractions allowed!
| austin-cheney wrote:
| 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.
| arccy wrote:
| these days with llms we're back to over a minute to get a
| response...
| NoahZuniga wrote:
| > 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?
| croes wrote:
| 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.
| wizzwizz4 wrote:
| 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.
| cluckindan wrote:
| 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...
| wizzwizz4 wrote:
| 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.
| cluckindan wrote:
| If that were true, no screen readers would work, which is
| not the case.
| wizzwizz4 wrote:
| 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.
| cluckindan wrote:
| You're right, some screen readers work better with
| specific browsers. The article doesn't mention anything
| about that, though.
| egeozcan wrote:
| If on Windows, opening tickets on NVDA repo works wonderfully
| well, as long as they find them valid.
|
| https://github.com/nvaccess/nvda
| lelandfe wrote:
| > _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
| WickyNilliams wrote:
| 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">PS123.45</output>
|
| That way it will be announced like "Total, PS123.45" rather
| than a random number with no context
| skeeter2020 wrote:
| 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/...
| WickyNilliams wrote:
| 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!
| pbhjpbhj wrote:
| 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.
| rglullis wrote:
| Chicken-and-egg. As soon as more websites start using the tag,
| screenreaders will catch up and role=status will not be needed.
| andai wrote:
| >When I searched GitHub public repos, it barely showed up at all.
|
| Is there a way to search by code?
| Etheryte wrote:
| That's literally what search does on Github?
| ameliaquining wrote:
| Only if you're signed in.
| greatgib wrote:
| 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.
| zkmon wrote:
| 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.
| swiftcoder wrote:
| > 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...
| moffkalast wrote:
| > 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?
| redbell wrote:
| > 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?
| mcdonje wrote:
| 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.
| nashashmi wrote:
| Yeah llms don't read docs. They repeat the info in docs. And
| swap letters around the code to make it fit.
| Devasta wrote:
| 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.
| abnercoimbre wrote:
| I was filled with a definite sadness after reading your
| comment. It is what it is.
| didi_bear wrote:
| I actually discovered <output> because Claude generated it !
| lpln3452 wrote:
| 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.
| Clamchop wrote:
| 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.
| ford wrote:
| 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
| stefvw93 wrote:
| I suppose claude is trained on the spec and docs like MDN
| IshKebab wrote:
| 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.
| c-smile wrote:
| 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.
| zdragnar wrote:
| 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?
| c-smile wrote:
| 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...
| dclowd9901 wrote:
| 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.
| zdragnar wrote:
| 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?
| c-smile wrote:
| <output type="currency">123456.00</output> formats output
| using _user 's_ settings: https://www.elevenforum.com/att
| achments/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.
| Muromec wrote:
| 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.
| TRiG_Ireland wrote:
| 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.
|
| EUR1,000.48 = 1.000,48EUR
| kortilla wrote:
| But if it's just formatting, how is that different from
| the "number" type?
| graftak wrote:
| Different rule set
| paulddraper wrote:
| !!!
|
| 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.
| austin-cheney wrote:
| 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.
| Pikamander2 wrote:
| > 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.
| abustamam wrote:
| 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.
| Muromec wrote:
| On all the projects I worked that involved ui elements
| library, datepicker consistently was the biggest pain in
| the ass, rivaled only by modals.
| dawnerd wrote:
| Modals at least are a solved problem these days.
| paradox460 wrote:
| 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
| c-smile wrote:
| Also, if to allow form.value to accept JSON-ish objects it will
| be possible to set form values in single shot:
| form.value = { transAmount: 12345n, transDate: new Date() };
|
| where form is <form> ... <output
| type="currency" name="transAmount" /> ... <output
| type="date-local" name="transDate" /> </form>
| DangerousPie wrote:
| It's still better than <span> or <div> though, isn't it? Which
| is what most people are using right now...
| c-smile wrote:
| "better" in what sense? If in hypothetical semantic meaning
| then another old zombie <var> is better in that sense, isn't
| it?
| samhh wrote:
| Those semantics make it more accessible for free.
| runarberg wrote:
| Unlike <div> and <span>, <output> becomes part of the form
| and you can target it as a named form item, e.g.
| <form id="my-form"> <input name="number"
| type="number"> <output name="result"></output>
| </form> <script> const myForm =
| document.getElementById("my-form"); const
| inputField = document.elements.namedItem("number");
| const outputField = document.elements.namedItem("result");
| outputField.textContent = inputField.valueAsNumber ** 2;
| </script>
| runarberg wrote:
| It is trivial to do that with JavaScript as you fill in the
| content of <output> using Intt, e.g. const
| outputEl = document.getElementById("my-output"); const
| currencyFormat = new Intl.NumberFormat("default", {
| style: "currency", currency: "ISK", });
| outputEl.textContent = currencyFormat.format(value);
|
| https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
| chrisweekly wrote:
| 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.
| runarberg wrote:
| 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]).
| its-summertime wrote:
| I'd prefer: <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)
| SoftTalker wrote:
| 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.
| spankalee wrote:
| 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.
| Pxtl wrote:
| That's basically the story with every browser feature. How did
| we get to the point that everything is built for this awful
| platform?
| SvenL wrote:
| 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.
| kortilla wrote:
| 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.
| Muromec wrote:
| It formats numbers and that's it, it doesn't know what
| currency it is and doesn't try to guess.
| spankalee wrote:
| 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: <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.
| sto11z wrote:
| 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.
| bdcravens wrote:
| 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.
| hn_throw_bs wrote:
| > So why don't we use it?
|
| Because we don't need another fucking tag, that's why.
| ty_2k wrote:
| I have completed multiple courses on front-end web accessibility
| and never run into <output>, somehow. Thanks so much for the
| awesome share.
| throw_m239339 wrote:
| 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.
| hollowturtle wrote:
| 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
| sefrost wrote:
| 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.
| hollowturtle wrote:
| 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!
| skrebbel wrote:
| I feel like you're worked up about a hype that began in
| 2005 and fizzled out in 2015.
| hollowturtle wrote:
| Please tell me then what I've been missing.
| Modals/Dialogs?
| Hadimns57 wrote:
| Okay
| didip wrote:
| 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.
| mgraczyk wrote:
| 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.
| hk1337 wrote:
| 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]">
___________________________________________________________________
(page generated 2025-10-11 23:00 UTC)