← Back to context

Comment by c-smile

3 days ago

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.

43 comments

c-smile

Reply
spankalee  2 days ago

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  3 days ago

> 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  2 days ago

    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  1 day ago

    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  2 days ago

    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  2 days ago

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  3 days ago

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  2 days ago

    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  2 days ago

      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.

DangerousPie  3 days ago

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

  • runarberg  3 days ago

    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  2 days ago

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

  • c-smile  3 days ago

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

zdragnar  3 days ago

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  3 days ago

    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  3 days ago

      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.

      6 replies →

  • paulddraper  2 days ago

    !!!

    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.

    • skissane  2 days ago

      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.

      1 reply →

  • austin-cheney  2 days ago

    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  2 days ago

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  3 days ago

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  3 days ago

    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  3 days ago

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

kortilla  2 days ago

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  2 days ago

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

c-smile  3 days ago

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  3 days ago

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  2 days ago

    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.