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

[Qebui Nehebkau]

On Wed, Feb 19, 2014 at 11:38 AM, Nils Dagsson Moskopp
<nils at dieweltistgarnichtso.net> wrote:
> 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).

This is all true, but the names we use are typically comprised,
essentially, of a number and a unit. Why shouldn't the numerical part
still be treated as a number? One would certainly use type="number"
for a mass or distance, I'd imagine, even though we can have different
names that refer to the same mass.

> 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.

That seems like a good way of interpreting that, but "2012 CE + 2
(years)" must result in 2014 CE.

> 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.

I certainly wouldn't wish to give authors any fine-grained control
over the grouping, or, for that matter, anything. Instead, I'd have a
set of fixed categories of numbers that are typically grouped in
unusual ways (vs. the general numerical case), allowing authors to
specify what kind of number this is and browsers, then, to use that
information to display the number optimally. Of course, it may be that
the number of types of numbers is infinite, but I would at least hope
that this isn't the case.