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
