On Wed, Feb 19, 2014 at 7:51 PM, Nils Dagsson Moskopp
<n...@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.
> 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). 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? 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.
> - 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.
> 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.
However, since you mention temperature in the context of cooking, I
should point out that, in Canada (for example), degrees Celsius are
the typical unit of temperature, but Fahrenheit is often used in
cooking. Localisation to Celsius, while likely comprehensible, may not
be ideal. That said, this seems like a reason for browsers to allow
the user to choose the representation, not a flaw in the idea itself.
