[whatwg] <input type=number> for year input

[Domenic Denicola]

One useful route may be using ECMAScript's Internationalization API to offload any formatting work. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NumberFormat seems to imply something like

<input type="number" formatstyle="decimal" lang="en-US">

could format according to

new Intl.NumberFormat("en-US", { style: "decimal" }).format(...)

Coming up with a translation of that constructor into attributes would be bit of an undertaking. Alternately you could offload all the work to script:

myInputEl.numberFormatter = new Intl.NumberFormat("en-US", { style: "currency" });

// Or set the default for everything on the page?
HTMLInputElement.prototype.numberFormatter = null;
// Here 'null' means 'no formatting,' i.e. just raw digits.
________________________________________
From: whatwg-bounces at lists.whatwg.org <whatwg-bounces at lists.whatwg.org> on behalf of Cameron Jones <cmhjones at gmail.com>
Sent: Wednesday, February 19, 2014 07:09
To: Nils Dagsson Moskopp
Cc: whatwg; Ian Hickson; Jonathan Watt; Qebui Nehebkau
Subject: Re: [whatwg] <input type=number> for year input

On Wed, Feb 19, 2014 at 11:38 AM, Nils Dagsson Moskopp <
nils at dieweltistgarnichtso.net> wrote:

> Qebui Nehebkau <qebui.nehebkau+whatwg at gmail.com> writes:
>
> > On Wed, Feb 19, 2014 at 4:32 AM, Nils Dagsson Moskopp
> > <nils at 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 at 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 at 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