> 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>
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.
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.
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.
<output for=input>
<!-- bring your own time-locale component -->
<time is=time-locale datetime=2001-02-03>2001-02-03</time>
</output>
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)
There have been a bunch of requests for Intl-driven related elements in HTML, and I expect them to be added at some point.
<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> - const inputField = document.elements.namedItem("number");
- const outputField = document.elements.namedItem("result");
+ const inputField = myForm.elements.namedItem("number");
+ const outputField = myform.elements.namedItem("result");<output type="currency"> uses the same convention as "Intl.NumberFormat/style=currency": https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
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.
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?
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.
€1,000.48 = 1.000,48€
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.
<input type="range" id="example_id" name="example_nm" min="0" max="50">
<output name="example_result" for="example_id"></output>
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=..."> const outputEl = document.getElementById("my-output");
const currencyFormat = new Intl.NumberFormat("default", {
style: "currency",
currency: "ISK",
});
outputEl.textContent = currencyFormat.format(value);
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]).
form.value = { transAmount: 12345n, transDate: new Date() };
<form>
... <output type="currency" name="transAmount" />
... <output type="date-local" name="transDate" />
</form>
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.