Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make number's and <input>'s get along better #9172

Closed
ghost opened this issue Apr 14, 2023 · 2 comments
Closed

Make number's and <input>'s get along better #9172

ghost opened this issue Apr 14, 2023 · 2 comments

Comments

@ghost
Copy link

ghost commented Apr 14, 2023

In the js world, numbers are dressed one way - the western way (which I'm quite thankful for). In the real world, people dress up numbers in all sorts of ways. I'm talking Intl.NumberFormat kinds of ways. When you want to go from a js number to an everybody number, easy! Just use Intl.NumberFormat. But when you want to go from an everybody number to a js number - good luck.

I understand the traditional solution has been to use <input type="text" /> and let the developers handle it, but most developers speak one or two languages, which makes the world wide web number-fractured. Numbers make the world go 'round. It would seem to me that everybody would benefit from an internationalized, flexible <input type="intl-numeric" /> or perhaps a more pure element like <number /> where users can enter the number according to their locale, developers have sensible handles to do developery things like specify the intent/styling of the number (like the second argument of Intl.NumberFormat) and dynamically delegate to their own parsers for implementing excel-like functionalities such as calculator.

This would be a massive undertaking, but in the end browsers would be able to intimately understand numbers from all people, languages, and relevant contexts. I would imagine this would amount to increased revenue for browser implementers once companies can easily support data entry on a international scale. The whole world speaks quantities - can browsers interpret?

@bathos
Copy link

bathos commented Apr 15, 2023

HTML doesn’t prescribe specific UI affordances for the number-type input, it only defines the generic semantics and observable behaviors. Realization of the “inner widget” is up to the agent. A note points out that it follows that agents are free to localize/internationalize as they see fit to best meet end user needs:

This specification does not define what user interface user agents are to use; user agent vendors are encouraged to consider what would best serve their users' needs. For example, a user agent in Persian or Arabic markets might support Persian and Arabic numeric input (converting it to the format required for submission as described above). [...]

I suspect the core of what you described would not be a specification concern but rather a feature request for browser vendors that aren’t currently doing number input localization. HTML similarly doesn’t specify things like what calendar to display in a date input’s drop down (if it has one) or what day of the week to use for its first column, etc — if something isn’t observable through any API, it’s usually the agent’s business, not the spec’s.

@domenic
Copy link
Member

domenic commented Apr 15, 2023

@bathos's response is perfect, and as spec editor, I have nothing to add. If you would like browsers to create better UIs for <input type=number>, please file browser bugs as he suggests. I'll close this issue since the HTML Standard already supports what you want.

@domenic domenic closed this as completed Apr 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants