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

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.

As others have explained, zip codes and credit cards are strings composed
of digits, not numbers, and should thus use type=text. If, for example,
you enter '0035', it needs to be processed as '0035' not '35' or '35.00'.
For a number, they are all equivalent. For things like credit card numbers
and postal codes, they probably aren't.

The spec could perhaps benefit from an example of how /not/ to use
type=number here...

~fantasai

Received on Monday, 13 February 2012 07:31:30 UTC