5 ms·

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

• zdragnar 11mo 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 11mo 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/Reference/Global_Objects/Intl/NumberFormat https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
    • dclowd9901 11mo 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.
      • zdragnar 11mo ago
        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?
        • TRiG_Ireland 11mo ago
          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€
        • c-smile 11mo ago
          <output type="currency">123456.00</output> formats output using user's settings: https://www.elevenforum.com/attachments/currency_format_control_panel-2-webp.141797/ 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.
          • Muromec 11mo ago
            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.
      • kortilla 11mo ago
        But if it’s just formatting, how is that different from the “number” type?
        • graftak 11mo ago
  • paulddraper 11mo 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 11mo 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.
      • paulddraper 11mo ago
        Maybe if we had <output type=“currency”> there would be fewer such snafus
  • austin-cheney 11mo 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.
• Pikamander2 11mo 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 11mo 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.
    • Muromec 11mo ago
      On all the projects I worked that involved ui elements library, datepicker consistently was the biggest pain in the ass, rivaled only by modals.
      • dawnerd 11mo ago
        Modals at least are a solved problem these days.
    • VladVladikoff 11mo ago
      Wait which browsers can’t support html5 date field?
      • abustamam 11mo ago
        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 https://caniuse.com/input-datetime
• c-smile 11mo 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>
• DangerousPie 11mo ago
  It's still better than <span> or <div> though, isn't it? Which is what most people are using right now...
  • c-smile 11mo ago
    "better" in what sense? If in hypothetical semantic meaning then another old zombie <var> is better in that sense, isn't it?
    • samhh 11mo ago
      Those semantics make it more accessible for free.
  • runarberg 11mo 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 11mo 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");
• runarberg 11mo 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/Reference/Global_Objects/Intl/NumberFormat/NumberFormat https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
  • chrisweekly 11mo 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 11mo 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]).
• its-summertime 11mo 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 11mo 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 11mo 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.
• Pxtl 11mo 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 11mo 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.
  • delian66 11mo ago
    Every other platform tends to be either worse, locked or both.
• kortilla 11mo 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 11mo ago
    It formats numbers and that's it, it doesn't know what currency it is and doesn't try to guess.
• spankalee 11mo 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.
• sto11z 11mo 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.
• araes 11mo 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=...">