[c-smile]

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.

[spankalee]

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.

[Pikamander2]

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

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.

[jkrejcha]

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.

[paradox460]

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

[sto11z]

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.

[its-summertime]

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]

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.

[DangerousPie]

It's still better than <span> or <div> though, isn't it? Which is what most people are using right now...

[runarberg]

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>

[c-smile]

"better" in what sense? If in hypothetical semantic meaning then another old zombie <var> is better in that sense, isn't it?

[zdragnar]

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]

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

[paulddraper]

!!!

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]

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.

[araes]

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

[runarberg]

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]

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.

[kortilla]

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]

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

[c-smile]

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>

[Pxtl]

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]

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.

[delian66]

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