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

On Wed, 19 Feb 2014, Michael[tm] Smith wrote:
> Ian Hickson <ian@hixie.ch>, 2014-02-18 23:59 +0000:
> > On Tue, 18 Feb 2014, Jonathan Watt wrote:
> > >
> > > I wonder if it would be that bad to have a 'year' type to compliment 
> > > the 'month' and 'day' types...
> > 
> > This has come up a few times, but so far the use cases have not been 
> > compelling enough. This is probably the most compelling use case, but 
> > even here, I don't know that it's that compelling.
> > 
> > I would be interested in hearing more about the locales where not 
> > using separators even for four digits is bad/suboptimal. If it wasn't 
> > for those, I would say that just not using separators for four-digit 
> > numbers would be an easy and effective solution.
> 
> The following info seems relevant -
> 
>   http://www.thepunctuationguide.com/comma.html#numbers
>   "Most authorities, including The Associated Press Stylebook and The Chicago
>   Manual of Style, recommend a comma after the first digit of a four-digit
>   number. The exceptions include years, page numbers, and street addresses."
> 
> To me that appears to be a strong argument that formatting of years is 
> in fact clearly an exception, and that's compelling enough to warrant 
> having a type for them separate from the normal number type (in which 
> four-digit numbers would instead have a separator, to follow existing 
> longstanding conventions).

Interesting.

For street addresses, we are moving in the direction of larger fields not 
smaller fields, so I'm not too worried about that use case. (I do know one 
form that looks just for a street address number, but presumably it has to 
handle non-numeric data anyway, as in "23A".)

If that left just page numbers, I'd probably ignore it, since the use 
cases are pretty limited there. But years are clearly a major use case.

Doing further research along these lines, it seems that it's specifically 
page numbers and years _that are four digits long_ that are at issue, when 
it comes to English:

| MLA style is to use a comma in four-digit numbers except in page 
| numbers, line numbers, addresses, and years, unless the year has more 
| than four digits, such as 10,000 BCE.
 -- http://www.esc.edu/online-writing-center/resources/punctuation/commas/

Though some people say that applies to more than just years and page 
numbers:

| Use commas to separate groups of 3 numbers in numbers of 5 digits or 
| more unless decimals are used. The comma in a 4-digit number may be 
| omitted.
 -- http://mtdesk.com/Numbers

However, in other languages, as Karl showed, the pattern is different.

As I see it, we have two possible paths:

1. We consider this a stylistic issue, and we add something to CSS to make 
it possible to control the formatting of numbers in <input type=number>. 
Then, someone doing a page-number control in English can use CSS to make 
it not include commas in four-digit numbers but include numbers otherwise, 
and so forth.

2. We consider this a semantic issue, and we add one or more new input 
types to handle the new smenatics. For example, we add type=year and 
type=page-number.

We can also follow a combinations of both, providing a new control for 
the cases that need more than just style, and providing style for the 
cases that are just presentational.


On Wed, 19 Feb 2014, Jukka K. Korpela wrote:
> 
> The point is that year numbers aren't really "numbers" in a normal 
> sense, any more than car plate numbers, credit card numbers, product 
> numbers, or social security numbers are. Surely they can be regarded as 
> numbers, but so can car plate numbers and the others.

On Wed, 19 Feb 2014, Smylers wrote:
> 
> Except that years do actually form a sequence, and it's possible to 
> perform maths on them; for instances, subtracting one year from another 
> yields a duration, which is a meaningful quantity, whereas subtracting a 
> couple of credit card numbers is completely useless.

On Wed, 19 Feb 2014, Jukka K. Korpela wrote:
> 
> Mathematically, you are right, but input types aren't based on general 
> properties of quantities but on practical classification of input data. 
> All the examples I gave, including year numbers, are normally input by 
> typing the digits - in contrast with, say, using a color picker, a data 
> picker, or a slider.

Your annual income, when enterested into an electronic tax form, is 
usually "input by typing the digits", but it's definitely a number. I 
think the only way, in western locales, that years differ from other 
numbers is with respect to formatting, and that's not unique to years, as 
Mike pointed out (c.f. page numbers).


On Wed, 19 Feb 2014, Smylers wrote:
> 
> There are situations where up/down arrows makes sense on years. For 
> instance, a chart of various baby names could have a box for the year 
> currently being displayed, and it's handy to be able to nudge that along 
> by a year at a time to see it change, without having to manually retype 
> the year. Or when displaying one year's tax return, with the ability to 
> display other years' returns — with adjacent years being likely options.

Indeed. This is why so far we haven't included a type=year control: 
type=number, semantically, is the right control.


