Html – Force decimal point instead of comma in HTML5 number input (client-side)

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.

I remember my CompSci professor saying never to use floats for currency.

The reason for that is how the IEEE specification defines floats in binary format. Basically, it stores sign, fraction and exponent to represent a Float. It's like a scientific notation for binary (something like +1.43*10^2). Because of that, it is impossible to store fractions and decimals in Float exactly.

That's why there is a Decimal format. If you do this:

irb:001:0> "%.47f" % (1.0/10)
=> "0.10000000000000000555111512312578270211815834045" # not "0.1"!

whereas if you just do

irb:002:0> (1.0/10).to_s
=> "0.1" # the interprer rounds the number for you

So if you are dealing with small fractions, like compounding interests, or maybe even geolocation, I would highly recommend Decimal format, since in decimal format 1.0/10 is exactly 0.1.

However, it should be noted that despite being less accurate, floats are processed faster. Here's a benchmark:

require "benchmark" 
require "bigdecimal" 

d = BigDecimal.new(3) 
f = Float(3)

time_decimal = Benchmark.measure{ (1..10000000).each { |i| d * d } } 
time_float = Benchmark.measure{ (1..10000000).each { |i| f * f } }

puts time_decimal 
#=> 6.770960 seconds 
puts time_float 
#=> 0.988070 seconds

Answer

Use float when you don't care about precision too much. For example, some scientific simulations and calculations only need up to 3 or 4 significant digits. This is useful in trading off accuracy for speed. Since they don't need precision as much as speed, they would use float.

Use decimal if you are dealing with numbers that need to be precise and sum up to correct number (like compounding interests and money-related things). Remember: if you need precision, then you should always use decimal.