Re: [whatwg] input type=number for year input
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 cmhjo...@gmail.com writes:
On Wed, Feb 19, 2014 at 11:38 AM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
Qebui Nehebkau qebui.nehebkau+wha...@gmail.com writes:
On Wed, Feb 19, 2014 at 4:32 AM, Nils Dagsson Moskopp
n...@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 jkorp...@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
n...@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
Re: [whatwg] input type=number for year input
On Wed, 19 Feb 2014, Michael[tm] Smith wrote: Ian Hickson i...@hixie.ch, 2014-02-18 23:59 +: 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
Re: [whatwg] input type=number for year input
On Thu, Feb 20, 2014 at 9:19 PM, Jonathan Watt jw...@jwatt.org wrote: For what it's worth I just tried the following in Chrome, and if I type in 12,34 then increment using the spinner it resets to zero, seeming to indicate that the , was rejected. Is that expected? data:text/html,input type=number step=0.01 lang=fr It's expected. Form controls in Google Chrome doesn't respect lang attribute for now. Form controls are always localized for browser's UI locale. We accepted entering grouping separators in the past. But we stopped it because users had to know their locale correctly. e.g. 1,234 has different meaning in French locale and English locale if we support grouping separators. So essentially you assume any separator that is a decimal separator in any locale is a decimal separator all cases? Even that approach would seem to have the potential for unexpected results for users; for example, a user types in 1,234 meaning 1234 but the input takes the value 1.234. Or maybe I misunderstand? You're right. Such confusion can happen even in WebKit/Blink implementation. However, it's much better than accepting both of grouping separator and decimal separator IMO. -- TAMURA, Kent Software Engineer, Google
Re: [whatwg] input type=number for year input
Ryosuke Niwa writes: On Mar 7, 2014, at 3:54 AM, Smylers smyl...@stripey.com wrote: An international website wanting a [year] ... could internally store all years using one particular system (say the Gregorian one), but allow input in other systems. This could be with a free-form text box with interpretation, validation, and error-handling on the server side, but that would be a substandard user interface. Better would be to use browser-side JavaScript either to perform the validation or to provide a year picker which only allows selecting valid years; regardless of the interface on this picker — for instance, listing Japanese emperors — it could set the value submitted with the form to be the equivalent Gregorian year. This is why type=year would be useful so that UAs could present it in accordance to the user preference. It's only useful if there are actually sites which want to do this. Are there many websites currently catering [for] Japanese years by offering such an interface? If so, it would make sense to create input type=year such that browsers can offer this consistently, freeing authors from having to develop these for each site. SMBC, the second largest bank in Japan, has an online account form which asks the date of birth using Japanese calendar system. They don't provide an option to type that in using the Gregorian calendar at least in the Japanese version of their website. Sony bank (moneykit.net) asks the date of birth using Gregorian calendar but provides a conversion table from Japanese calendar system: http://moneykit.net/visitor/account/account14.html I'll note, however, that both of these use cases are better addressed via type=date. Yes, so they aren't actually demonstrating that input type=year would be useful. Also, both of those seem to be sites intended only for Japanese users. As such, a Japanese-specific year selection is sufficient for them; they can use select for the entire year, or possibly select for the era then input type=number for the year within that era. Such sites wouldn't be trying to use input type=number for a year in the first place, so the unsuitability of it for Japanese years doesn't matter. The need for a widget which offers either Japanese or Gregorian interfaces for selecting a year, depending on the user's preference, then always submits it in a single defined way to the server, only really crops up on an international site which can expect users most familiar with each of those calendar systems. However, that still wouldn't solve the problem of input type=number putting commas in 4-digit page numbers. Right. But with if we had type=year, UAs could localize it appropriately for this use case. Indeed. 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). Cheers Smylers -- http://twitter.com/Smylers2
Re: [whatwg] input type=number for year input
On Mar 11, 2014, at 2:28 AM, Smylers smyl...@stripey.com wrote: Ryosuke Niwa writes: On Mar 7, 2014, at 3:54 AM, Smylers smyl...@stripey.com wrote: An international website wanting a [year] ... could internally store all years using one particular system (say the Gregorian one), but allow input in other systems. This could be with a free-form text box with interpretation, validation, and error-handling on the server side, but that would be a substandard user interface. Better would be to use browser-side JavaScript either to perform the validation or to provide a year picker which only allows selecting valid years; regardless of the interface on this picker ― for instance, listing Japanese emperors ― it could set the value submitted with the form to be the equivalent Gregorian year. This is why type=year would be useful so that UAs could present it in accordance to the user preference. It's only useful if there are actually sites which want to do this. Are there many websites currently catering [for] Japanese years by offering such an interface? If so, it would make sense to create input type=year such that browsers can offer this consistently, freeing authors from having to develop these for each site. SMBC, the second largest bank in Japan, has an online account form which asks the date of birth using Japanese calendar system. They don't provide an option to type that in using the Gregorian calendar at least in the Japanese version of their website. Sony bank (moneykit.net) asks the date of birth using Gregorian calendar but provides a conversion table from Japanese calendar system: http://moneykit.net/visitor/account/account14.html I'll note, however, that both of these use cases are better addressed via type=date. Yes, so they aren't actually demonstrating that input type=year would be useful. Also, both of those seem to be sites intended only for Japanese users. As such, a Japanese-specific year selection is sufficient for them; they can use select for the entire year, or possibly select for the era then input type=number for the year within that era. Such sites wouldn't be trying to use input type=number for a year in the first place, so the unsuitability of it for Japanese years doesn't matter. It isn't. Unfortunately, younger generations tend to be more comfortable with the Gregorian calendar while older generations tend to be more comfortable with Japanese era system. This is why iOS allows users to pick either representation instead of always using either based on locale. The need for a widget which offers either Japanese or Gregorian interfaces for selecting a year, depending on the user's preference, then always submits it in a single defined way to the server, only really crops up on an international site which can expect users most familiar with each of those calendar systems. Hence this is not true. However, that still wouldn't solve the problem of input type=number putting commas in 4-digit page numbers. Right. But with if we had type=year, UAs could localize it appropriately for this use case. Indeed. 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). Cheers Smylers -- http://twitter.com/Smylers2
Re: [whatwg] input type=number for year input
Ryosuke Niwa writes: On Mar 11, 2014, at 2:28 AM, Smylers smyl...@stripey.com wrote: Ryosuke Niwa writes: On Mar 7, 2014, at 3:54 AM, Smylers smyl...@stripey.com wrote: Are there many websites currently catering [for] Japanese years by offering such an interface? If so, it would make sense to create input type=year such that browsers can offer this consistently, freeing authors from having to develop these for each site. SMBC, the second largest bank in Japan, has an online account form which asks the date of birth using Japanese calendar system. They don't provide an option to type that in using the Gregorian calendar at least in the Japanese version of their website. Sony bank (moneykit.net) asks the date of birth using Gregorian calendar but provides a conversion table from Japanese calendar system: http://moneykit.net/visitor/account/account14.html I'll note, however, that both of these use cases are better addressed via type=date. Yes, so they aren't actually demonstrating that input type=year would be useful. Also, both of those seem to be sites intended only for Japanese users. As such, a Japanese-specific year selection is sufficient for them; they can use select for the entire year, or possibly select for the era then input type=number for the year within that era. Such sites wouldn't be trying to use input type=number for a year in the first place, so the unsuitability of it for Japanese years doesn't matter. younger generations tend to be more comfortable with the Gregorian calendar while older generations tend to be more comfortable with Japanese era system. Ah, OK. input type=date with an interface offering both ways of specifying a date would indeed be useful, but I don't think that requires any changes to the HTML spec. 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. Smylers -- http://twitter.com/Smylers2
Re: [whatwg] input type=number for year input
On Mar 7, 2014, at 3:54 AM, Smylers smyl...@stripey.com wrote:
Ryosuke Niwa writes [re-ordered]:
On Feb 19, 2014, at 7:36 AM, Jukka K. Korpela jkorp...@cs.tut.fi
wrote:
2014-02-19 11:10, Smylers wrote:
Jukka K. Korpela writes:
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.
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
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. 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...).
So in the input process, a year number is not treated like a number.
It typically appears when asking for year of birth or some other
event (marriage, employment, etc.). The input check is normally
against any non-digit data, the kind of thing we can do with
pattern=...
Logically, one might say that since asking for a year is very often
an alternative to asking for more specific data such as month or
day, it should be treated as date and time input rather than text
input with restrictions. But I don't see how this would be
practically relevant. What else could input type=year be other
than reading some digits? There is the possibility of allowing
two-digit numbers, with an implied century, but if that is
desirable, authors can use input type=text pattern=\d{4}|\d{2} and
deal with the implied century in their own code.
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.
Yes, so for a Japanese organization using the era system,
input type=number would clearly be inappropriate for years.
Yes.
An international website wanting a could use input type=text and let
users specify the year any way they want — Japanese eras, 2-digit years,
Roman numerals, whatever. This could only realistically be stored as a
string, and the only thing the website could do with it is display it
again; it would be hard to sort by it, or perform restrictions based on
the year, for instance. In this scenario, there's nothing special about
the year so far as HTML is concerned.
I don't think that's a good solution because websites probably needed to use
that year to do something.
Or it could force all users to use Gregorian years, and anybody using a
different system needs to convert their year themselves. At which point
input type=number works just fine.
That's also an inadequate solution as the conversion between two systems isn't
easy.
It's not a simple subtraction or addition. Note that iOS natively support
Japanese calendar system.
Or the website could internally store all years using one particular
system (say the Gregorian one), but allow input in other systems. This
could be with a free-form text box with interpretation, validation, and
error-handling on the server side, but that would be a substandard user
interface. Better would be to use browser-side JavaScript either to
perform the validation or to provide a year picker which only allows
selecting valid years; regardless of the interface on this picker — for
instance, listing Japanese emperors — it could set the value submitted
with the form to be the equivalent Gregorian year.
This is why type=year would be useful so that UAs could present it in
accordance to the user preference.
Are there many websites currently catering Japanese years by offering
such an interface? If so, it would make sense to create
input type=year such that browsers can offer this consistently,
freeing authors from having to develop these for each site.
SMBC, the second largest bank in Japan, has an online account form which asks
the date of birth using Japanese calendar system.
They don't provide an option to type that in using the Gregorian calendar at
least in the Japanese version of their website.
Sony bank (moneykit.net) asks the date of birth using Gregorian calendar but
provides a conversion table from Japanese
Re: [whatwg] input type=number for year input
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])? Addresses frequently, but moreso in cities than in rural areas [2] have the property that 123 Huaihai Zhong Road is geographically between 120 Huaihai Zhong Road and 130 Huaihai Zhong Road, hence obeying the transitive property when articulated into geography. 130 State Street SW 30 State Street SW 30 State Street NW 130 State Street NW, meaning that sign is written using notation other than the minus sign. Generally, in places with European cultural heritage, the divisibility of the number (by two) determines the side of street, though even in Europe there are some fun and remarkable differences [3]. Many times, as with the ordinal numbers (first, second and so forth) there is the assumption that the n-th president will have served during a time intermediate between the n-1st and n+1st president. That is, inferences, in the classical sense of the semantic web, may be drawn about many classes of entities considered to be numeric. Do all things for which a simple bijection between the elements of a set and the integers, inherit the number property of that bijection, or simply if the bijection is humanly intuitive (though the cardinality of the rationals is aleph null, we might not expect the standard Cantor labeling to convey the ordinality to such). It is reminiscent of work with the gravitational flavorings of graphs [4] in which we ponder the question of how simple graphs like the internet might be flavored with a single dimension of artificial gravity so as to guide simplified navigation. 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 n1) 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? Cheers David [1] http://en.wikipedia.org/wiki/Level_of_measurement [2] http://bitboost.com/ref/international-address-formats/prc-china/ [3] http://en.wikipedia.org/wiki/House_numbering [4] http://www.graphicalweb.org/2012/#presentation_19 -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Nils Dagsson Moskopp Sent: Saturday, March 08, 2014 1:25 AM To: Jonathan Watt; whatwg Subject: Re: [whatwg] input type=number for year input Jonathan Watt jw...@jwatt.org writes: is it wrong to use input type=number for year input. I am certainly not an expert on the topic, but I believe the conceptual problem can be reduced to using an input designed for a group (in the mathematical sensce) to represent a value that is torsor. Quote http://ro-che.info/articles/2013-01-08-torsors.html: While adding two dates is not possible, it is possible to add a time interval to a date («five days from today»). This suggests that we should not confound dates and time intervals — they are different types of values. Therefore asking for a duration using input type=number is fine – asking for a calendar year, however, is obviously a type error. http://math.ucr.edu/home/baez/torsors.html -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] input type=number for year input
David Dailey ddai...@zoominternet.net writes: Addresses frequently, but moreso in cities than in rural areas [2] have the property that 123 Huaihai Zhong Road is geographically between 120 Huaihai Zhong Road and 130 Huaihai Zhong Road, hence obeying the transitive property when articulated into geography. As re-zoning and constructions efforts frequently do not preserve transitive relations, I hereby urge everyone to never rely on it. Also, in Berlin alone, there are at least three house numbering systems, one of them having the numbers wrap around at the end of the street, like: | | 1 2 3 4 5 | I | + +-- = = = = = = + +-- 10 9 8 7 6 | I | | | -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] input type=number for year input
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.
- R. Niwa
On Feb 19, 2014, at 7:36 AM, Jukka K. Korpela jkorp...@cs.tut.fi wrote:
2014-02-19 11:10, Smylers wrote:
Jukka K. Korpela writes:
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.
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
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. 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...).
So in the input process, a year number is not treated like a number. It
typically appears when asking for year of birth or some other event
(marriage, employment, etc.). The input check is normally against any
non-digit data, the kind of thing we can do with pattern=...
Logically, one might say that since asking for a year is very often an
alternative to asking for more specific data such as month or day, it should
be treated as date and time input rather than text input with restrictions.
But I don't see how this would be practically relevant. What else could
input type=year be other than reading some digits? There is the possibility
of allowing two-digit numbers, with an implied century, but if that is
desirable, authors can use input type=text pattern=\d{4}|\d{2} and deal with
the implied century in their own code.
Yucca
Re: [whatwg] input type=number for year input
Ryosuke Niwa writes [re-ordered]:
On Feb 19, 2014, at 7:36 AM, Jukka K. Korpela jkorp...@cs.tut.fi
wrote:
2014-02-19 11:10, Smylers wrote:
Jukka K. Korpela writes:
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.
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
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. 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...).
So in the input process, a year number is not treated like a number.
It typically appears when asking for year of birth or some other
event (marriage, employment, etc.). The input check is normally
against any non-digit data, the kind of thing we can do with
pattern=...
Logically, one might say that since asking for a year is very often
an alternative to asking for more specific data such as month or
day, it should be treated as date and time input rather than text
input with restrictions. But I don't see how this would be
practically relevant. What else could input type=year be other
than reading some digits? There is the possibility of allowing
two-digit numbers, with an implied century, but if that is
desirable, authors can use input type=text pattern=\d{4}|\d{2} and
deal with the implied century in their own code.
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.
Yes, so for a Japanese organization using the era system,
input type=number would clearly be inappropriate for years.
An international website wanting a could use input type=text and let
users specify the year any way they want — Japanese eras, 2-digit years,
Roman numerals, whatever. This could only realistically be stored as a
string, and the only thing the website could do with it is display it
again; it would be hard to sort by it, or perform restrictions based on
the year, for instance. In this scenario, there's nothing special about
the year so far as HTML is concerned.
Or it could force all users to use Gregorian years, and anybody using a
different system needs to convert their year themselves. At which point
input type=number works just fine.
Or the website could internally store all years using one particular
system (say the Gregorian one), but allow input in other systems. This
could be with a free-form text box with interpretation, validation, and
error-handling on the server side, but that would be a substandard user
interface. Better would be to use browser-side JavaScript either to
perform the validation or to provide a year picker which only allows
selecting valid years; regardless of the interface on this picker — for
instance, listing Japanese emperors — it could set the value submitted
with the form to be the equivalent Gregorian year.
Are there many websites currently catering Japanese years by offering
such an interface? If so, it would make sense to create
input type=year such that browsers can offer this consistently,
freeing authors from having to develop these for each site.
However, that still wouldn't solve the problem of input type=number
putting commas in 4-digit page numbers.
Cheers
Smylers
--
http://twitter.com/Smylers2
Re: [whatwg] input type=number for year input
Jonathan Watt jw...@jwatt.org writes: is it wrong to use input type=number for year input. I am certainly not an expert on the topic, but I believe the conceptual problem can be reduced to using an input designed for a group (in the mathematical sensce) to represent a value that is torsor. Quote http://ro-che.info/articles/2013-01-08-torsors.html: While adding two dates is not possible, it is possible to add a time interval to a date («five days from today»). This suggests that we should not confound dates and time intervals — they are different types of values. Therefore asking for a duration using input type=number is fine – asking for a calendar year, however, is obviously a type error. http://math.ucr.edu/home/baez/torsors.html -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] input type=number for year input
Nils Dagsson Moskopp writes: Jonathan Watt jw...@jwatt.org writes: is it wrong to use input type=number for year input. I am certainly not an expert on the topic, but I believe the conceptual problem can be reduced to using an input designed for a group (in the mathematical sensce) to represent a value that is torsor. Quote http://ro-che.info/articles/2013-01-08-torsors.html: That seems to be begging the question. What is it about input type=number that leads you to believe it makes sense to add two such values together? Would you also rule out input type=number for page numbers — if I've reached page 122 of a book and you've read up to page 169, adding those together to get page 291 doesn't make any sense, especially if the book only has 255 pages. Or for temperatures in a degree scale, such as Celsius? Here in Leeds it was 10°C yesterday and is 13°C today, but adding those together to make 23° is absurd. Or what about for people's ages? It seems nonsense to me when the media write things like The Rolling Stones having “a combined age of 273”, yet they do: http://www.standard.co.uk/goingout/music/the-rolling-stones-o2-arena--review-8351840.html While adding two dates is not possible, it is possible to add a time interval to a date («five days from today»). This suggests that we should not confound dates and time intervals — they are different types of values. Therefore asking for a duration using input type=number is fine – asking for a calendar year, however, is obviously a type error. http://math.ucr.edu/home/baez/torsors.html That doesn't seem obvious to me at all. The only mathematical operations I've seen available on input type=number are increment and decrement, which clearly is possible on (Gregorian) years. There are many situations where a web form could wish to collect a non-self-addable value such as a temperature. What would be the advantage in telling web authors they can't use input type=number for these? We could add input type=torsor (except I suspect most web authors would be unfamiliar with the term; I can't find it in the ‘Oxford English Dictionary’), but if it's appearance, interface, and behaviour are identical to that of input type=number, what is the point of distinguishing the two? Cheers Smylers -- http://twitter.com/Smylers2
Re: [whatwg] input type=number for year input
On 20/02/2014 01:34, TAMURA, Kent wrote: Hi, The current WebKit/Blink behavior is: - Accept both of the ASCII digits and localized digits - Accept both of the standard decimal point '.' and a localized decimal point That sounds similar to what I've implemented, but users can't mix digits, decimal or grouping separators from different locales. The entire input must be consistent. Specifically, input typed in by the user is first processed using the locale of the element (as defined by the 'lang'/'xml:lang' attributes, if any). If that fails we retry with the locale of the document (Content-Language header). If that fails we retry with the locale of the browser. If that fails then we pass the string off to HTMLInputElement's internals to be set as its value without de-localizing it, where it will be parsed using the HTML 5 rules for valid floating-point number (essentially allowing ASCII digits and decimal point as the final fallback). (We start with the element and work out looking for locale information in order to give priority to the locale of the context in which the input exists.) For what it's worth I just tried the following in Chrome, and if I type in 12,34 then increment using the spinner it resets to zero, seeming to indicate that the , was rejected. Is that expected? data:text/html,input type=number step=0.01 lang=fr - Not accept grouping separators and don't show grouping separators We showed grouping separators in the past. But we stopped it because grouping separators disturb some use cases. So I've discovered. ;) We accepted entering grouping separators in the past. But we stopped it because users had to know their locale correctly. e.g. 1,234 has different meaning in French locale and English locale if we support grouping separators. So essentially you assume any separator that is a decimal separator in any locale is a decimal separator all cases? Even that approach would seem to have the potential for unexpected results for users; for example, a user types in 1,234 meaning 1234 but the input takes the value 1.234. Or maybe I misunderstand? Jonathan
Re: [whatwg] input type=number for year input
Qebui Nehebkau qebui.nehebkau+wha...@gmail.com writes: 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. Looks like a type error to me – similar to the following cases: - octets can be treated as characters, as a simplification - UTF-16 can be treated as UCS-2, as a simplification - REST can be treated as CRUD, as a simplification - HTML can be parsed with regular expr…ZA̡͊͠͝LGΌ 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 time2014/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). I think the HTML specification follows ISO 8601 – so yes, 2014 CE. 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? That solution leads to the following prerequisites for localization: 1. authors are aware of localization issues 2. authors care about localization issues 3. authors know about user locale 4. authors implement localization 5. authors are competent working with localized data The input type=year solution instead only requires that the web server is able to process ISO 8601 dates. It would place a small one-time burden on implementors, instead of a continuous burden on authors. 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. I do not think that localization should be an author's burden. I also do think that localization should not depend on sender, but on receiver. - 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. See example: 900 seconds or 15 minutes, what would you rather read? 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: labeltemperature input type=number unit-type=K value=453.15/label labelcooking time input type=number unit-type=s value=900/label labelbeep 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. Public transport schedule query forms commonly ask how much time you want to have for changing trains at each stop and/or how far the stop is allowed to be from the actual target and how fast you can walk. This common use case already covers time (s), distance (m) and speed (m/s). Those forms use select and option nowadays, see example:
Re: [whatwg] input type=number for year input
On Wed, Feb 19, 2014 at 4:32 AM, Nils Dagsson Moskopp n...@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: On Wed, Feb 19, 2014 at 12:23 AM, Jukka K. Korpela jkorp...@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 n...@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. 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.
Re: [whatwg] input type=number for year input
Jukka K. Korpela writes: 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. 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[*1], which is a meaningful quantity, whereas subtracting a couple of credit card numbers is completely useless. [*1] Yes, there are exceptions. But there are still many situations where this is useful, because of the context, such as the range of possible years and the location. Smylers -- http://twitter.com/Smylers2
Re: [whatwg] input type=number for year input
Qebui Nehebkau qebui.nehebkau+wha...@gmail.com writes: On Wed, Feb 19, 2014 at 4:32 AM, Nils Dagsson Moskopp n...@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 jkorp...@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 n...@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. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] input type=number for year input
On Wed, Feb 19, 2014 at 11:38 AM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
Qebui Nehebkau qebui.nehebkau+wha...@gmail.com writes:
On Wed, Feb 19, 2014 at 4:32 AM, Nils Dagsson Moskopp
n...@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 jkorp...@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
n...@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
Re: [whatwg] input type=number for year input
One useful route may be using ECMAScript's Internationalization API to offload
any formatting work.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NumberFormat
seems to imply something like
input type=number formatstyle=decimal lang=en-US
could format according to
new Intl.NumberFormat(en-US, { style: decimal }).format(...)
Coming up with a translation of that constructor into attributes would be bit
of an undertaking. Alternately you could offload all the work to script:
myInputEl.numberFormatter = new Intl.NumberFormat(en-US, { style: currency
});
// Or set the default for everything on the page?
HTMLInputElement.prototype.numberFormatter = null;
// Here 'null' means 'no formatting,' i.e. just raw digits.
From: whatwg-boun...@lists.whatwg.org whatwg-boun...@lists.whatwg.org on
behalf of Cameron Jones cmhjo...@gmail.com
Sent: Wednesday, February 19, 2014 07:09
To: Nils Dagsson Moskopp
Cc: whatwg; Ian Hickson; Jonathan Watt; Qebui Nehebkau
Subject: Re: [whatwg] input type=number for year input
On Wed, Feb 19, 2014 at 11:38 AM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
Qebui Nehebkau qebui.nehebkau+wha...@gmail.com writes:
On Wed, Feb 19, 2014 at 4:32 AM, Nils Dagsson Moskopp
n...@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 jkorp...@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
n...@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
Re: [whatwg] input type=number for year input
2014-02-19 11:10, Smylers wrote:
Jukka K. Korpela writes:
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.
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
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. 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...).
So in the input process, a year number is not treated like a number. It
typically appears when asking for year of birth or some other event
(marriage, employment, etc.). The input check is normally against any
non-digit data, the kind of thing we can do with pattern=...
Logically, one might say that since asking for a year is very often an
alternative to asking for more specific data such as month or day, it
should be treated as date and time input rather than text input with
restrictions. But I don't see how this would be practically relevant.
What else could input type=year be other than reading some digits?
There is the possibility of allowing two-digit numbers, with an implied
century, but if that is desirable, authors can use input type=text
pattern=\d{4}|\d{2} and deal with the implied century in their own code.
Yucca
Re: [whatwg] input type=number for year input
Jukka K. Korpela writes: 2014-02-19 11:10, Smylers wrote: Jukka K. Korpela writes: 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. 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 Mathematically, you are right, but input types aren't based on general properties of quantities but on practical classification of input data. That's a reasonable way of doing it. All the examples I gave, including year numbers, are normally input by typing the digits Many other numbers — actual, no-doubt-about-it, definitely 100% genuine numbers — are also typically typed in. - in contrast with, say, using a color picker, a data picker, or a slider. 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. Obviously not every year actually gets treated as a number, but there are many situations where they are, and where a number input control makes sense for them. Contrast this with credit card numbers or telephone numbers, which never actually get treated as numbers (unless you want a form with the ability to easily cycle through the final digit of a credit card number until it passes the mod 10 check!). 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...). Many people, at least in the UK, don't bother with a thousands separator in 4-digit numbers anyway, but probably would put them in a 5-digit year. The style guides Mike quoted (which in general did use commas in 4-digit numbers) also had other categories apart from years which don't use commas, including page numbers. Page numbers are undoubtedly numbers, and it definitely makes sense to provide up/down arrows for them. So if we wish to be able to follow those style guides, we still need to be able to provide comma-less input type=number controls for page numbers, regardless of whether you consider a year to be a number. If we don't care about following those style guides, we could simply go with Hixie's suggestion of never putting thousands separators in 4-digit numbers. In neither case does decreeing that years aren't numbers actually help. Cheers Smylers -- http://twitter.com/Smylers2
Re: [whatwg] input type=number for year input
On Wed, Feb 19, 2014 at 11:38 AM, Nils Dagsson Moskopp n...@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. 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. 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.
Re: [whatwg] input type=number for year input
Qebui Nehebkau qebui.nehebkau+wha...@gmail.com writes: On Wed, Feb 19, 2014 at 11:38 AM, Nils Dagsson Moskopp n...@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 time2014/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: labeltemperature input type=number unit-type=K value=453.15/label labelcooking time input type=number unit-type=s value=900/label labelbeep 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
Re: [whatwg] input type=number for year input
Hi, The current WebKit/Blink behavior is: - Accept both of the ASCII digits and localized digits - Accept both of the standard decimal point '.' and a localized decimal point - Not accept grouping separators and don't show grouping separators We showed grouping separators in the past. But we stopped it because grouping separators disturb some use cases. We accepted entering grouping separators in the past. But we stopped it because users had to know their locale correctly. e.g. 1,234 has different meaning in French locale and English locale if we support grouping separators. On Wed, Feb 19, 2014 at 8:09 AM, Jonathan Watt jw...@jwatt.org wrote: When implementing input type=number for Mozilla I decided to display the value to the user using the grouping separator (generally the thousands separator) of the users locale. So, for example, if the input's value is 1234 and the user's locale is English, it is displayed to the user as 1,234. This is causing a problem for at least media wiki, because they use input type=number for year input. For example: https://en.wikipedia.org/w/index.php?title=IRIXaction=history https://en.wikipedia.org/wiki/Special:Contributions/newbies The question is, should I change Mozilla's implementation to stop displaying the internal value using grouping separators, or is it wrong to use input type=number for year input. I'm erring on the former, but I'd like to solicit others' thoughts on this matter. I should also note that I can still allow the implementation to accept input from the user that contains grouping separators, even if when the internal value is set/changed the visual result will be updated to a string that does not contain grouping separators. -- TAMURA, Kent Software Engineer, Google
Re: [whatwg] input type=number for year input
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 time2014/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: labeltemperature input type=number unit-type=K value=453.15/label labelcooking time input type=number unit-type=s value=900/label labelbeep 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.
[whatwg] input type=number for year input
When implementing input type=number for Mozilla I decided to display the value to the user using the grouping separator (generally the thousands separator) of the users locale. So, for example, if the input's value is 1234 and the user's locale is English, it is displayed to the user as 1,234. This is causing a problem for at least media wiki, because they use input type=number for year input. For example: https://en.wikipedia.org/w/index.php?title=IRIXaction=history https://en.wikipedia.org/wiki/Special:Contributions/newbies The question is, should I change Mozilla's implementation to stop displaying the internal value using grouping separators, or is it wrong to use input type=number for year input. I'm erring on the former, but I'd like to solicit others' thoughts on this matter. I should also note that I can still allow the implementation to accept input from the user that contains grouping separators, even if when the internal value is set/changed the visual result will be updated to a string that does not contain grouping separators.
Re: [whatwg] input type=number for year input
On Tue, 18 Feb 2014, Jonathan Watt wrote: When implementing input type=number for Mozilla I decided to display the value to the user using the grouping separator (generally the thousands separator) of the users locale. So, for example, if the input's value is 1234 and the user's locale is English, it is displayed to the user as 1,234. This is causing a problem for at least media wiki, because they use input type=number for year input. For example: https://en.wikipedia.org/w/index.php?title=IRIXaction=history https://en.wikipedia.org/wiki/Special:Contributions/newbies The question is, should I change Mozilla's implementation to stop displaying the internal value using grouping separators, or is it wrong to use input type=number for year input. I'm erring on the former, but I'd like to solicit others' thoughts on this matter. I should also note that I can still allow the implementation to accept input from the user that contains grouping separators, even if when the internal value is set/changed the visual result will be updated to a string that does not contain grouping separators. My recommendation would be to just use comma separation for numbers greater than . It doesn't help that much for four-digit numbers, and years beyond four digits often _do_ have commas, e.g.: http://en.wikipedia.org/wiki/Year_10,000_problem I agree that it's a bit weird (though not particularly wrong) for four-digit years to have commas. type=number does seem appropriate for years, though. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] input type=number for year input
On 18/02/2014 23:09, Jonathan Watt wrote: When implementing input type=number for Mozilla I decided to display the value to the user using the grouping separator (generally the thousands separator) of the users locale. So, for example, if the input's value is 1234 and the user's locale is English, it is displayed to the user as 1,234. This is causing a problem for at least media wiki, because they use input type=number for year input. For example: https://en.wikipedia.org/w/index.php?title=IRIXaction=history https://en.wikipedia.org/wiki/Special:Contributions/newbies The question is, should I change Mozilla's implementation to stop displaying the internal value using grouping separators, or is it wrong to use input type=number for year input. I'm erring on the former, but I'd like to solicit others' thoughts on this matter. I should also note that I can still allow the implementation to accept input from the user that contains grouping separators, even if when the internal value is set/changed the visual result will be updated to a string that does not contain grouping separators. I should also have noted that I did get some early feedback that failing to include grouping separators in the general input type=number case would be bad/suboptimal for certain locales, but I can't remember which locales those were at this point. If anyone knows of such locales I'd be interested to hear which.
Re: [whatwg] input type=number for year input
On 18/02/2014 23:17, Ian Hickson wrote: On Tue, 18 Feb 2014, Jonathan Watt wrote: When implementing input type=number for Mozilla I decided to display the value to the user using the grouping separator (generally the thousands separator) of the users locale. So, for example, if the input's value is 1234 and the user's locale is English, it is displayed to the user as 1,234. This is causing a problem for at least media wiki, because they use input type=number for year input. For example: https://en.wikipedia.org/w/index.php?title=IRIXaction=history https://en.wikipedia.org/wiki/Special:Contributions/newbies The question is, should I change Mozilla's implementation to stop displaying the internal value using grouping separators, or is it wrong to use input type=number for year input. I'm erring on the former, but I'd like to solicit others' thoughts on this matter. I should also note that I can still allow the implementation to accept input from the user that contains grouping separators, even if when the internal value is set/changed the visual result will be updated to a string that does not contain grouping separators. My recommendation would be to just use comma separation It would be the appropriate separator(s) for the locale in use, not necessarily the comma, but I'm guessing that's what you meant. for numbers greater than . It doesn't help that much for four-digit numbers, and years beyond four digits often _do_ have commas, e.g.: http://en.wikipedia.org/wiki/Year_10,000_problem I agree that it's a bit weird (though not particularly wrong) for four-digit years to have commas. Personally I think it's a bit more than a bit weird to have Year: 2,014. It seems pretty ugly to me, and four digit years are going to be the common case. type=number does seem appropriate for years, though. I wonder if it would be that bad to have a 'year' type to compliment the 'month' and 'day' types...
Re: [whatwg] input type=number for year input
On 2/18/14, 17:17, Ian Hickson wrote: On Tue, 18 Feb 2014, Jonathan Watt wrote: The question is, should I change Mozilla's implementation to stop displaying the internal value using grouping separators, or is it wrong to use input type=number for year input. I'm erring on the former, but I'd like to solicit others' thoughts on this matter. My recommendation would be to just use comma separation for numbers greater than . Perhaps unrelated, but that would solve the type=number-for-tcp-ports-looks-kinda-weird problem: https://cloudup.com/cKEisWEkvjv -- Mike Taylor Web Compat, Mozilla
Re: [whatwg] input type=number for year input
On 2/18/14, 17:55, Mike Taylor wrote: On 2/18/14, 17:17, Ian Hickson wrote: On Tue, 18 Feb 2014, Jonathan Watt wrote: The question is, should I change Mozilla's implementation to stop displaying the internal value using grouping separators, or is it wrong to use input type=number for year input. I'm erring on the former, but I'd like to solicit others' thoughts on this matter. My recommendation would be to just use comma separation for numbers greater than . Perhaps unrelated, but that would solve the type=number-for-tcp-ports-looks-kinda-weird problem: https://cloudup.com/cKEisWEkvjv (for ports under , that is) -- Mike Taylor Web Compat, Mozilla
Re: [whatwg] input type=number for year input
On Tue, 18 Feb 2014, Jonathan Watt wrote: My recommendation would be to just use comma separation It would be the appropriate separator(s) for the locale in use, not necessarily the comma, but I'm guessing that's what you meant. Sure. for numbers greater than . It doesn't help that much for four-digit numbers, and years beyond four digits often _do_ have commas, e.g.: http://en.wikipedia.org/wiki/Year_10,000_problem I agree that it's a bit weird (though not particularly wrong) for four-digit years to have commas. Personally I think it's a bit more than a bit weird to have Year: 2,014. It seems pretty ugly to me, and four digit years are going to be the common case. type=number does seem appropriate for years, though. 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. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] input type=number for year input
2014-02-19 1:59, Ian Hickson wrote: I would be interested in hearing more about the locales where not using separators even for four digits is bad/suboptimal. It would break a few national standards on number representation. 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. Breaking standards or practices documented at CLDR just because some 4-digit number might be a year number sounds like rather arbitrary. It would be simpler to just say that input type=number is meant for normal numeric input where some locale definitions are supposed to apply. Using such an element normally makes sense only when we can expect the actual user input to be most often close to the initial value provided, so that the up and down functions make sense. For simply checking that the input is a digit sequence, input type=text pattern= is much more natural. Yucca
Re: [whatwg] input type=number for year input
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Ian Hickson i...@hixie.ch, 2014-02-18 23:59 +: 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). --Mike - -- Michael[tm] Smith http://people.w3.org/mike -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJTA/tCAAoJEIfRdHe8OkuV2aAP/iRM71IfqZtGq4RojC9iPBEe rBCMCd7X0JfqCibx+FIhXtaXoLwyqzK6ALM0I9XxHKzXhi1Ioqg67mLNif+ch8vu UNwwE/NYbjHkymspxg0N0IOQjTPcwDpra7avDjqmtzVsJImqe2nwEmKr9lfhl+NS GCu+U2f2Uoh5UTw10RAscRbODZoqbWcNboI7wGNXeavzckcaVvj7ePN9mjTty96N OmB2E+lgrlrrQXdHM2Vp5cuduPxoXUaEzOxEUc8la7P50/zgP+HW9Ultx0WC1g/3 5a1gpiuXteEdiCYbOz1sjP/XiCTMGNnUUFlWsSt8Rd/NC5tTbpM85vJsXabeLWnm 1Od4NhPHvcUAeHO+J+DtfmSDYB9G09NMAlMzFvhZyIxXlFGxGAvk5SRufvzzzk1B r9tTSFRiDsFyLIu9ILfe0ssXLpyrrq/0qV+QwAyebpBWSvewBnbEdeV5b3l4xVhc HKY9CU0/YOaJrmJ6gSVI1BB7wDE1Hpo7OwAXsAXIW7NrlLGNCj/d/ycJlBClIfrf T4ZoPxWnO2ijvp8niENZmbvU3SnNWiduWygZtwzlOUw2fNqHrR4g/PW+oo9d/qhN j97LOXwkFVM8cw4SjLaLctOxkgine96xQR8q38rwdLQ6PCmk4Bq5U12w9NkSAemR envZdVX/S7hoY3DrDzCW =gY28 -END PGP SIGNATURE-
Re: [whatwg] input type=number for year input
Le 19 févr. 2014 à 08:17, Ian Hickson i...@hixie.ch a écrit : It doesn't help that much for four-digit numbers, and years beyond four digits often _do_ have commas, e.g.: http://en.wikipedia.org/wiki/Year_10,000_problem In English. The same page you used: 西暦1年問題 Problema del año 1 Y10K 1년 문제 Проблема 1 года Проблема 1 року 1年问题 For example, the comma in France is used for 10,5 as in 10.5 (21/2). And the space is used as a separator 11 222 333,44 A good source for different conventions depending on the locales. http://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Conventions_concernant_les_nombres http://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Dates_and_numbers http://de.wikipedia.org/wiki/Wikipedia:Schreibweise_von_Zahlen http://zh.wikipedia.org/wiki/Wikipedia:%E6%A0%BC%E5%BC%8F%E6%89%8B%E5%86%8C/%E6%97%A5%E6%9C%9F%E5%92%8C%E6%95%B0%E5%AD%97 etc. I wonder if it would not be more flexible to have a `format` attribute. input type=number format=%Y/ (or any other formatting syntax) -- Karl Dubost http://www.la-grange.net/karl/
Re: [whatwg] input type=number for year input
On 19/02/2014 01:24, Karl Dubost wrote: I wonder if it would not be more flexible to have a `format` attribute. input type=number format=%Y/ (or any other formatting syntax) I'm not sure a formatting attribute is desirable, at least not if it leads to content authors making decisions that are inappropriate for a given locale. A boolean attribute to say that the grouping separator is not appropriate might be useful though, given the other comments on this thread regarding other number types where such separators would be undesirable, and may not be so subject to misuse. It's not clear that in all these cases (or even in the case of years) that the grouping separator is undesirable for all locales though.
Re: [whatwg] input type=number for year input
On Tuesday, February 18, 2014 8:24 PM Karl Dubost wrote Le 19 févr. 2014 à 08:17, Ian Hickson i...@hixie.ch a écrit : It doesn't help that much for four-digit numbers, and years beyond four digits often _do_ have commas, e.g.: http://en.wikipedia.org/wiki/Year_10,000_problem In English. The same page you used: 西暦1年問題 Problema del año 1 Y10K 1년 문제 Проблема 1 года Проблема 1 року 1年问题 For example, the comma in France is used for 10,5 as in 10.5 (21/2). And the space is used as a separator 11 222 333,44 A good source for different conventions depending on the locales. http://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Conventions_concernant_les_nombres http://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Dates_and_numbers http://de.wikipedia.org/wiki/Wikipedia:Schreibweise_von_Zahlen http://zh.wikipedia.org/wiki/Wikipedia:%E6%A0%BC%E5%BC%8F%E6%89%8B%E5%86%8C/%E6%97%A5%E6%9C%9F%E5%92%8C%E6%95%B0%E5%AD%97 etc. I wonder if it would not be more flexible to have a `format` attribute. input type=number format=%Y/ (or any other formatting syntax) -- What fun! 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.555... 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. Cheers David
Re: [whatwg] input type=number for year input
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? Cheers D -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Michael[tm] Smith Sent: Tuesday, February 18, 2014 7:31 PM To: Ian Hickson Cc: whatwg; Jonathan Watt Subject: Re: [whatwg] input type=number for year input -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Ian Hickson i...@hixie.ch, 2014-02-18 23:59 +: 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). --Mike - -- Michael[tm] Smith http://people.w3.org/mike -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJTA/tCAAoJEIfRdHe8OkuV2aAP/iRM71IfqZtGq4RojC9iPBEe rBCMCd7X0JfqCibx+FIhXtaXoLwyqzK6ALM0I9XxHKzXhi1Ioqg67mLNif+ch8vu UNwwE/NYbjHkymspxg0N0IOQjTPcwDpra7avDjqmtzVsJImqe2nwEmKr9lfhl+NS GCu+U2f2Uoh5UTw10RAscRbODZoqbWcNboI7wGNXeavzckcaVvj7ePN9mjTty96N OmB2E+lgrlrrQXdHM2Vp5cuduPxoXUaEzOxEUc8la7P50/zgP+HW9Ultx0WC1g/3 5a1gpiuXteEdiCYbOz1sjP/XiCTMGNnUUFlWsSt8Rd/NC5tTbpM85vJsXabeLWnm 1Od4NhPHvcUAeHO+J+DtfmSDYB9G09NMAlMzFvhZyIxXlFGxGAvk5SRufvzzzk1B r9tTSFRiDsFyLIu9ILfe0ssXLpyrrq/0qV+QwAyebpBWSvewBnbEdeV5b3l4xVhc HKY9CU0/YOaJrmJ6gSVI1BB7wDE1Hpo7OwAXsAXIW7NrlLGNCj/d/ycJlBClIfrf T4ZoPxWnO2ijvp8niENZmbvU3SnNWiduWygZtwzlOUw2fNqHrR4g/PW+oo9d/qhN j97LOXwkFVM8cw4SjLaLctOxkgine96xQR8q38rwdLQ6PCmk4Bq5U12w9NkSAemR envZdVX/S7hoY3DrDzCW =gY28 -END PGP SIGNATURE-
Re: [whatwg] input type=number for year input
Ian Hickson i...@hixie.ch writes: On Tue, 18 Feb 2014, Jonathan Watt wrote: My recommendation would be to just use comma separation It would be the appropriate separator(s) for the locale in use, not necessarily the comma, but I'm guessing that's what you meant. Sure. for numbers greater than . It doesn't help that much for four-digit numbers, and years beyond four digits often _do_ have commas, e.g.: http://en.wikipedia.org/wiki/Year_10,000_problem I agree that it's a bit weird (though not particularly wrong) for four-digit years to have commas. Personally I think it's a bit more than a bit weird to have Year: 2,014. It seems pretty ugly to me, and four digit years are going to be the common case. type=number does seem appropriate for years, though. 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. 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. 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 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 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. 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 ] [+|-] Greetings, -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] input type=number for year input
2014-02-19 2:30, Michael[tm] Smith wrote:
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.
Similar rules apply to other languages as well. Generally, we should
expect implementations to apply documented locale-specific rules (for
some locale determined somehow). There are different grouping rules,
though; not all locales use groups of three digits. Anyway, we should
expect a 4-digit number to be grouped, with some group separator, rather
often.
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).
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.
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).
Yucca
