Comment by c-smile

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>

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

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>

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)

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

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?

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>

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);

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.

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() };

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