- From: Cameron Jones <cmhjones@gmail.com>
- Date: Wed, 19 Feb 2014 12:09:16 +0000
- To: Nils Dagsson Moskopp <nils@dieweltistgarnichtso.net>
- Cc: whatwg <whatwg@lists.whatwg.org>, Ian Hickson <ian@hixie.ch>, Jonathan Watt <jwatt@jwatt.org>, Qebui Nehebkau <qebui.nehebkau+whatwg@gmail.com>
On Wed, Feb 19, 2014 at 11:38 AM, Nils Dagsson Moskopp < nils@dieweltistgarnichtso.net> wrote: > Qebui Nehebkau <qebui.nehebkau+whatwg@gmail.com> writes: > > > On Wed, Feb 19, 2014 at 4:32 AM, Nils Dagsson Moskopp > > <nils@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: > > I consider year-era-constructs as names for a duration of time. We can > have different names than refer to the same duration of time, like "2014 > CE" and "2557 BE" and "ROC 103". The fact that most of these calendar > systems use a neutral element (era) and a successor function does not > detract from that: Many contemporary calendar systems also have the > concept of month numbering ("february is the second month") - still, in > the interest of localization, the ISO date string value "2014-02" in > <input type=month> might be rendered as e.g. "Februar 2014" (German). > > Btw, a meaningful type system should probably prevent you from summing > year numbers. "2012 CE + 2013 CE + 2014 CE" should not result in "6039 > CE", but a duration of time from 2012 CE to 2014 CE. > > > On Wed, Feb 19, 2014 at 12:23 AM, Jukka K. Korpela <jkorpela@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 > > <nils@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. > > I do not think the specification should "force" any interface. It is > just that if I were asked to implement a year picker, it would both a) > focus on the current year if no value was given and b) display the year > number (name) according to the current locale settings. > > >> 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. > > I sincerely hope grouping does not become a CSS property, as it is > locale dependent. Authors can (and will) ruin this for users not in > their locale. > > For CSS it would actually be ok because you could use the lang selector, ie: input.year:lang(en) { format: "%t"; } If it was an HTML attribute it would be impossible to define formats for multiple different locales (other than using an element for each permutation): <input class="year" type="number" format="%t" locale="en"/> Thanks, Cameron Jones
Received on Wednesday, 19 February 2014 12:09:52 UTC