Chrome auto formats input=number

Question

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?

Forego

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. – Forego

What version of Chrome are you seeing this comma? I don't see it on my version. – Freshwater

@Donvan: i using crome too but comma is not included? i don't see it in my version too. – Seljuk

I am seeing the comma in 11.0.696.25 beta – Endostosis

Just make sure not to use chrome as your mobile browser =P – Quetzal

It seems to be a bug in Chrome - code.google.com/p/chromium/issues/detail?id=78520 – Unspoiled

My version of Chrome (11.0.696.71) strips leading zeros, inserts commas and doesn't allow letters in the field. I don't want any of those behaviours. I just want mobile devices to use the appropriate keyboard. This overhelpfulness is just a nuisance. All those behaviours should be something I have to turn on - at least give me a way to turn them off without doing browser detection! – Careless

Safari is doing the same thing in mobile safari. Annoying for zip code fields. – Minta

Answer 1

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.

Misstate

Works, but not the ideal solution as you lose the up/down arrows. Still the best method I've found so far though. – Palatal

@njak32 Agreed. Having to avoid number in Chrome is a pain; hoping the issue is fixed quickly. – Misstate

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. – Misstate

Webkit bug 62939 entered by Patrick! Thanks! – Misstate

This solution is exactly what I needed for making a number input field work like I wanted it to on the Ipad. Thanks! – Mossy

+1 for not only answering the question, but then taking the time to actually fix the software that's causing the bug! – Monti

I just checked Chrome 20.0.1132.11 beta-m and it is no longer exhibiting this behavior. As per the comments on the WebKit defect, on Mar 11, 2012 it was stated that "this bug was fixed for platforms using LocalizedNumberICU such as Chromium. We still have the problem with platforms using LocalizedNumberMac (OS X and iOS)." So, at least some progress in the right direction. – Misstate

WebKit defect 93236 was just opened to address this on Apple platforms. – Misstate

Looks like defect 93236 was fixed on Aug 7, and that closed the final issue with defect 62939. So, that should be it for this issue. – Misstate

I'm printing "10,30" from Culture "nl-BE". My en-GB chrome turns this into an EMPTY field (value still 10,30 but you can't see it), it accepts it, but posts it as 10.30, FUN stuff, totally not confusing – Teaching

A number pattern should also allow the input of "e","E","+","-" like in 1e-8 – Chantellechanter

Answer 2

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; }

Sikorsky

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. – Defeatist

Answer 3

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.

Unspoiled

It does the same thing. Commas, commas, commas. – Forego

@DonovanWoodside: It doesn't add commas on IOS. – Thrombocyte

Answer 4

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.

Fasta

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. – Forego

@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. – Fasta

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. – Forego

Answer 5

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

Gladi

Answer 6

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.

Refute

Answer 7

Try this:

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

Iluminadailwain

Answer 8

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.

Wolfgang

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? – Karlenekarlens

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 – Skelly

@Karlenekarlens you should not use type=number for year, we have <input type=year> for that – Beedon