Allow pattern attribute on input type="number"

[AshleyScirra]

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+)?

It would be useful to allow a custom pattern for number inputs for several use cases:

• currencies: the number input could allow €100, 0.50$, £5 etc
• include a symbol for units, e.g. 25%, 45° etc
• allow custom separators, e.g. 10 000, 10,000 etc
• allow entering calculations, e.g. 1+1, 1920/2 etc

Currently all of these use cases require using input type="text", which has two drawbacks:

• on mobile, it reverts to a normal full keyboard instead of a number pad
• on desktop, most browsers show a spinner control for "number" inputs, which aren't shown with "text"

This does raise some issues:

1. What keyboard should be shown on mobile?
   • I suggest keeping it the same (number pad) - it still works for all the use cases above.
2. What should the value be if it contains characters e.g. $100?
   • 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.
3. What should happen when the spinners are clicked?
   • 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.

Not specifying a pattern would work identically to how it does at the moment, so this would be as backwards-compatible as possible.

[domenic]

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

I don't believe this has anything to do with the pattern attribute. Browsers use regular expressions, sure, but they don't use the pattern attribute.

It would be useful to allow a custom pattern for number inputs for several use cases:

It sounds like what you're asking for here is not really related to custom patterns, but related to browser UI. You wish browsers allowed different ways of entering things in number inputs than just allowing numbers.

This is already allowed by the spec, however. The spec makes no judgments on browser UI: a number field could be a textbox with spinners, something with a slider, or something where you type words like "one thousand and forty three", or something where you type things like "$0.50" or "123 USD". The spec doesn't control that.

It sounds like you're interested in getting browsers to update their UI, which is probably best done via browser issue trackers.

[AshleyScirra]

I see your point about what the spec doesn't say, but I think the main purpose of my suggestion is the current behavior most browsers do of only allowing numerical input is also itself a valid and common use case so some developers would prefer to turn off these new features. 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. I think this alone is motivation enough for browser makers to say they won't change it, hence the need for some other separate feature to allow this.

Maybe instead there could be a new more relaxed input type, e.g. input type="numerical", specifically intended for use cases like currency etc.? From a web search/looking at StackOverflow it looks like a common problem.

[annevk]

It sounds like you want inputmode=numeric which is part of the standard. Not sure about implementations.

[AshleyScirra]

@annevk - oh, I didn't know about that attribute - could browsers also use it to show a spinner?

[annevk]

If they wanted to, I suppose.

[domenic]

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.

There'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:

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).

[domenic]

I think we can close this, because there's nothing for the spec to do here; it already allows the desired flexibility, and it's simply up to browsers to decide if they want to work on their <input type="number"> or <input inputmode="numeric"> implementations to behave with the UX @AshleyScirra describes. Feel free to refer to this thread when filing feature requests on browser issue trackers!