W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2012

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

From: fantasai <fantasai.lists@inkedblade.net>
Date: Mon, 13 Feb 2012 16:31:30 +0100
Message-ID: <4F392CD2.6090906@inkedblade.net>
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...

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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:39 UTC