[whatwg] Why isn't the "pattern" attribute applied to <input type="number">?

[Ms2ger]

Hi Brenton,

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
> apply<http://dev.w3.org/html5/spec/common-input-element-attributes.html#do-not-apply>
> to
> the element". (
> http://dev.w3.org/html5/spec/states-of-the-type-attribute.html#number-state-type-number
> )
>
> 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
>
> pattern="(\d{5}([\-]\d{4})?)"
>
> or you want a US ZIP or ZP4 code which can either be nnnnn or nnnnn-nnnn
>
> pattern="(\d{5}([\-]\d{4})?)"
>
> 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 
cases.

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.

HTH
Ms2ger