Re: [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
applyhttp://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 n or n-
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
Re: [whatwg] Why isn't the pattern attribute applied to input type=number?
On 02/10/2012 05:49 AM, Ms2ger wrote:
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
applyhttp://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 n or n-
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.)
Ms2ger is correct. What you want is something like proposed in this bug:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=12885
--
Mounir
[whatwg] Why isn't the pattern attribute applied to input type=number?
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
applyhttp://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 n or n-
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.
Brenton Strine
Re: [whatwg] Why isn't the pattern attribute applied to input type=number?
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
applyhttp://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 n or n-
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
Re: [whatwg] Why isn't the pattern attribute applied to input type=number?
2012-02-10 12:39, 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 to the element.
That’s because the pattern attribute is for constraining text data using
a regular expression.
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?
A regular expression, which operates on texts, is not a _logical_ way to
set constraints on _numbers_. A number is a mathematical entity; a
numeral, such as 2000 or 2.000 or 2,000 or MM, is a textual presentation
of a number.
At a more concrete level, type=number really means type=spinbox, but
modern design of markup languages favors names that look more semantic.
(If type=checkbox were invented today, it would probably be called
type=boolean.)
What if you want the number to be either 13 or 16 digits long, as with a
credit card
pattern=(\d{5}([\-]\d{4})?)
Then you use type=text. Whether the value is a number or just a
sequence of digits is debatable. But in any case you don’t want to
create a spinbox.
Yucca
