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
