Dne Thu, 14 Apr 2011 11:40:12 +0200 Henri Sivonen <hsivo...@iki.fi>
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 <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. 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 <input type="number"> at all, which is something we
might not want...
Ollie