On Wed, 19 Feb 2014, Jukka K. Korpela wrote:
>
> And year numbers differ, as mentioned, from normal numbers as regards to 
> conventional formats (e.g., 2014 vs. 2,014 or 2'014 or 2 014 or...).

But as noted above, this is not unique to years. Indeed in some locales, 
it's all numbers with four digits; in others it's also page numbers and 
street addresses.


On Wed, 19 Feb 2014, Jukka K. Korpela wrote:
>
> What else could <input type=year> be other than reading some digits?

This is an interesting question. If the answer is "nothing", then 
type=number with styling hints is the right answer for addressing the "no 
commas in years" problem. But if the answer is "in some locales, years are 
completely different", then we have a semantic on our hands.


On Fri, 7 Mar 2014, Ryosuke Niwa wrote:
>
> Let me point out that not every calendar uses simple 2-4 digit numbers 
> to denote years.
> 
> The Japanese era name calendar system, for example, requires an era name 
> such as Showa and Heisei associated with each year.
> 
> For example, I was born in Gregorian year 1986 but any Japanese 
> government document would say I was born in Showa 61.  My brother was 
> born in 1989 but, again, he must write "Heisei 1" instead on any 
> government form.
> 
> There are also even quite few banks and other organizations in Japan 
> that use the era name system for various forms and documents.

This is a pretty strong argument for a type=date feature, in principle.

However: Some eras start mid-way through a year. For example, Meiji 45 
lasts until July 30th 1912, and Taishō 1 starts then. Without date 
context, how would such values get round-tripped? If we assume a 
hypothetical type=year displays Japanese era years in the UI, but 
transmits Gregorian years over the wire, how do we ensure that the same 
year comes back?

If round-tripping is important, then this is actually a _different_ input 
type than Gregorian years.

Presumably, round-tripping is important here. For example, I would presume 
that the sentence "Emperor Meiji said 'Hello' in Meiji 45" has rather 
different connotations than "Emperor Meiji said 'Hello' in Taishō 1".


On Tue, 11 Mar 2014, Smylers wrote:
> 
> [..] But if <input type=year> isn't otherwise useful, there may be a 
> more generic way of addressing the ‘no commas in 4-digit years’ issue 
> which also addresses 4-digit page numbers (and the like).

Indeed.


On Tue, 11 Mar 2014, Ryosuke Niwa wrote:
> 
> This is why iOS allows users to pick either representation instead of 
> always using either based on locale.

How does iOS handle the round-tripping issue?


On Tue, 11 Mar 2014, Smylers wrote:
> 
> It follows that any site which wants a year for any purpose and has a 
> Japanese audience would therefore benefit from a year widget which also 
> offers both Gregorian and Japanese ways of specifying a year.
> 
> I could find such sites in English, and hypothesize that equivalent 
> Japanese sites would also exist. But in terms of providing requirements 
> to the HTML spec, it'd be better to have examples of actual sites, not 
> mere hypothetical ones.

Indeed.


On Wed, 19 Feb 2014, Jukka K. Korpela wrote:
> 
> And what about page numbers and street addresses (and other exceptions)? 
> If we have <input type=year>, then it would be rather odd to use it for 
> reading a page number.
> 
> Most importantly, though, this would introduce yet another value for the 
> type attribute for something that can well be handled with existing 
> tools: <input pattern=\d{4}>. It is improbable that any year selection 
> widget would be useful. Years are normally best entered by typing them.

The pattern="" attribute is about the wire format constraints, not about 
the display format. They are orthogonal issues. I think trying to reuse 
pattern="" in the context of numeric formatting is not a winning strategy.


> On the other hand, as this is about input, not output, a simple 
> additional rule (which has other usability benefits, too) would solve 
> the issue, too: User agents may allow locale-specific group separators 
> in a number (e.g., “1,500” when the locale is English), but they shall 
> accept a number without group separators, too (e.g., “1500”, in any 
> locale).

The problem is what the display should be, not what input should be 
accepted. One would not want this:

   <label> Year: <input type=number value="2014"> </label>

...to render, in an English context, as:

   Year: [     2,014 ]


On Wed, 19 Feb 2014, Nils Dagsson Moskopp wrote:
> 
> Some calendars do have an integer offset to the gregorian calendar,
> allowing localization. If I understand the Wikipedia pages correctly, to
> get the year in the Thai solar calendar one has to add 543 to the ISO
> year and for both the Republic of China calendar and North Korean
> calendar one has to substract 1911.
> 
> <http://en.wikipedia.org/wiki/Thai_solar_calendar>
> <http://en.wikipedia.org/wiki/North_Korean_calendar>
> <http://en.wikipedia.org/wiki/Minguo_calendar>

These appear to all map cleanly to Gregorian years, which increases the 
argument for a type=year control.


> 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:
> <http://www.yuiblog.com/blog/2009/04/03/multi-layer-calendar/>
> <http://msdn.microsoft.com/en-us/library/windows/desktop/bb760913(v=vs.85).aspx#SELECT_DIFF_YEAR>

It's a pity those are Western only, it would have been interesting to see 
how they handled the overlap issues with Japanese eras.


> Consider the following grouping of <input type=number>:
> 
> [ 210 000 ] [+|-]
> [  19 250 ] [+|-]
> [   1 500 ] [+|-]

This is a strong argument for not special-casing four-digit numbers.


It looks like there's some demand for type=year; I've filed a bug to track 
implementor interest:

   https://www.w3.org/Bugs/Public/show_bug.cgi?id=25315


It also looks like it would be good to have a way to style input controls, 
in particular <input type=number>, to use specific kinds of formatting. 
This is somewhat out of scope for HTML; I recommend developing a CSS 
feature for this purpose in conjunction with browser vendors, if anyone 
is interested in pursuing this.

I've abandoned the idea of making the spec suggest that four-digit numbers 
should not have separators.



On Wed, 19 Feb 2014, Nils Dagsson Moskopp wrote:
> 
> 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.

What problem is this solving?


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

Is this something that has real author demand? What pages are working 
around the lack of this feature today?


On Thu, 20 Feb 2014, Qebui Nehebkau wrote:
> 
> 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.

If no-one would use it...


On Sat, 8 Mar 2014, David Dailey wrote:
>
> I think there are two interesting questions here: 1. What is a number?  
> A magnitude, an ordinal value (obeying the transitive property), a 
> rotational value (like day of year, degrees, day of week), an interval 
> value, a nominal labeling (take the SS Stevens taxonomy and add 
> rotational [1])?

In the context of <input type=number>, a number is something for which it 
makes sense to have a up/down buttons.


> 2. What sort of interface is best used to elicit a numerical response 
> from a person? We often assume that the human will type such a thing, 
> though for small n, radios and even selects work okay. Can a widget be 
> developed called a "throttle" which allows the user to use a joystick to 
> accelerate through an ordinal collection of n ordinal values (for large 
> n>10000) and to pick a number more quickly using the throttle than by 
> using the keyboard? Since the words of an alphabetic language have a 
> natural ordering (imposed by alphabetization) are not words numeric, and 
> cannot a throttle be used more effectively than a keyboard?

That's up to the browser.


On Tue, 18 Feb 2014, David Dailey wrote:
>
> <input
> [magnitude|quantity|quality|time|thing|person|place|action|epistemic|quantif
> ier|URI|anaphora|mediatype|direction|influence|...]=attribute-value-expressi
> on-with-micro-syntax>
> 
> with all appropriate cross-cultural studies underlying each 
> attribute-value.
>
> I am reminded of the Navajo verb system, in which epistemic values 
> (certainty), influence (transitive/intransitive), deixis 
> (this/that/yonder), and quantifiers (unique, none, all, some) are not 
> strictly orthogonal. Nle`i dzilh bits'i`i d'shighan : the unique and 
> well-known hill over yonder, beyond it there is my house. Were the hill 
> or the direction not well known, then it might be expressed differently 
> (as I seem to recall). It's maybe a bad example since bits'i`i could be 
> viewed as a preposition, but heck, it's been decades since I had a 
> Navajo-speaking hitchhiker in my car (and we seemed never to agree on 
> etymology)!
> 
> What sorts of things might people want to say to us as web-folk? Are not 
> those all the possible types of input?

I'm not sure I follow what you are asking here.


On Tue, 18 Feb 2014, David Dailey wrote:
> 
> Thanks to jwatt for raising the issue and to Karl for casting it in the 
> context that I presume jwatt was intending it to be cast.
> 
> It reminds me of the early discussions, circa 2007 on 
> whatwg/public-html, of what exactly was meant by 'semantics'. Is it 
> merely HTML or is it meaning?
> 
> In a cross-cultural sense, do we really expect that <p> and <aside> and 
> <quote> and <grid> and <section> and all the other things (that 
> HTML5.5555555... might ultimately asymptote with itself to include) are 
> inclusive of the ways that cultures, the world wide, might choose to 
> partition their discourse, into tags, elements, and taxonomies, replete 
> with meaning, context, style and behavior?
> 
> Perhaps at the core of human expression is the <idea> and until we 
> respect one another for that core expression, distinctions between 
> semantics, behavior, presentation and context are askew, or at least 
> un-worldwidish. HTML7 should be radically different than HTML5: a new 
> prime number requires new thinking and new participation and perhaps, 
> even, reinvention at the expense of a broken wheel or two.

I don't understand what you are proposing here, but it's worth noting that 
(a) "5" is also prime, and (b) we've dropped the number entirely. For 
further discussion on the issue of reinvention, I recommend this post:

   https://plus.google.com/+IanHickson/posts/SiLdNL9MsFw

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'