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.
Update
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.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…