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.


Reply via email to