[whatwg] Why isn't the "pattern" attribute applied to <input type="number">?
ms2ger at gmail.com
Fri Feb 10 02:49:43 PST 2012
On 02/10/2012 11:39 AM, brenton strine wrote:
> Regarding the an input with type in the "number" state, the spec states
> that the "pattern" attribute "must not be specified and do[es] not
> the element". (
> Why is it specifically blocked? Doesn't that encourage the use of a less
> semantic "text" input type for numbers that need to be validated beyond
> simple max and min?
> What if you want the number to be either 13 or 16 digits long, as with a
> credit card
> or you want a US ZIP or ZP4 code which can either be nnnnn or nnnnn-nnnn
> To get the pattern to validate, I have to (non-semantically) change the
> input to the text state? I much prefer the current behavior of Firefox
> (tested 9 and 10) which does validate the pattern.
Using input type=number for those cases is wrong. You would not use a
credit card number or a ZIP code in calculations. (In fact, in the
United Kingdom, post codes contain letters.)
input type=number is meant to be used for numbers, rather than for
strings that happen to contain mostly numbers. The specification does
indeed require a *more* semantically correct input type=text for those
The reason that Firefox validates the pattern is that it currently does
not implement input type=number (patches welcome). Instead, it
implements the fallback behaviour defined in the specification, i.e.,
treat unknown 'type' values as 'text'—which causes the pattern attribute
to apply. Using input type=number pattern=... will break as soon as
Firefox correctly implements the feature.
More information about the whatwg