ChatGPT解决这个技术问题 Extra ChatGPT

Chrome auto formats input=number

I have a web application where I'm specifying an input field to be a number using the HTML5 property type="number".

<input type="number" value="123456" />

By specifying the type, Chrome automatically formats the value to include a comma (123,456). In other browsers it does not format the number, but it also does not prevent non-numeric characters.

In this case, I don't want the comma to be added. Is there any way to turn off localized formatting?

I know I can leave the type as text and using JS to enforce the types of characters. However, I'm using this in a mobile app and want the keyboard to default to the number keyboard layout.
What version of Chrome are you seeing this comma? I don't see it on my version.
@Donvan: i using crome too but comma is not included? i don't see it in my version too.
I am seeing the comma in 11.0.696.25 beta
Just make sure not to use chrome as your mobile browser =P

a
arcain

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.


Works, but not the ideal solution as you lose the up/down arrows. Still the best method I've found so far though.
@njak32 Agreed. Having to avoid number in Chrome is a pain; hoping the issue is fixed quickly.
I've produced a fix that corrects this problem in Chromium, but the actual issue is in the WebKit code. I'll submit it to the WebKit project when I return from vacation on 6/13.
Webkit bug 62939 entered by Patrick! Thanks!
+1 for not only answering the question, but then taking the time to actually fix the software that's causing the bug!
E
Evan Carroll

There are a couple of extra properties that you can check including valueAsNumber.

Chrome attempts to provide you with the best input method possible based on the input type. In this case, number also has some extra abilities such as toggle up and down.

The point of this, is if the number isn't valid, you will be able to detect that there are errors and also set the styling input[type=number]:invalid { background-color: red; }


I appreciate this answer was written 2.5 years ago but wanted to share my experience that I have just tested this in Chrome 31.0.1650.63 and the valueAsNumber property is not necessary and can be omitted.
g
gdt

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.


It does the same thing. Commas, commas, commas.
@DonovanWoodside: It doesn't add commas on IOS.
D
DanBeale

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.


I'd prefer that the browser somehow allow me to control how it formats the number via the HTML instead of requiring the user to disable it. I want a numeric field but without formatting so that both desktop and mobile devices can have the same experience. As is, the mobile devices I'm testing with handles it well by defaulting to the appropriate keyboard layout. Chrome (dev channel) on the desktop tweaks the UI in the manner I originally posted about.
@Donovan What about using JavaScript and cancelling keypress events for anything other than numbers? Alternatively, allow them to be pressed but display an error next to the input box.
I already have a script wired up which only allows numbers, but the main reason I have the input set to type="number" is so that the mobile (iPad/iPhone/etc) keyboard defaults to one with numbers. That way the user doesn't have to tap the number layout button. It's just a matter of convenience.
C
Community

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).


M
Michael Schmidt

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.


t
tiriana

Try this:

if (navigator.userAgent.toLowerCase().indexOf("chrome") >= 0) {
    $('[type=number]').attr('type', 'text').attr('pattern', '[0-9]*');
}

A
Aristoteles

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.


There are many reasons. For example a 4 digit year field (e.g. 2013) becomes 2,013 when the input type is number! Where is the logic in that?
If it remained local, fewer people would complain. Besides for the obvious mis-formatting of years, zip codes, credit cards, you're still dealing with these commas being sent to the server! It is not local
@LDJ you should not use type=number for year, we have <input type=year> for that