I have a web application where I\'m specifying an input field to be a number using the HTML5 property type=\"number\".
You could try ...
<input type="text" pattern="[0-9]*" value="123456" />
which will enforce the entry of 0-9 on Firefox 4 on the desktop as well as an iPhone; I don't have Chrome at hand to try it on, but it should do the same.
Here is a whole list of regular expressions that you can plug into the "pattern" attribute of the html input tag: HTML5 Pattern
Here is how I am using a pattern to format the number two decimal points:
<input type="number" pattern="\d+(\.\d{2})?" />
Unfortunately it doesn't seem to work quite right on the iPad.
This is occurring because of the behavior associated with the HTML5 number
input type in Chromium, and you are definitely not the only one that doesn't care for this.
I have worked around this issue in the past by using the text
type. For example, this has worked well (tested just now in Chrome 11.0.696.71):
<input type="text"
placeholder="Enter Text"
name="inputName"
pattern="[0-9]*">
This behavior of the number
type (to me, at least) is definitely a bug, because the HTML5 standard specifies the number
should have the following value when formatted for display:
The algorithm to convert a number to a string, given a number input, is as follows: Return a valid floating point number that represents input.
And the standard defines a "valid floating point" number here, and as far as I can see, including grouping characters is not expected.
I've isolated the issue to the following code down in the guts of WebKit. I've included the line that fixes the issue here as well:
// From LocalizedNumberICU.cpp
String formatLocalizedNumber(double number, unsigned fractionDigits)
{
NumberFormat* formatter = numberFormatter();
if (!formatter)
return String();
UnicodeString result;
formatter->setMaximumFractionDigits(clampToInteger(fractionDigits));
formatter->setGroupingUsed(FALSE); // added this line to fix the problem
formatter->format(number, result);
return String(result.getBuffer(), result.length());
}
I'm on vacation next week, but plan on submitting this patch to the WebKit team when I return. Once they (hopefully) accept the patch, Chromium should pull it in as part of its normal refresh process.
You can see the original code here, the patched revision here, and the diff of the original file and the patched file here. The final patch was created by Shinya Kawanaka.
Refer to my answer for this similar question.
I believe using <input type="tel" />
is most logical for avoiding this pitfall currently. The other options are intriguing and slightly new to me (like the pattern
attribute) but I found them to be unsatisfactory for my design. You can look at a screenshot of a mobile application I complete for Hilton not too long ago here (it's actually shown in the answer I first referenced).
Number is one of the new HTML5 input types. There are loads of these - email, date, time, url, etc. However, I think only Chrome has implemented them so far. The others fall back to using the default type (text).
For more info about HTML5 input types: http://diveintohtml5.ep.io/forms.html
If you want to disable it on Chrome, you could leave as text and change it to number if the user device is a handheld. Since it's not a usability killer if the user device sniffing gives the wrong result, you shouldn't have any problems.
Why would you want to disable localized formatting? If you want a different format, just change the localization settings of your PC. Why would a user not be interested to show a number in his or her local format? This is definitely not a bug in Chrome but a feature!
It seems to me you are not really using a "number" as input but rather a "text" code with a pattern. See the other posts for suggestions to that.