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.

> 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.

It's the one place we still use user-agent sniffing: if the built in date picker works we show that (iPhone / iPad), otherwise we do a JS picker.

Wait which browsers can’t support html5 date field?

It's not a question of support, it's a question of consistency. I don't remember the details, I just remember it was barely usable on one of my coworkers device/browsers. It worked, for some definition of the word, but it was not intuitive.

https://caniuse.com/input-datetime

The one that gets me is the fact that there's no user-editable combobox. There's a select drop down, and "input + datalist" (and that doesn't help when there's effectively 0 hint about what the things you can use actually are), but no way to have the two combined.

It's actually a little surprising to me since these are somewhat basic controls that have been around in UI toolkits for decades. It's in that weird sweet spot where the building blocks are almost usable enough to build rich applications, but it's just out of reach.

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.

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)

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...

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>

Too late to edit, but there is a mistake s/document.elements/myForm.elements/r :

    -   const inputField = document.elements.namedItem("number");
    -   const outputField = document.elements.namedItem("result");
    +   const inputField = myForm.elements.namedItem("number");
    +   const outputField = myform.elements.namedItem("result");

"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.

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.

In en-AU locale, I’d prefer AU$ or AUD too - because you can just never be sure what you are dealing with - my work pays for me to use a coworking space not far from my house, and the app we use shows the price in US dollars, and doesn’t even mark it as US$ or USD, just plain $, I’m expected to know what it means. I’ve seen hotel sites quote amazingly cheap deals for hotel rates in Australia, only to realise they were quoting me USD (without clearly marking it as such), despite the fact that I was searching for a hotel in Australia from within Australia. In today’s global economy, you can’t go wrong by always being explicit about which currency you are using.

Maybe if we had <output type=“currency”> there would be fewer such snafus

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.

Top personal issue, be nice if it could just attach to an <input> and list the result. Like:

  <input type="range" id="example_id" name="example_nm" min="0" max="50">
  <output name="example_result" for="example_id"></output>

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 name="result">
  <form oninput="result.value=...">

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...

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]).

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.

It formats numbers and that's it, it doesn't know what currency it is and doesn't try to guess.

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>

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.

Every other platform tends to be either worse, locked or both.