Skip to content
This repository has been archived by the owner on Jul 30, 2019. It is now read-only.

Reconsider the behaviour for type="number" - restricting input #1355

Closed
joelanman opened this issue Apr 10, 2018 · 1 comment
Closed

Reconsider the behaviour for type="number" - restricting input #1355

joelanman opened this issue Apr 10, 2018 · 1 comment
Assignees
Milestone

Comments

@joelanman
Copy link

joelanman commented Apr 10, 2018

The current spec for type="number" says:

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.

@edent
Copy link
Member

edent commented Apr 10, 2018

Just for a bit of background...

Quoting from W3C Spec

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.

The flip side of this is input type="telephone"

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

<input type="text"   pattern="[-+]?[0-9]*[.,]?[0-9]+" >

@chaals chaals added this to the HTML5.3 WD5 milestone Jun 19, 2018
edent added a commit that referenced this issue Jul 4, 2018
Improve the explanation in the note.  Make the link to pattern more obvious.

Fixes #1355
LJWatson pushed a commit that referenced this issue Jul 4, 2018
Improve the explanation in the note.  Make the link to pattern more obvious.

Fixes #1355
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants