- From: Nils Dagsson Moskopp <nils@dieweltistgarnichtso.net>
- Date: Wed, 19 Feb 2014 20:51:30 +0100
- To: Qebui Nehebkau <qebui.nehebkau+whatwg@gmail.com>
- Cc: whatwg <whatwg@lists.whatwg.org>, Jonathan Watt <jwatt@jwatt.org>, Ian Hickson <ian@hixie.ch>
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