[whatwg] <input type=number> for year input
Nils Dagsson Moskopp
nils at dieweltistgarnichtso.net
Wed Feb 19 11:51:30 PST 2014
Qebui Nehebkau <qebui.nehebkau+whatwg at gmail.com> writes:
> 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.
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>
More information about the whatwg
mailing list