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

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

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

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.

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

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

- 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) ?

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

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

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.

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

Received on Wednesday, 19 February 2014 19:52:16 UTC