On Wed, Feb 19, 2014 at 4:32 AM, Nils Dagsson Moskopp <n...@dieweltistgarnichtso.net> wrote: > The number of a calendar year really does not fit into to the number > model. Year numbering conveys something different than floating point > numbers or even integers. Standardization of values on ISO years / > proleptic gregorian calendar could prevent quite a few errors here.
Actually, they seem very clearly to be numbers (an integer offset from some defined 'zero' value, despite some complexities where the zero and direction of the offset actually differ between CE and BCE) - they can be incremented or summed meaningfully, even multiplied (although not squared, most of the time), and unlike, eg., the mentioned: On Wed, Feb 19, 2014 at 12:23 AM, Jukka K. Korpela <jkorp...@cs.tut.fi> wrote: > [...] car plate numbers, credit card numbers, product numbers, or > social security numbers [...] they can be usefully selected with varying precision (adjacent years are closely related, but the next credit card number up is completely different). On Wed, Feb 19, 2014 at 4:32 AM, Nils Dagsson Moskopp <n...@dieweltistgarnichtso.net> wrote: > Interface-wise, a dialog for <input type=year> without a value might > focus the current year initially - I would consider that a usability > boon. Year selection dialogs do already exist: That's certainly already possible, and would be undesirable often enough that it is better not to force it. It could make sense as a default if a value is not supplied, though. > This rule may not be so useful in general: Digit grouping using dots, > commas or spaces can be useful when comparing smaller and larger > numbers. Consider the following grouping of <input type=number>: > > [ 210 000 ] [+|-] > [ 19 250 ] [+|-] > [ 1 500 ] [+|-] To me, this suggests that grouping should eventually be a CSS property. But, personally, I just don't think the problem justifies a workaround until we can do that.