Re: [whatwg] Decimal comma in numeric input
On 08/02/2012, at 12:39 AM, Ian Hickson wrote: > On Fri, 20 Jan 2012, Cameron Heavon-Jones wrote: >> >> The lang attribute is the structural declaration of the content's >> localization, be it prose or data values. > > Technically it just sets the language, not the localisation. I expect we > will in due course add an attribute to explicitly set the locale of the > content in the page. How it's rendered would then be controlled by new > features in CSS (e.g. the page locale could be "British", and the > presentation could be "American", which would mean dates would have their > day and month fields flipped over). Similarly, the presentation layer > ultimately controls the widgets, including how they work and what input > formats they expect, e.g. through XBL or whatever replaces it. > > This is all pie in the sky, though, it doesn't exist today. Yes, for the interested the following is a great description of locale\language distinction and it's relative fuzziness: http://unicode.org/reports/tr35/#Locale I think however that the "lang" tag and resolution algorithm is currently more that adequate and takes all the required configuration into account for resolution of declaration and intent. The 'flip' is already possible by user-preference override which appears to mostly be the default implementation choice in browsers. With advancements in data markup and hopefully the universal deferment of presentational rendering into the UA, this would provide consistency for users who want data to be 'flipped' automatically, ie i'm thinking of , and here... the elimination of pre-rendered values is key. I agree that CSS is a better place for this to be defined and XBL the method for rich interfaces. Looking forward to some tasty pie flavoured from around the world, or mashed up into a regional taste :) Quick additional thought, potentially the translate attribute may be used as an additional indicator as to the scope of 'flipping'. Thanks, Cam
Re: [whatwg] Decimal comma in numeric input
On Thu, 19 Jan 2012, John Tamplin wrote: > > [...] a user types "1,575" in a field. Is that interpreted as a value > between 1 and 2 or between 1000 and 2000? [...] That's entirely up to the UA. On Thu, 19 Jan 2012, Bronislav Klu�~Mka wrote: > > This should depend on selected locale, is coma thousands or decimal > separator? Browser should follow such settings and display value > accordingly, but value MUST be sent to server according to 1 set of > rules, regardless of anything else (e.g. no thousands separator and full > stop as decimal separator). No browser locale, no server locale... one > set of rules. Consider JavaScript here... regardless of displayed value, > you always get Number type out of it (not string like 15.123,55 but > 15123.55) So it is just display here, but spec should explain the > difference between display value and underlying data. Correct. On Fri, 20 Jan 2012, Jukka K. Korpela wrote: > 2012-01-20 1:19, David Singer wrote: > > > > What the user enters and sees on screen is a presentational/locale > > issue > > Which one? That's defined by the UA. (The spec has some suggestions.) On Fri, 20 Jan 2012, Cameron Heavon-Jones wrote: > > The lang attribute is the structural declaration of the content's > localization, be it prose or data values. Technically it just sets the language, not the localisation. I expect we will in due course add an attribute to explicitly set the locale of the content in the page. How it's rendered would then be controlled by new features in CSS (e.g. the page locale could be "British", and the presentation could be "American", which would mean dates would have their day and month fields flipped over). Similarly, the presentation layer ultimately controls the widgets, including how they work and what input formats they expect, e.g. through XBL or whatever replaces it. This is all pie in the sky, though, it doesn't exist today. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Decimal comma in numeric input
On 20/01/2012, at 6:52 PM, Bronislav Klučka wrote: > On 20.1.2012 18:52, Cameron Heavon-Jones wrote: >> >> >> The lang attribute is the structural declaration of the content's >> localization, be it prose or data values. There should be no difference in >> what the following mean: >> >> This is some english text >> >> >> >> > "English date" is misleading term here > > > is a datetime, not English datetime, not Czech datetime (since time zone > suggests CET), but a datetime, the difference is how it should be presented. > But also in this case translation/language has no meaning here, because of > the time zone in dates, East Coast Time presentation will be different than > London time presentation, it can have the same structure (mm/dd/ > [0-11]:[0-59] am/pm) but values should be different. > And without lang attribute, this should follow users choice > 11/19/2010 2:48 pm in London, 19.11.2010 15:48 in Prague and as such should > be displayed according to localization > > > > > Brona > Yes, i agree that "english date" is slightly confusing but with the in the context of the additional examples i thought it adequately described the problem. I agree with your description of the value of datetime with regards to timezone as a facet of the value. Without any lang resolution within the representation, i agree that the presentation should follow the user's choice locale. No disagreements here. Thanks Cameron Jones
Re: [whatwg] Decimal comma in numeric input
On 20.1.2012 18:52, Cameron Heavon-Jones wrote: The lang attribute is the structural declaration of the content's localization, be it prose or data values. There should be no difference in what the following mean: This is some english text "English date" is misleading term here is a datetime, not English datetime, not Czech datetime (since time zone suggests CET), but a datetime, the difference is how it should be presented. But also in this case translation/language has no meaning here, because of the time zone in dates, East Coast Time presentation will be different than London time presentation, it can have the same structure (mm/dd/ [0-11]:[0-59] am/pm) but values should be different. And without lang attribute, this should follow users choice 11/19/2010 2:48 pm in London, 19.11.2010 15:48 in Prague and as such should be displayed according to localization Brona
Re: [whatwg] Decimal comma in numeric input
Sorry, I didn't mean to argue that CSS should be involved, merely that the communication user to user-agent should be considered to use locle-dependent formats, and that the communication user-agent to server should be in a standard format. On Jan 19, 2012, at 16:29 , Jukka K. Korpela wrote: > 2012-01-20 1:19, David Singer wrote: > >> What the user enters and sees on screen is a presentational/locale issue > > Which one? “Presentational” normally refers to things like layout design, > colors, fonts, and borders. Locales are something different. > > The difference between “1.005” meaning one thousand and five vs. one and five > thousandths is normally regarded as a locale difference, and nobody has > suggested that that it should be handled in CSS when it is about document > content. > > Why would things suddenly change when it comes to user interface? Besides, > there is nothing in CSS as currently defined that even tries to address such > issues. > > Yucca > David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Decimal comma in numeric input
On 20/01/2012, at 1:33 PM, Bronislav Klučka wrote: > On 20.1.2012 1:29, Jukka K. Korpela wrote: >> >> Why would things suddenly change when it comes to user interface? Besides, >> there is nothing in CSS as currently defined that even tries to address such >> issues. >> >> Yucca > > I've joined this discussion to point out the difference between presentation > and data behind it. But I agree, this has nothing to do with CSS, this should > not be handled by CSS. I'd prefer lang attribute here: if not presented > (directly on input element) then users OS locale should be used (or maybe > some general browser settings), if presented, format defined by that locale > should be used (the same process should apply to date inputs as well). > > Brona The lang attribute is the structural declaration of the content's localization, be it prose or data values. There should be no difference in what the following mean: This is some english text This methods allows for an element-by-element application of localization enabling multi-lingual pages to exist. Added to the hierarchical resolution of language tags and this enables effective declaration. Add the tags and http headers and you have a compete resolution algorithm. Only once all of these avenues have been exhausted does the resolution of content language enter an ambiguous state whereby a user's default preference should be used. Do not forget that the UA specifies a user's preference in the Accept-Language header. If a server is incapable of providing a localized representation then what is returned is the most relevant representation available and as a result the one that the user has requested to see. It is up to the server to define the representation of a resource based on all request information and it is the UA's responsibility to render *that* representation for the user. There is a usability case for the UA to translate the content automagically for the benefit of the user, but this is assuming that the user desires this feature and is not multilingual and just navigating to a foreign site. For them to have to adjust their locale settings each time they do this is a disaster. Automatic translation as an option is better as it could be applied for white\black-list configured languages and will take responsibility for translating the entire content (or potentially translate="yes" elements) and not just form inputs. The method for how to handle data entry on inputs should be defined by the resolved language of the element per the algorithm. This is the only method which makes sense especially if you examine use cases for text entry as well as numerical or temporal data values. In this case the form author is defining which language of input they desire whereby dictionary and additional assistance can be given. By automatically applying a static application-level setting the user will always be given assistance in their own language which isn't very helpful in answering a question such as "what is your favourite colour?" for a different language. Even for non-native speakers with such auto-assistance even i might be able to enter a correct value in french or whatever other language was defined on the page\element. The notion that native periods or comma usage in data entry is too confusing to decipher fails to take into account they the user has already navigated to a foreign language page and is obviously already capable of interacting with it enough to decipher what the form they are entering data into means. Possibly the addition of a placeholder text would definitively communicate this to the user for these types. The case for CSS presentational specification of formatting is desirable in the case of date\time values which typically can take a large variety of formats and is distinct from their value. Unicode defines both enumerated FULL, LONG, MEDIUM, SHORT pre-configured settings and symbol format templates. Since these have no affect on the data values themselves the place seems to be CSS, however their interaction with data entry would in effect result in applying pattern restriction in order to retain parsing ability. For this reason i think this negates using CSS for this purpose in favour of possibly a format attribute or such. Thanks, Cameron Jones
Re: [whatwg] Decimal comma in numeric input
On 20.1.2012 1:29, Jukka K. Korpela wrote: Why would things suddenly change when it comes to user interface? Besides, there is nothing in CSS as currently defined that even tries to address such issues. Yucca I've joined this discussion to point out the difference between presentation and data behind it. But I agree, this has nothing to do with CSS, this should not be handled by CSS. I'd prefer lang attribute here: if not presented (directly on input element) then users OS locale should be used (or maybe some general browser settings), if presented, format defined by that locale should be used (the same process should apply to date inputs as well). Brona
Re: [whatwg] Decimal comma in numeric input
2012-01-20 1:19, David Singer wrote: What the user enters and sees on screen is a presentational/locale issue Which one? “Presentational” normally refers to things like layout design, colors, fonts, and borders. Locales are something different. The difference between “1.005” meaning one thousand and five vs. one and five thousandths is normally regarded as a locale difference, and nobody has suggested that that it should be handled in CSS when it is about document content. Why would things suddenly change when it comes to user interface? Besides, there is nothing in CSS as currently defined that even tries to address such issues. Yucca
Re: [whatwg] Decimal comma in numeric input
On Jan 19, 2012, at 13:35 , Bronislav Klučka wrote: > > > On 19.1.2012 21:51, John Tamplin wrote: >> On Thu, Jan 19, 2012 at 3:38 PM, Ian Hickson wrote: >> > On Thu, 14 Apr 2011, John Tamplin wrote: > Indeed. To solve this, we need help from CSS. That's one of the reasons > we created in HTML. This is about data representation and localization, not about optional stylistic suggestions, so CSS is a wrong way to deal with the issue. >>> I disagree. It's entirely a presentational issue. It's almost the >>> _definition_ of a presentational issue. >> >> I still disagree -- a user types "1,575" in a field. Is that interpreted >> as a value between 1 and 2 or between 1000 and 2000? Interpretation of the >> value entered by the user has nothing to do with CSS. >> > > This should depend on selected locale, is coma thousands or decimal > separator? Browser should follow such settings and display value accordingly, > but value MUST be sent to server according to 1 set of rules, regardless of > anything else (e.g. no thousands separator and full stop as decimal > separator). No browser locale, no server locale... one set of rules. > Consider JavaScript here... regardless of displayed value, you always get > Number type out of it (not string like 15.123,55 but 15123.55) > So it is just display here, but spec should explain the difference between > display value and underlying data. Yes. What the user enters and sees on screen is a presentational/locale issue mediated by the browser etc. What an API returns, a form sends, etc., when it is a number in string format, should be fixed. David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Decimal comma in numeric input
On 19.1.2012 21:51, John Tamplin wrote: On Thu, Jan 19, 2012 at 3:38 PM, Ian Hickson wrote: On Thu, 14 Apr 2011, John Tamplin wrote: Indeed. To solve this, we need help from CSS. That's one of the reasons we created in HTML. This is about data representation and localization, not about optional stylistic suggestions, so CSS is a wrong way to deal with the issue. I disagree. It's entirely a presentational issue. It's almost the _definition_ of a presentational issue. I still disagree -- a user types "1,575" in a field. Is that interpreted as a value between 1 and 2 or between 1000 and 2000? Interpretation of the value entered by the user has nothing to do with CSS. This should depend on selected locale, is coma thousands or decimal separator? Browser should follow such settings and display value accordingly, but value MUST be sent to server according to 1 set of rules, regardless of anything else (e.g. no thousands separator and full stop as decimal separator). No browser locale, no server locale... one set of rules. Consider JavaScript here... regardless of displayed value, you always get Number type out of it (not string like 15.123,55 but 15123.55) So it is just display here, but spec should explain the difference between display value and underlying data. Brona.
Re: [whatwg] Decimal comma in numeric input
On Thu, Jan 19, 2012 at 3:38 PM, Ian Hickson wrote: > > > On Thu, 14 Apr 2011, John Tamplin wrote: > > > > > > > > The entire web application, which includes both client and > > > > server-side code, must have the same idea about what locale the user > > > > is using. If the app provides a drop-down box or preference setting > > > > to choose a different locale, as most localized apps do, the web > > > > browser has to be using the same locale for any native locale > > > > processing it uses. Otherwise, you run a serious risk of having > > > > incorrect data -- if a user types "10,000" in a field when they > > > > think they are using a locale with a comma as the decimal separator, > > > > does the app receive that as 1 or 10.000? If the app is running > > > > in en-US because the user requested it or their system locale isn't > > > > supported by the app, and the browser sends "10.000" as the value > > > > because the system locale is "de", then that is a problem. > > > > > > Indeed. To solve this, we need help from CSS. That's one of the > > > reasons we created in HTML. > > > > This is about data representation and localization, not about optional > > stylistic suggestions, so CSS is a wrong way to deal with the issue. > > I disagree. It's entirely a presentational issue. It's almost the > _definition_ of a presentational issue. I still disagree -- a user types "1,575" in a field. Is that interpreted as a value between 1 and 2 or between 1000 and 2000? Interpretation of the value entered by the user has nothing to do with CSS. -- John A. Tamplin Software Engineer (GWT), Google
Re: [whatwg] Decimal comma in numeric input
On Sat, 16 Jul 2011, Jukka K. Korpela wrote: > 16.07.2011 00:01, Ian Hickson wrote: > > > Much discussion on this topic happened when we started on this work in > > 2004 and 2005, I highly recommend perusing the archives around that > > time. > > Authors and implementors will need to be able to understand the topic > without checking discussions archives, so the specs should say at least > a little about the issue that the rules for user’s input may be quite > different from the rules for the as stored and forwared. And users will > be confused anyway, when user interfaces work oddly. Ok, done. > > On Thu, 14 Apr 2011, John Tamplin wrote: > > > > > > The entire web application, which includes both client and > > > server-side code, must have the same idea about what locale the user > > > is using. If the app provides a drop-down box or preference setting > > > to choose a different locale, as most localized apps do, the web > > > browser has to be using the same locale for any native locale > > > processing it uses. Otherwise, you run a serious risk of having > > > incorrect data -- if a user types "10,000" in a field when they > > > think they are using a locale with a comma as the decimal separator, > > > does the app receive that as 1 or 10.000? If the app is running > > > in en-US because the user requested it or their system locale isn't > > > supported by the app, and the browser sends "10.000" as the value > > > because the system locale is "de", then that is a problem. > > > > Indeed. To solve this, we need help from CSS. That's one of the > > reasons we created in HTML. > > This is about data representation and localization, not about optional > stylistic suggestions, so CSS is a wrong way to deal with the issue. I disagree. It's entirely a presentational issue. It's almost the _definition_ of a presentational issue. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Decimal comma in numeric input
On 16/07/2011, at 5:52 AM, Jukka K. Korpela wrote: > 16.07.2011 00:01, Ian Hickson wrote: > >> Much discussion on this topic happened when we started on this work in >> 2004 and 2005, I highly recommend perusing the archives around that time. > > Authors and implementors will need to be able to understand the topic without > checking discussions archives, so the specs should say at least a little > about the issue that the rules for user’s input may be quite different from > the rules for the as stored and forwared. And users will be confused anyway, > when user interfaces work oddly. Yes, or if you have the knowledge of these discussions perhaps some additional assistance in locating any specific items would be helpful? >> On Thu, 14 Apr 2011, John Tamplin wrote: >>> >>> The entire web application, which includes both client and server-side >>> code, must have the same idea about what locale the user is using. If >>> the app provides a drop-down box or preference setting to choose a >>> different locale, as most localized apps do, the web browser has to be >>> using the same locale for any native locale processing it uses. >>> Otherwise, you run a serious risk of having incorrect data -- if a user >>> types "10,000" in a field when they think they are using a locale with a >>> comma as the decimal separator, does the app receive that as 1 or >>> 10.000? If the app is running in en-US because the user requested it or >>> their system locale isn't supported by the app, and the browser sends >>> "10.000" as the value because the system locale is "de", then that is a >>> problem. >> >> Indeed. To solve this, we need help from CSS. That's one of the reasons we >> created in HTML. > Concerned about . > This is about data representation and localization, not about optional > stylistic suggestions, so CSS is a wrong way to deal with the issue. It will > probably cause _further_ confusion. > > I’m afraid the new input types for numeric data and for dates and times, even > when implemented in browsers, will be of very limited usefulness and will > cause more damage than good, unless the localization issues will be properly > addressed. > > It is part of the risk that they often _seemingly_ work. For example, an > author would use and test the software thoroughly by his > own standards, but the standards don’t include testing with the system’s UI > language being other than English. So things seem to work until someone tries > to put a bid of 10,000 dollars but gets it turned to 10 dollars and loses, or > makes a date for 7/4/2012 and gets it interpreted as April 7 when he meant > July 4, or vice versa. > > I’m afraid many authors will start using the new types eagerly when browser > support comes sufficiently widespread. It looks so much better, cooler, and > easier than parsing data yourself or requiring the user to type data in > specifically instructed format. But it’s a dangerous illusion. > > -- > Yucca, http://www.cs.tut.fi/~jkorpela/ Yes, i agree. I've opened a bug about the handling of i18n by user agents: http://www.w3.org/Bugs/Public/show_bug.cgi?id=13408 In response to the question of how to manage the formatting and encoding of i18n data values, the element's declared or derived lang should be used. the form element also contains a lang attribute and it is this which should be used to encode the data for submission and processing, as the author has declared they expect to accept. ie: This input should parse and format the number in the Finish locale, and the form should encode the number in en-US locale. Thanks, Cameron Jones
Re: [whatwg] Decimal comma in numeric input
On 15/04/2011, at 10:56 PM, Aryeh Gregor wrote: > Trying to add more features to the > new form stuff is premature when we only have one really good > implementation (IMO: Gecko's), and that implementation is partial. > The time to talk about new features is when we have some amount of > stability and interoperability in existing features. However, features resulting from new, or more clarified, requirements would seem to require immediate attention in order to avoid such 'complete' implementations and their expectation of validity and continuance. Thanks, Cameron Jones
Re: [whatwg] Decimal comma in numeric input
16.07.2011 00:01, Ian Hickson wrote: Much discussion on this topic happened when we started on this work in 2004 and 2005, I highly recommend perusing the archives around that time. Authors and implementors will need to be able to understand the topic without checking discussions archives, so the specs should say at least a little about the issue that the rules for user’s input may be quite different from the rules for the as stored and forwared. And users will be confused anyway, when user interfaces work oddly. On Thu, 14 Apr 2011, John Tamplin wrote: The entire web application, which includes both client and server-side code, must have the same idea about what locale the user is using. If the app provides a drop-down box or preference setting to choose a different locale, as most localized apps do, the web browser has to be using the same locale for any native locale processing it uses. Otherwise, you run a serious risk of having incorrect data -- if a user types "10,000" in a field when they think they are using a locale with a comma as the decimal separator, does the app receive that as 1 or 10.000? If the app is running in en-US because the user requested it or their system locale isn't supported by the app, and the browser sends "10.000" as the value because the system locale is "de", then that is a problem. Indeed. To solve this, we need help from CSS. That's one of the reasons we created in HTML. This is about data representation and localization, not about optional stylistic suggestions, so CSS is a wrong way to deal with the issue. It will probably cause _further_ confusion. I’m afraid the new input types for numeric data and for dates and times, even when implemented in browsers, will be of very limited usefulness and will cause more damage than good, unless the localization issues will be properly addressed. It is part of the risk that they often _seemingly_ work. For example, an author would use and test the software thoroughly by his own standards, but the standards don’t include testing with the system’s UI language being other than English. So things seem to work until someone tries to put a bid of 10,000 dollars but gets it turned to 10 dollars and loses, or makes a date for 7/4/2012 and gets it interpreted as April 7 when he meant July 4, or vice versa. I’m afraid many authors will start using the new types eagerly when browser support comes sufficiently widespread. It looks so much better, cooler, and easier than parsing data yourself or requiring the user to type data in specifically instructed format. But it’s a dangerous illusion. -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] Decimal comma in numeric input
On Thu, 14 Apr 2011, Jukka K. Korpela wrote: > > I was surprised at seeing that the Finnish-language version of Google > Chrome 11 beta accepts a number with a comma, such as "4,2", in type="number">. It silently converts the comma to a full stop, "4.2". > > This looked like a useful feature at first sight, as decimal comma is > standard in Finnish as in most human languages. But this seems to > violate the rules, since is defined as allowing a > "valid floating point number" (the definition of which clearly allows > FULL STOP as the only decimal separator) only and, moreover, there is > prescribed error processing: an error shall be returned, and the value > sanitization algorithm shall set the value to the empty string; ref.: > http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#number-state > > So the Google Chrome implementation is in error here, right? No, it's exactly right. You are confusing the UI with the submitted value. On Thu, 14 Apr 2011, Old�ich Vete�n�k wrote: > > I am afraid that if the decimal separator (in rendering) doesn't behave > the way people expect it to, it will mean web developers will have to > deal with clients saying "We wan't to be able to enter a comma." The > "dealing" might mean not using at all, which is > something we might not want... That is a risk, it is true. On Fri, 15 Apr 2011, Aryeh Gregor wrote: > > I didn't read the whole thread, but: authors with specific needs will > always want to roll their own inputs for most of these things, and > that's fine. If satisfies 80% of the use-cases, > that's fine. As more authors start using the new input types, we'll get > feedback about what the most-requested features are, and we can consider > adding them at that time. Trying to add more features to the new form > stuff is premature when we only have one really good implementation > (IMO: Gecko's), and that implementation is partial. The time to talk > about new features is when we have some amount of stability and > interoperability in existing features. Indeed. On Mon, 18 Apr 2011, Jukka K. Korpela wrote: > > My original observation was that Google Chrome accepts a number with > decimal comma. It does that quite independently of the language. As far > as specifications go, it could just as well _only_ accept decimal comma. > Would that be perfectly suitable? Per spec, yes. Of course, it would be a pretty poor user experience. But that's just a UI issue. What it _should_ do is magically guess what the user meant and just do the right thing. Failing that, an approximation based on the user's preferences and locale, and the page's locale and style sheets. On Thu, 14 Apr 2011, Jukka K. Korpela wrote: > > In general with the new input types, we have the problem that when they > are not supported but degrade to , the user would > need instructions on data format, e.g. saying that decimal point be used > or that a color be specified as #hh - and these would look stupid > when they are not needed. But this can probably be handled reasonably > using scripts that test for the support first. Or maybe it would be more > robust, transitionally, to include the instructions and type="text"> in markup, with client-side scripting then trying to set > the state to, say, "number", and when successful, removing the > instructions (or replacing them with some different instructions). Indeed. Much discussion on this topic happened when we started on this work in 2004 and 2005, I highly recommend perusing the archives around that time. On Thu, 14 Apr 2011, John Tamplin wrote: > > The entire web application, which includes both client and server-side > code, must have the same idea about what locale the user is using. If > the app provides a drop-down box or preference setting to choose a > different locale, as most localized apps do, the web browser has to be > using the same locale for any native locale processing it uses. > Otherwise, you run a serious risk of having incorrect data -- if a user > types "10,000" in a field when they think they are using a locale with a > comma as the decimal separator, does the app receive that as 1 or > 10.000? If the app is running in en-US because the user requested it or > their system locale isn't supported by the app, and the browser sends > "10.000" as the value because the system locale is "de", then that is a > problem. Indeed. To solve this, we need help from CSS. That's one of the reasons we created in HTML. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Decimal comma in numeric input
Dne Fri, 15 Apr 2011 23:56:45 +0200 Aryeh Gregor napsal(a): 2011/4/14 Oldřich Vetešník : I am afraid that if the decimal separator (in rendering) doesn't behave the way people expect it to, it will mean web developers will have to deal with clients saying "We wan't to be able to enter a comma." The "dealing" might mean not using at all, which is something we might not want... I didn't read the whole thread, but: authors with specific needs will always want to roll their own inputs for most of these things, and that's fine. If satisfies 80% of the use-cases, that's fine. As more authors start using the new input types, we'll get feedback about what the most-requested features are, and we can consider adding them at that time. Trying to add more features to the new form stuff is premature when we only have one really good implementation (IMO: Gecko's), and that implementation is partial. The time to talk about new features is when we have some amount of stability and interoperability in existing features. Indeed, good point. Let's wait and see. Ollie
Re: [whatwg] Decimal comma in numeric input
Aryeh Gregor wrote: On Sat, Apr 16, 2011 at 9:18 AM, Jukka K. Korpela wrote: An element for user input of a real number in a format that uses a suitable decimal separator is hardly a "specific need". It's more specific than just an element for user input of a number. This isn't a matter of being more or less specific. It's about adequacy of a concept and acceptability of implementations. Formally, one might say that specifications can define just the internal format and leave the rest to implementors, but that's not a reasonable approach. The current specification is perfectly sufficient for many use-cases -- at a minimum, English-language sites. My original observation was that Google Chrome accepts a number with decimal comma. It does that quite independently of the language. As far as specifications go, it could just as well _only_ accept decimal comma. Would that be perfectly suitable? If there's author demand for control over decimal separators, a new CSS property is probably the right way to do it, No, this is not about optional presentational suggestions concerning the rendering of documents. It's about processing of input data. Something that allows the author to specify what decimal separator is used would certainly be "more features". I wasn't saying that authors should be able to specify what decimal separator is used. I discussed the need for addressing the decimal separator issue and at least specifying _how_ it is decided on. Then authors would know what to expect when they use . -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] Decimal comma in numeric input
On Sat, Apr 16, 2011 at 9:18 AM, Jukka K. Korpela wrote: > An element for user input of a real number in a format that uses a suitable > decimal separator is hardly a "specific need". It's more specific than just an element for user input of a number. We don't even have that implemented well across browsers yet. The current specification is perfectly sufficient for many use-cases -- at a minimum, English-language sites. If there's author demand for control over decimal separators, a new CSS property is probably the right way to do it, which should affect all in-page browser-generated numbers (supposing there are any other than ). But I don't know if there's going to be implementer interest at this stage, before they've even gotten a basic implementation of all the existing input types. In Firefox 4.0, for instance, date inputs don't work at all. I'd be surprised if they prioritized adding new features to number inputs before they've got any date inputs at all. > This is not about "more features". This is about the implementations, and > implementability, of the feature . Something that allows the author to specify what decimal separator is used would certainly be "more features". It would be another thing for UAs to implement and converge on, which takes time and resources that could be devoted to other things. > Is rather about "less features". Maybe should be > restricted to integer input only, on the ground that useful features with > fairly straightforward implementability should be added, without waiting for > clarification of issues related possible extended formats of the features. > > It might even be a good idea to add an element for real number input later > as, say, rather than allowing to > accept real numbers. This would allow e.g. an implementation to provide a > virtual keyboard for with only digits, "+" sign, and > "-" sign, making it clearer that only whole numbers are expected. accepts only integers by default. If you want it to accept non-integers, you have to specify the step attribute. step, min, and max should be enough to allow implementers to provide good UI -- there's no need for a separate type. (I'll add as someone whose academic background is more mathematics than computers: could we please not write standards that call floating-point numbers "reals"? "float" is the more common term anyway, and it doesn't conflict with terminology that long predated computers.)
Re: [whatwg] Decimal comma in numeric input
Aryeh Gregor wrote: I didn't read the whole thread, but: authors with specific needs will always want to roll their own inputs for most of these things, and that's fine. An element for user input of a real number in a format that uses a suitable decimal separator is hardly a "specific need". By "suitable" I mean that the separator corresponds to the user's preferences _or_ the conventions of the (main) language of the page - it is not clear which one should be used, but using either a full stop in all cases (against the rules of most languages of the world) or an unpredictable separator is hardly suitable. Trying to add more features to the new form stuff is premature when we only have one really good implementation (IMO: Gecko's), and that implementation is partial. This is not about "more features". This is about the implementations, and implementability, of the feature . Is rather about "less features". Maybe should be restricted to integer input only, on the ground that useful features with fairly straightforward implementability should be added, without waiting for clarification of issues related possible extended formats of the features. It might even be a good idea to add an element for real number input later as, say, rather than allowing to accept real numbers. This would allow e.g. an implementation to provide a virtual keyboard for with only digits, "+" sign, and "-" sign, making it clearer that only whole numbers are expected. -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] Decimal comma in numeric input
2011/4/14 Oldřich Vetešník : > I am afraid that if the decimal separator (in rendering) doesn't behave the > way people expect it to, it will mean web developers will have to deal with > clients saying "We wan't to be able to enter a comma." The "dealing" might > mean not using at all, which is something we might not > want... I didn't read the whole thread, but: authors with specific needs will always want to roll their own inputs for most of these things, and that's fine. If satisfies 80% of the use-cases, that's fine. As more authors start using the new input types, we'll get feedback about what the most-requested features are, and we can consider adding them at that time. Trying to add more features to the new form stuff is premature when we only have one really good implementation (IMO: Gecko's), and that implementation is partial. The time to talk about new features is when we have some amount of stability and interoperability in existing features.
Re: [whatwg] Decimal comma in numeric input
On Thu, Apr 14, 2011 at 12:40 PM, Jukka K. Korpela wrote: > Well, HTML(5) is not just about client-server applications. It’s also about > offline applications and about the bulk of web and intranet content that > cannot be characterized as “applications” in any significant meaning. > > Moreover, part of the very idea of client-server model is that the client > can handle user interaction in the user’s preferred locale and generally the > way that suits the user, whereas the server-side processing and storage can > use globalized format of data. The server can remain totally ignorant of the > user interaction; it just gets and send data in a global well-defined > format, which may be almost or completely unreadable to humans, or at least > odd-looking to most, like ISO 8601 date and time, language codes, or real > numbers in binary format. > Ok, if you want to say that some apps don't have a server component or that some apps translate to a global format when sending to the server, that is fine. However, it doesn't change the fact that the part running on the client has to know what locale the user is using when interacting with it, and needs to be able to control that rather than using whatever the user's OS is set to. For example, imagine a translation application that will show messages in a source locale and allow the user to edit translations in a different locale. Clearly, the OS is only going to be running in one locale, so if the application relies on the browser which relies on the OS for the locale then it cannot possibly localize the parts of the app appropriate for each of these locales. > New input types like "color", "date", and "number" are interesting steps > towards allowing localized user interfaces with strictly defined and > controlled interfaces to server-side and client-side processing of data. But > they are perhaps not quite _conscious_ steps, and they are relatively > limited, and they are (probably intentionally) silent about most > localization issues. If they don't cover the case of what should happen, then either the implementors implement it the same correct way by chance or the feature can't actually be used by apps that care about localizaiton. > > If the app provides a drop-down box or preference setting >> to choose a different locale, as most localized apps do, >> > > Do they? Some examples: - amazon.com is US English (at least from a US IP address, I don't know if they remap it based on other things, but they definitely don't use Accept-Language to choose). At the bottom of the page is a list of links to other localized versions of the site, like amazon.fr, amazon.it, etc. I don't see any persistent settings for your account. - cnn.com is similar, ignores Accept-Language and lists links to a few localized sites at the bottom of the page - bbc.co.uk is similar, ignoring Accept-Language and providing a large list of locales to choose from in the body of the page - google.com defaults to Accept-Language or IP-based geolocation if you don't have a preference, provides a link to the English version for non-English sites, and allows setting a persistent preference if you are logged in. Note that the list of supported languages includes many not likely to be supported by the OS. - yahoo.com has only an "international" link which then takes you to a large list of localized versions of the site to choose from So if the OS/browser support is sufficient, why do most sites roll their own? > Is that a good move, as opposite to using one centralized set of settings > in the user's system? How many times am I actually supposed to tell my > preferred language, country, currency, decimal separator, and so on, when > using different applications? Localization is far more than choosing a > locale from a dropdown, or at least it should be to be genuinely useful. Setting it in the system allows you to choose from the locales that the OS or browser supports. That set of locales can be very different from the set of locales supported by a given application. If a user's OS is set for Estonian and my app doesn't support that, how do I know which of the locales I do support would be the best option for the user? What if the OS doesn't support a locale that my application does support, do I just not allow the user to select it? What about the common case where the OS/browser idea of localization is insufficient, such as most not supporting BCP47 language tags, so I can't say I want to read in Cyrillic (sr-Cyrl) or Latin (sr-Latn)? Maybe one day the support will be there that allows this, but right now if you care about it you have to localize it yourself. > > the web browser has to be using the same locale for any native locale >> processing it uses >> > > I’m not sure I follow you here. If an application is used via a web > browser, then according to your words the application normally provides its > own locale selection
Re: [whatwg] Decimal comma in numeric input
John Tamplin wrote: The entire web application, which includes both client and server-side code, must have the same idea about what locale the user is using. Well, HTML(5) is not just about client-server applications. It’s also about offline applications and about the bulk of web and intranet content that cannot be characterized as “applications” in any significant meaning. Moreover, part of the very idea of client-server model is that the client can handle user interaction in the user’s preferred locale and generally the way that suits the user, whereas the server-side processing and storage can use globalized format of data. The server can remain totally ignorant of the user interaction; it just gets and send data in a global well-defined format, which may be almost or completely unreadable to humans, or at least odd-looking to most, like ISO 8601 date and time, language codes, or real numbers in binary format. New input types like "color", "date", and "number" are interesting steps towards allowing localized user interfaces with strictly defined and controlled interfaces to server-side and client-side processing of data. But they are perhaps not quite _conscious_ steps, and they are relatively limited, and they are (probably intentionally) silent about most localization issues. If the app provides a drop-down box or preference setting to choose a different locale, as most localized apps do, Do they? Is that a good move, as opposite to using one centralized set of settings in the user's system? How many times am I actually supposed to tell my preferred language, country, currency, decimal separator, and so on, when using different applications? Localization is far more than choosing a locale from a dropdown, or at least it should be to be genuinely useful. the web browser has to be using the same locale for any native locale processing it uses I’m not sure I follow you here. If an application is used via a web browser, then according to your words the application normally provides its own locale selection. Are you now saying that a web browser should somehow try to access such choices and turn them into its own choices. I was confused, and I am getting more and more confused. Otherwise, you run a serious risk of having incorrect data -- if a user types "10,000" in a field when they think they are using a locale with a comma as the decimal separator, does the app receive that as 1 or 10.000? That was the issue I raised, and I don’t see how it would vanish according to the approach to selecting a locale. If the app is running in en-US because the user requested it or their system locale isn't supported by the app, and the browser sends "10.000" as the value because the system locale is "de", then that is a problem. Independently of the ways in which some software decides to use some locale settings, there is the problem that the user does not what to enter when he needs to enter a number with a decimal part. I think non-localized UIs (e.g., UIs that always use full stop as decimal separator) are definitely better than poorly-localized UIs. Thus, it would be safer to compute the language of the input element, In practical terms, no. We know that authors generally fail to specify the content language or have it mis-specified (typically, as English irrespective of the real language) by authoring software. If you can't rely on getting the locale the app is running in, then apps are not going to be able to use any fancy features and will continue to implement their own localization since they can't rely on the browser getting it right. They can hardly expect browsers to get it right now or in the near future, as there isn’t even any definition for what is right. And there is considerable conceptual confusion too – you seem to imply that the language of the input element is the same as the locale some application is running in. Most forms in HTML documents aren’t part of any “application” with some localization features. It’s just a form, and the page has some language (though usually detectable only by analyzing the content), and it’s used in a browser that has some user interface language (language of menus, error messages etc.) and little localization outside that. The best approximation of what is generally most natural for the user is in the settings of the underlying system. But users can’t and won’t really expect web pages to apply those settings (usually just silently accepted by the user) to, say, their methods of input for decimal numbers. What I’m saying is, I guess, that HTML specifications should _discourage_ browsers from setting up localized methods for numeric input. It's different with calendars for example. When using an English-language page, I’m quite prepared to seeing a calendar with English month names, but I would not be too surprised at seeing Finnish month names (when using a Finnish version of an O
Re: [whatwg] Decimal comma in numeric input
On Thu, Apr 14, 2011 at 7:23 AM, Jukka K. Korpela wrote: > > I think the main problem is triggering the decimal separator mode (or >> the order of numeric day and month for that matter) on the UI locale >> rather than the locale of the page, >> > > Well that's certainly at least _one_ of the problems. And we might ask > whether a browser should use the _system_ settings, as they should probably > be expected to best reflect the user's real preferences. The entire web application, which includes both client and server-side code, must have the same idea about what locale the user is using. If the app provides a drop-down box or preference setting to choose a different locale, as most localized apps do, the web browser has to be using the same locale for any native locale processing it uses. Otherwise, you run a serious risk of having incorrect data -- if a user types "10,000" in a field when they think they are using a locale with a comma as the decimal separator, does the app receive that as 1 or 10.000? If the app is running in en-US because the user requested it or their system locale isn't supported by the app, and the browser sends "10.000" as the value because the system locale is "de", then that is a problem. > Thus, it would be safer to compute the language of the input element, >> > > In practical terms, no. We know that authors generally fail to specify the > content language or have it mis-specified (typically, as English > irrespective of the real language) by authoring software. If you can't rely on getting the locale the app is running in, then apps are not going to be able to use any fancy features and will continue to implement their own localization since they can't rely on the browser getting it right. -- John A. Tamplin Software Engineer (GWT), Google
Re: [whatwg] Decimal comma in numeric input
Henri Sivonen wrote: The the requirements you cite apply to what goes over the wire and appears in the DOM. The browser may provide a comma-base UI for manipulating the value that is stored and transfered using a period. I see... thanks for the clarification. Yes the description is very general and allows user interfaces of many kinds. It does mean that the degradation story in browsers that don't support the numeric form input types is worse for locales that don't use the period as the decimal separator. In general with the new input types, we have the problem that when they are not supported but degrade to , the user would need instructions on data format, e.g. saying that decimal point be used or that a color be specified as #hh - and these would look stupid when they are not needed. But this can probably be handled reasonably using scripts that test for the support first. Or maybe it would be more robust, transitionally, to include the instructions and in markup, with client-side scripting then trying to set the state to, say, "number", and when successful, removing the instructions (or replacing them with some different instructions). On the other hand, would it be useful to _allow_ localization so that a browser _may_ interpret a comma as a decimal separator? No. Having "may" in processing rules is a recipe for non-interoperability. As far as I can see, such operations _are_ allowed by the current formulations. The browser may use various mechanisms for letting the user to specify a number, and this includes permissive processing of written numbers, as long as the browser ultimately generates a valid number (or raises an error). I think the main problem is triggering the decimal separator mode (or the order of numeric day and month for that matter) on the UI locale rather than the locale of the page, Well that's certainly at least _one_ of the problems. And we might ask whether a browser should use the _system_ settings, as they should probably be expected to best reflect the user's real preferences. Thus, it would be safer to compute the language of the input element, In practical terms, no. We know that authors generally fail to specify the content language or have it mis-specified (typically, as English irrespective of the real language) by authoring software. treat the language as a locale Mapping languages to locales is a guessing game, in addition to all the other problems involved. The problems look rather complicated, but at least I now understand the issue better. -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] Decimal comma in numeric input
Dne Thu, 14 Apr 2011 11:40:12 +0200 Henri Sivonen napsal(a): On Thu, 2011-04-14 at 12:05 +0300, Jukka K. Korpela wrote: I was surprised at seeing that the Finnish-language version of Google Chrome 11 beta accepts a number with a comma, such as "4,2", in . It silently converts the comma to a full stop, "4.2". This looked like a useful feature at first sight, as decimal comma is standard in Finnish as in most human languages. But this seems to violate the rules, since is defined as allowing a "valid floating point number" (the definition of which clearly allows FULL STOP as the only decimal separator) only and, moreover, there is prescribed error processing: an error shall be returned, and the value sanitization algorithm shall set the value to the empty string; ref.: http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#number-state So the Google Chrome implementation is in error here, right? No. The the requirements you cite apply to what goes over the wire and appears in the DOM. The browser may provide a comma-base UI for manipulating the value that is stored and transfered using a period. It does mean that the degradation story in browsers that don't support the numeric form input types is worse for locales that don't use the period as the decimal separator. On the other hand, would it be useful to _allow_ localization so that a browser _may_ interpret a comma as a decimal separator? No. Having "may" in processing rules is a recipe for non-interoperability. I am afraid that if the decimal separator (in rendering) doesn't behave the way people expect it to, it will mean web developers will have to deal with clients saying "We wan't to be able to enter a comma." The "dealing" might mean not using at all, which is something we might not want... Ollie
Re: [whatwg] Decimal comma in numeric input
On Thu, 2011-04-14 at 12:05 +0300, Jukka K. Korpela wrote: > I was surprised at seeing that the Finnish-language version of Google Chrome > 11 beta accepts a number with a comma, such as "4,2", in type="number">. It silently converts the comma to a full stop, "4.2". > > This looked like a useful feature at first sight, as decimal comma is > standard in Finnish as in most human languages. But this seems to violate > the rules, since is defined as allowing a "valid > floating point number" (the definition of which clearly allows FULL STOP as > the only decimal separator) only and, moreover, there is prescribed error > processing: an error shall be returned, and the value sanitization algorithm > shall set the value to the empty string; ref.: > http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#number-state > > So the Google Chrome implementation is in error here, right? No. The the requirements you cite apply to what goes over the wire and appears in the DOM. The browser may provide a comma-base UI for manipulating the value that is stored and transfered using a period. It does mean that the degradation story in browsers that don't support the numeric form input types is worse for locales that don't use the period as the decimal separator. > On the other hand, would it be useful to _allow_ localization so that a > browser _may_ interpret a comma as a decimal separator? No. Having "may" in processing rules is a recipe for non-interoperability. > Google Chrome seems to take the localization so far that if I specify > value="4.2", it gets displayed as "4,2", and if I type "5.5" in the field, > it gets automatically converted to "5,5" in the visible rendering - though > in DOM and in the submitted form data, it's "5.5". That seems reasonable when the field is in a comma-enabled mode. > Things get risky, because if the user then enters "1.500" (which corresponds > to the old way of writing one thousand five hundred in digits in Finnish, a > notation still used to some extent and still official in some other > languages) in field, it gets accepted and sent as > "1.500" (one and a half), if the value restrictions allow it - though the > visual rendering is automatically changed to "1,5". I think the main problem is triggering the decimal separator mode (or the order of numeric day and month for that matter) on the UI locale rather than the locale of the page, because a normal user won't know if a page has browser-supplied features or site author-supplied features. It's quite reasonable for a Finnish user to expect a U.S. site to require input using the U.S. conventions when all the surrounding text is in American English. Thus, it would be safer to compute the language of the input element, treat the language as a locale and use that to trigger the comma-enabled mode. Unfortunately, this requires the browser to have an exhaustive list of locales and their decimal separators. Fortunately, relative comprehensive data is available as part of operating systems and as part of liberally-licensed Free Software such as ICU these days. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
[whatwg] Decimal comma in numeric input
I was surprised at seeing that the Finnish-language version of Google Chrome 11 beta accepts a number with a comma, such as "4,2", in type="number">. It silently converts the comma to a full stop, "4.2". This looked like a useful feature at first sight, as decimal comma is standard in Finnish as in most human languages. But this seems to violate the rules, since is defined as allowing a "valid floating point number" (the definition of which clearly allows FULL STOP as the only decimal separator) only and, moreover, there is prescribed error processing: an error shall be returned, and the value sanitization algorithm shall set the value to the empty string; ref.: http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#number-state So the Google Chrome implementation is in error here, right? On the other hand, would it be useful to _allow_ localization so that a browser _may_ interpret a comma as a decimal separator? Perhaps assuming the localization settings of the browser or the underlying system specify comma as decimals separator, or perhaps independently of that. Google Chrome seems to take the localization so far that if I specify value="4.2", it gets displayed as "4,2", and if I type "5.5" in the field, it gets automatically converted to "5,5" in the visible rendering - though in DOM and in the submitted form data, it's "5.5". Things get risky, because if the user then enters "1.500" (which corresponds to the old way of writing one thousand five hundred in digits in Finnish, a notation still used to some extent and still official in some other languages) in field, it gets accepted and sent as "1.500" (one and a half), if the value restrictions allow it - though the visual rendering is automatically changed to "1,5". I guess the big question is: Should localization issues be concerned in the specification of ? If not, the usefulness of the construct is limited, since in many contexts it is unacceptable to require that users input and see numbers in a format that does not correspond to conventions that are normal for their language and culture. -- Yucca, http://www.cs.tut.fi/~jkorpela/
