You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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.
@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.
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 useIntl.NumberFormat
. But when you want to go from an everybody number to a jsnumber
- 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 ofIntl.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?
The text was updated successfully, but these errors were encountered: