2014-02-19 11:10, Smylers wrote:
Jukka K. Korpela writes:
The point is that year numbers aren't really "numbers" in a normal
sense, any more than car plate numbers, credit card numbers, product
numbers, or social security numbers are. Surely they can be regarded
as numbers, but so can car plate numbers and the others.
Except that years do actually form a sequence, and it's possible to
perform maths on them; for instances, subtracting one year from another
yields a duration
Mathematically, you are right, but input types aren't based on general
properties of quantities but on practical classification of input data.
All the examples I gave, including year numbers, are normally input by
typing the digits - in contrast with, say, using a color picker, a data
picker, or a slider. And year numbers differ, as mentioned, from normal
numbers as regards to conventional formats (e.g., 2014 vs. 2,014 or
2'014 or 2 014 or...).
So in the input process, a year number is not treated like a number. It
typically appears when asking for year of birth or some other event
(marriage, employment, etc.). The input check is normally against any
non-digit data, the kind of thing we can do with pattern=...
Logically, one might say that since asking for a year is very often an
alternative to asking for more specific data such as month or day, it
should be treated as "date and time input" rather than text input with
restrictions. But I don't see how this would be practically relevant.
What else could <input type=year> be other than reading some digits?
There is the possibility of allowing two-digit numbers, with an implied
century, but if that is desirable, authors can use <input type=text
pattern=\d{4}|\d{2} and deal with the implied century in their own code.
Yucca
