[whatwg] Decimal comma in numeric input

[Ian Hickson]

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 <input 
> 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 <input type="number"> 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 <input type="number"> 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 <input type=number> 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 <input type="text">, the user would 
> need instructions on data format, e.g. saying that decimal point be used 
> or that a color be specified as #hhhhhh - 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 <input 
> 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 10000 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 <output> in HTML.

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