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

[Nils Dagsson Moskopp]

Qebui Nehebkau <qebui.nehebkau+whatwg at gmail.com> writes:

> On Wed, Feb 19, 2014 at 7:51 PM, Nils Dagsson Moskopp
> <nils at dieweltistgarnichtso.net> wrote:
>> CE or BE or ROC do not specify units (successor elements), but points of
>> reference (neutral elements). In my examples, the unit for a time offset
>> is always the duration of a solar year.
>
> Yes, sorry, by 'essentially' I meant that they /act/ like and can be
> treated as such, as a simplification.

Looks like a type error to me – similar to the following cases:

- octets can be treated as characters, as a simplification
- UTF-16 can be treated as UCS-2, as a simplification
- REST can be treated as CRUD, as a simplification
- HTML can be parsed with regular expr…ZA̡͊͠͝LGΌ

>> The first operand is the name for a duration of time (conveying a start
>> point and an end point), while the second operand is an offset. Suppose
>> the result was displayed using html, like <time>2014</time>:
>
> I agree so far, sure, but note also that the year name is itself
> comprised of an offset and a description of a zero point; 2014 CE is
> "the year starting at the moment when 2,014 years have elapsed from
> the start of 1 BC". It is itself a number of years, rendered a certain
> way by convention.
>
>> - A user agent could localize the result to 2557 BE or ROC 103 or YOLD
>>   3180 without introducing errors into the calculation - similar to an
>>   conversion between binary, decimal and hex. Why should it be unable to
>>   localize the input (which is done with time zones all the time, btw) ?
>
> Sure, you can change the number that corresponds to a given abstract
> year by changing the zero, and this would depend on knowing the
> original zero such that it's clear that, for example, '2014' means
> 2014 CE rather than BE or even BCE (presumably by specification).

I think the HTML specification follows ISO 8601 – so yes, 2014 CE.

> The question is, is it a big enough deal that it demands a new input
> type, rather than, say, a number and a dropdown with typical eras,
> provided by the author?

That solution leads to the following prerequisites for localization:

  1. authors are aware of localization issues
  2. authors care about localization issues
  3. authors know about user locale
  4. authors implement localization
  5. authors are competent working with localized data

The <input type=year> solution instead only requires that the web server
is able to process ISO 8601 dates. It would place a small one-time
burden on implementors, instead of a continuous burden on authors.

> Or, for that matter, a CSS property telling the browser to display the
> number following its conventions for year numbers, which could include
> choice of zero just as much as grouping, as long as the document's
> choice can be determined.

I do not think that localization should be an author's burden. I also do
think that localization should not depend on sender, but on receiver.

>> - A user agent could not localize the offset, unless a separate <input
>>   type=timedelta> (or similar) would be introduced. One can use an
>>   <input type=number> for a time offset quite nicely, also see below.
>
> Yes, of course. Although I'm not sure what localising an elapsed time
> would even mean (beyond the obvious choice of characters), except
> possibly converting it into some non-year unit.

See example: 900 seconds or 15 minutes, what would you rather read?

>> I hereby - only half-jokingly - propose a @unit-type attribute for both
>> <input type=number> and <input type=range>, which conveys what the given
>> number represents. Thee @unit-type attribute can have the values "K",
>> "s", "m", "kg", "cd", "A" and "mol" to enable hints for the seven SI
>> base units. A microsyntax using the tokens "(", ")", "+", "-", "*", "/"
>> and "^" could be used to specify derived units. User agents would be
>> encouraged to localized the displayed data.
>>
>> Example for <input> element on a cooking form:
>>
>> <label>temperature <input type=number unit-type="K" value=453.15></label>
>> <label>cooking time <input type=number unit-type="s" value=900></label>
>> <label>beep frequency <input type=range unit-type="1/s" value=1></label>
>>
>> A user agent could display this - localized - as follows:
>>
>>     temperature     [      180 °C ][+|-]
>>     cooking time    [      15 min ][+|-]
>>     beep frequency  [ each second ][+|-]
>>
>> The @unit-type attribute could also provide useful when allowed on the
>> <data>, <var>, <output> and <meter> elements. Mark my words.
>
> When I first read this, I considered it unnecessary complexity. On
> reflection, though, I find that I kind of like it. Perhaps it should
> be allowed for <data> as well? Of course, I'm not sure that anyone
> would really use it in practice.

Public transport schedule query forms commonly ask how much time you
want to have for changing trains at each stop and/or how far the stop is
allowed to be from the actual target and how fast you can walk. This
common use case already covers time (s), distance (m) and speed (m/s).

Those forms use <select> and <option> nowadays, see example:
<https://www.s-bahn-berlin.de/fahrplanauskunft-routenplaner>

Weather sites commonly display temperature. I'd probably use temperature
and time myself (more likely if @unit-type could also contain '°C',
'min' and 'h').

-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>