{"action":"created","issue":{"url":"https://api.github.com/repos/whatwg/html/issues/1086","repository_url":"https://api.github.com/repos/whatwg/html","labels_url":"https://api.github.com/repos/whatwg/html/issues/1086/labels{/name}","comments_url":"https://api.github.com/repos/whatwg/html/issues/1086/comments","events_url":"https://api.github.com/repos/whatwg/html/issues/1086/events","html_url":"https://github.com/whatwg/html/issues/1086","id":150123471,"number":1086,"title":"Allow pattern attribute on input type=\"number\"","user":{"login":"AshleyScirra","id":768723,"avatar_url":"https://avatars.githubusercontent.com/u/768723?v=3","gravatar_id":"","url":"https://api.github.com/users/AshleyScirra","html_url":"https://github.com/AshleyScirra","followers_url":"https://api.github.com/users/AshleyScirra/followers","following_url":"https://api.github.com/users/AshleyScirra/following{/other_user}","gists_url":"https://api.github.com/users/AshleyScirra/gists{/gist_id}","starred_url":"https://api.github.com/users/AshleyScirra/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/AshleyScirra/subscriptions","organizations_url":"https://api.github.com/users/AshleyScirra/orgs","repos_url":"https://api.github.com/users/AshleyScirra/repos","events_url":"https://api.github.com/users/AshleyScirra/events{/privacy}","received_events_url":"https://api.github.com/users/AshleyScirra/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":6,"created_at":"2016-04-21T16:26:31Z","updated_at":"2016-04-22T20:52:19Z","closed_at":null,"body":"The `pattern` attribute has no effect on number inputs. However some browsers appear to use a pattern anyway to enforce number input only, judging by the error Chrome reports when trying to assign something else: `The value must match to the following regular expression: -?(\\d+|\\d+\\.\\d+|\\.\\d+)([eE][-+]?\\d+)?`\r\n\r\nIt would be useful to allow a custom pattern for number inputs for several use cases:\r\n\r\n - currencies: the number input could allow `€100`, `0.50$`, `£5` etc\r\n - include a symbol for units, e.g. `25%`, `45°` etc\r\n - allow custom separators, e.g. `10 000`, `10,000` etc\r\n - allow entering calculations, e.g. `1+1`, `1920/2` etc\r\n\r\nCurrently all of these use cases require using input type=\"text\", which has two drawbacks:\r\n\r\n - on mobile, it reverts to a normal full keyboard instead of a number pad\r\n - on desktop, most browsers show a spinner control for \"number\" inputs, which aren't shown with \"text\"\r\n\r\nThis does raise some issues:\r\n\r\n1. What keyboard should be shown on mobile?\r\n - I suggest keeping it the same (number pad) - it still works for all the use cases above.\r\n2. What should the value be if it contains characters e.g. `$100`?\r\n - The `value` attribute is a string anyway, so this can simply return the full string. It's up to Javascript to parse it correctly, which developers are opting-in to doing by specifying a custom pattern. `valueAsNumber` could also return a number parsed by simply filtering all valid numerical characters and calling `parseFloat()` on the result. This works for all the use cases above except calculations, where the number will be calculated by Javascript separately anyway.\r\n3. What should happen when the spinners are clicked?\r\n - I suggest using the same filtering mechanism to parse out a number, which can then be incremented or decremented and set back as the new value. This does have the effect of turning e.g. `$100` in to `101` rather than `$101`, but the browser probably can't know how to do that automatically. Again this can be solved in Javascript by listening for change events and re-applying the correct formatting.\r\n\r\nNot specifying a pattern would work identically to how it does at the moment, so this would be as backwards-compatible as possible."},"comment":{"url":"https://api.github.com/repos/whatwg/html/issues/comments/213584924","html_url":"https://github.com/whatwg/html/issues/1086#issuecomment-213584924","issue_url":"https://api.github.com/repos/whatwg/html/issues/1086","id":213584924,"user":{"login":"domenic","id":617481,"avatar_url":"https://avatars.githubusercontent.com/u/617481?v=3","gravatar_id":"","url":"https://api.github.com/users/domenic","html_url":"https://github.com/domenic","followers_url":"https://api.github.com/users/domenic/followers","following_url":"https://api.github.com/users/domenic/following{/other_user}","gists_url":"https://api.github.com/users/domenic/gists{/gist_id}","starred_url":"https://api.github.com/users/domenic/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/domenic/subscriptions","organizations_url":"https://api.github.com/users/domenic/orgs","repos_url":"https://api.github.com/users/domenic/repos","events_url":"https://api.github.com/users/domenic/events{/privacy}","received_events_url":"https://api.github.com/users/domenic/received_events","type":"User","site_admin":false},"created_at":"2016-04-22T20:52:19Z","updated_at":"2016-04-22T20:52:19Z","body":"> There's also backwards-compatibility: if all number inputs across the web suddenly start accepting $ and % characters for example, then suddenly you can type unexpected values and all sorts of form validation/JS code/server-posted values could break.\r\n\r\nThere's a difference between what's displayed in the UI, and what's reflected to JavaScript and to the server upon form submission. From https://html.spec.whatwg.org/multipage/forms.html#concept-fe-value:\r\n\r\n> For instance, if a user enters the word \"three\" into a numeric field that expects digits, the user's input would be the string \"three\" but the control's value would remain unchanged. Or, if a user enters the email address \"  awesome@example.com\" (with leading whitespace) into an email field, the user's input would be the string \"  awesome@example.com\" but the browser's UI for email fields might translate that into a value of \"awesome@example.com\" (without the leading whitespace)."}}