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
{{ message }}
This repository has been archived by the owner on Jul 30, 2019. It is now read-only.
User agents must not allow the user to set the value to a non-empty string that is not a valid floating-point number.
This is not a user-friendly requirement (I'm referring to end-users here, not developers). A core usability concept is that when a user gives an interface input (for example via a keyboard) that the interface responds to the user. Ideally the response will be what the user expected (a character appears in the input), or if not, some kind of feedback to explain what went wrong. In this case a user, presented with what appears to be a text input, will get no feedback of any kind if they type the 'wrong' characters (most of them).
The characters allowed are esoteric - the majority of users will not know what characters are allowed in a 'floating point number' - which includes 'e'.
Another aspect to this is browser support. In my testing it seems like only Chrome actually respects this requirement, with other browsers allowing any characters, presumably due to the usability issues mentioned.
The text was updated successfully, but these errors were encountered:
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, when displaying a page in the Persian or Arabic languages, a form might support Persian and Arabic style numeric input (converting it to the format required for submission as described above). Similarly, a user agent showing a page in a French locale might display the value with apostrophes between thousands and commas before the decimals, and allow the user to enter a value in that manner, internally converting it to the submission format described above
So, do UK users expect to be able to enter 1,234.56? or -789 or +123? That's 4 non-numeric characters which might be in everyday use.
Unlike the URL and E-mail types, the Telephone type does not enforce a particular syntax. This is intentional; in practice, telephone number fields tend to be free-form fields, because there are a wide variety of valid phone numbers.
1-800-STAR-WARS is valid, as is +442079460123,5#;*
Which leads us to
Systems that need to enforce a particular format are encouraged to use the pattern attribute or the setCustomValidity() method to hook into the client-side validation mechanism.
So, if you just wanted plain numbers, with decimals, but nothing else, you could use
The current spec for type="number" says:
This is not a user-friendly requirement (I'm referring to end-users here, not developers). A core usability concept is that when a user gives an interface input (for example via a keyboard) that the interface responds to the user. Ideally the response will be what the user expected (a character appears in the input), or if not, some kind of feedback to explain what went wrong. In this case a user, presented with what appears to be a text input, will get no feedback of any kind if they type the 'wrong' characters (most of them).
The characters allowed are esoteric - the majority of users will not know what characters are allowed in a 'floating point number' - which includes 'e'.
Another aspect to this is browser support. In my testing it seems like only Chrome actually respects this requirement, with other browsers allowing any characters, presumably due to the usability issues mentioned.
The text was updated successfully, but these errors were encountered: