Hacker Newsnew | past | comments | ask | show | jobs | submit | c-smile's commentslogin

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.


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.


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


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.


On all the projects I worked that involved ui elements library, datepicker consistently was the biggest pain in the ass, rivaled only by modals.


Modals at least are a solved problem these days.


It's the one place we still use user-agent sniffing: if the built in date picker works we show that (iPhone / iPad), otherwise we do a JS picker.


Wait which browsers can’t support html5 date field?


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


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.


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


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


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.


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.


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


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>


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


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


Those semantics make it more accessible for free.


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?


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


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.


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?


<output type="currency">123456.00</output> formats output using user's settings: 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.


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.


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€


But if it’s just formatting, how is that different from the “number” type?


Different rule set


!!!

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.


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.


Maybe if we had <output type=“currency”> there would be fewer such snafus


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.


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


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


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.


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


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.


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


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>


That's basically the story with every browser feature. How did we get to the point that everything is built for this awful platform?


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.


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


I used to have NEC MobilePro 900 like here: https://live.staticflickr.com/213/481422006_92cdaeb6ee_b.jpg

I miss that form factor really.

And BTW, I regret that WindowsCE is not the thing anymore. IMO it has the best development infrastructure out there backed with MSVC IDE.

I classify OSes into two major groups: "writer OS" (all desktop OSes primarily) and "reader OS" (all mobiles). But there is a void in between for palmtop form factor devices.

Sigh, probably its only me who needs this ...


You may like this: https://kingjim.us/products/pomera-full-suite-typewriter-for...


Or a reMarkable with the addon keyboard!


Judging by eBay prices for Psions, you’re not the only one who misses that form factor.


Well, Highlight API ( https://developer.mozilla.org/en-US/docs/Web/API/Highlight ) should just work inside <textarea> too.

At least it works in my Sciter like this:

    <style>
      textarea::mark(myHighlight) {
        background-color: yellow;
        color: red;
      }
    </style>
    <body>
       <textarea>Lorem ipsum dolor sit amet</textarea>
    </body>
    <script>

      // Select a range of text to highlight
      const range = document.createRange();
      const textNode = document.querySelector('textarea').firstChild; 

      range.setStart(textNode, 6); // Start at the 6th character
      range.setEnd(textNode, 11); // End at the 11th character

      // Highlight the range
      range.highlight("myHighlight")

    </script>
Ask your browser vendor to enable highlight API in <textarea> too :) so such tricks will not be required.


DOM per se, as a tree of elements, is not that bad. CSS is also not that bad in general.

Their API is probably the problem. Not modular so makes the mess.

Options to modularize them:

DOM, concept of interfaces/behaviors rather than inheritance leading to huge maps. Let say for <textarea> we may have separate "textarea" interface:

   element.tagName
   ... and the rest of DOM-as-a-tree methods ...
   element.textarea // <textarea> specific interface of its behavior
   element.textarea.select(startEnd) // interface method
   element.textarea.selectionStart // interface prop
   element.textarea.selectionEnd // interface prop
   element.textarea.rows // interface prop
   element.textarea.columns // interface prop
   ...
CSS, that huge flat table is a nightmare, not just because of its size, but because of extensibility problems right now and in the future. Example, all CSS grid related properties should rather go to their own namespace:

   section {
     color: red;
     // ... and other basic CSS 2.1 props

     display: grid(
       rows: ...;
       columns: ...;
       align-items: center;
       justify-items: start
     );
   }
So different layouts ( like display:flex(), display:waterfall() ) may have their own rows, columns, etc.

As sooner we will do that - the better. API is on the brink of collapsing / combinatorial explosion, indeed.


Why does it matter? Its not like im doing a for..in loop over Element objects.


From the very beginning in Sciter an Image can be constructed in two ways at runtime ( other than just getting loaded image reference):

1. By painting on it using Canvas/Graphics API:

    new Graphics.Image(width, height, painter(graphics) [,initColor]);
Where _painter_ is a function used for paining on the image surface using Canvas/Graphics reference.

2. By making snapshot of the existing DOM element:

    new Graphics.Image(width, height, element [,initColor])
Such images can be used in DOM, rendered by other Canvas/Graphics as also in WebGL as textures.

See: https://docs.sciter.com/docs/Graphics/Image#constructor


Consider <textarea> that has resizing handle on the corner (try to reply to this message to see it alive). And now try to imagine how would you render those diagonal lines in HTML/CSS ?

While in Sciter, that has such immediate mode rendering form the very beginning, you can simply draw them as:

   resizableElement.paintForeground = function(gfx) { // draw on top of background & content

      let box = this.getBoundingClientRect();
      gfx.moveTo(...); gfx.lineTo(...);
      gfx.moveTo(...); gfx.lineTo(...);
      ...
   }
Easy, right? And does not need to modify DOM and place artificial positioned elements.


> "Includes" functionality is considered to be server-side

Exactly! Include makes perfect sense on server-side.

But client-side include means that the client should be able to modify original DOM at unknown moment of time. Options are

1. at HTML parse time (before even DOM is generated). This requires synchronous request to server for the inclusion. Not desirable.

2. after DOM creation: <include src=""> (or whatever) needs to appear in the DOM, chunk loaded asynchronously and then the <include> DOM element(sic!) needs to be replaced(or how?) by external fragment. This disables any existing DOM structure validation mechanism.

Having said that...

I've implemented <include> in my Sciter engine using strategy #1. It works there as HTML in Sciter usually comes from local app resources / file system where price of issuing additional "get chunk" request is negligible.

See: https://docs.sciter.com/docs/HTML/html-include


yEd, for those of us who knows word "Visio"

https://www.yworks.com/products/yed


Interesting timing...

I've just made something similar but with JS: C modules in JS.

    import * as CModule from "./module.c";
C module gets compiled to native code on load. I think that clear separation of execution models is a good thing.

https://sciter.com/c-modules-in-sciter/

https://sciter.com/here-we-go/


Slightly orthogonal...

In my Sciter, that uses QuickJS (no JIT), instead of JIT I've added C compiler. That means we can add not just JS modules but C modules too:

   import * as cmod from "./cmodule.c"
Such cmodule will be compiled and executed on the fly into native code. Idea is simple each language is good for specific tasks. JS is flexible and C is performant - just use right tool that is most optimal for a task.

c-modules play two major roles: FFI and number crunching code execution.

Sciter uses TCC compiler and runtime.

In total size of QuickJS + TCC binary bundle 500k + 220k = 720k.

For the comparison: V8 is of 40mb size.

https://sciter.com/c-modules-in-sciter/ https://sciter.com/here-we-go/


Interesting project! After clicking around on the website:

> In almost 10 years, Sciter UI engine has become the secret weapon of success for some of the most prominent antivirus products on the market: Norton Antivirus and Internet Security, Comodo Internet Security, ESET Antivirus, BitDefender Antivirus, and others.

What an intriguingly specific niche of customer! How come all these different anti-virus companies decided to use your platform?


> anti-virus companies decided to use your platform?

One of the reasons: AV application should look modern to give an impression that the app is adequate to modern threats. So while app backend is relatively stable, its UI shall be easily tweakable. CSS/HTML is good for that.

Check this: https://sciter.com/wp-content/uploads/2018/06/n360.png


I actually really love it. Typically AV products UIs feel snappy and lightweight and it is the backend engine that does most of the work and feels horrendously as a bottleneck. Which I think is an interesting phenomena when considering modern desktop applications where typically the backend code does very little and the frontend one is the one being bloated (Electron).

It's a bit sad that there is not a lot of talk and re-usable components from these companies for Sciter that can help us create snappy apps!


Even if I am not a big C fan, the idea is rather cool, it is a bit like having C++ on .NET via C++/CLI.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: