- From: Nils Dagsson Moskopp <nils@dieweltistgarnichtso.net>
- Date: Fri, 07 Aug 2015 19:23:08 +0200
- To: Cameron Jones <cmhjones@gmail.com>
- Cc: whatwg <whatwg@lists.whatwg.org>, Qebui Nehebkau <qebui.nehebkau+whatwg@gmail.com>, Jonathan Watt <jwatt@jwatt.org>, Ian Hickson <ian@hixie.ch>
Could you explain how „format“ would work if the content of the element can not be formated like that? How could attributes be re-formated? Cameron Jones <cmhjones@gmail.com> writes: > On Wed, Feb 19, 2014 at 11:38 AM, Nils Dagsson Moskopp < > nils@dieweltistgarnichtso.net> wrote: > >> Qebui Nehebkau <qebui.nehebkau+whatwg@gmail.com> writes: >> >> > On Wed, Feb 19, 2014 at 4:32 AM, Nils Dagsson Moskopp >> > <nils@dieweltistgarnichtso.net> wrote: >> >> The number of a calendar year really does not fit into to the number >> >> model. Year numbering conveys something different than floating point >> >> numbers or even integers. Standardization of values on ISO years / >> >> proleptic gregorian calendar could prevent quite a few errors here. >> > >> > Actually, they seem very clearly to be numbers (an integer offset from >> > some defined 'zero' value, despite some complexities where the zero >> > and direction of the offset actually differ between CE and BCE) - they >> > can be incremented or summed meaningfully, even multiplied (although >> > not squared, most of the time), and unlike, eg., the mentioned: >> >> 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). >> >> 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. >> >> > On Wed, Feb 19, 2014 at 12:23 AM, Jukka K. Korpela <jkorpela@cs.tut.fi> >> wrote: >> >> [...] car plate numbers, credit card numbers, product numbers, or >> >> social security numbers [...] >> > >> > they can be usefully selected with varying precision (adjacent years >> > are closely related, but the next credit card number up is completely >> > different). >> > >> > On Wed, Feb 19, 2014 at 4:32 AM, Nils Dagsson Moskopp >> > <nils@dieweltistgarnichtso.net> wrote: >> >> Interface-wise, a dialog for <input type=year> without a value might >> >> focus the current year initially - I would consider that a usability >> >> boon. Year selection dialogs do already exist: >> > >> > That's certainly already possible, and would be undesirable often >> > enough that it is better not to force it. It could make sense as a >> > default if a value is not supplied, though. >> >> I do not think the specification should "force" any interface. It is >> just that if I were asked to implement a year picker, it would both a) >> focus on the current year if no value was given and b) display the year >> number (name) according to the current locale settings. >> >> >> This rule may not be so useful in general: Digit grouping using dots, >> >> commas or spaces can be useful when comparing smaller and larger >> >> numbers. Consider the following grouping of <input type=number>: >> >> >> >> [ 210 000 ] [+|-] >> >> [ 19 250 ] [+|-] >> >> [ 1 500 ] [+|-] >> > >> > To me, this suggests that grouping should eventually be a CSS >> > property. But, personally, I just don't think the problem justifies a >> > workaround until we can do that. >> >> 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. >> >> > For CSS it would actually be ok because you could use the lang selector, ie: > > input.year:lang(en) { > format: "%t"; > } > > If it was an HTML attribute it would be impossible to define formats for > multiple different locales (other than using an element for each > permutation): > > <input class="year" type="number" format="%t" locale="en"/> > > Thanks, > Cameron Jones -- Nils Dagsson Moskopp // erlehmann <http://dieweltistgarnichtso.net>
Received on Friday, 7 August 2015 17:24:42 UTC