1003896 - Provide a way to allow <input type=number> to display its number using a fixed number of decimal places (append trailing zeros if necessary)

Status: NEW

(Core :: Layout: Form Controls, enhancement, P4)

Description

[Gordon Edmands Myers]

Attachment: HTML Example

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.131 Safari/537.36

Steps to reproduce:

I've got an <input type="number"> for entering dollar amounts. The "step" attribute is set to 0.01, and the "min" attribute is set to 0.00. For the most part it behaves normally, with one big exception: it doesn't preserve the 2-digit precision at all! It keeps rounding the numbers and only displaying those values.


Actual results:

In my (attached) HTML example, I've set the value of it to 42.00 and it does not display correctly; instead it simply shows 42 without any decimal precision. Or if I change it to something like 13.50 this also does not work right; instead it shows 13.5


Expected results:

If I've explicitly given the number field a value with decimal precision, and that number is valid within the specified range, it should leave the formatting alone to whatever I've specified, and not forcibly remove it. Right now there seems to be no recourse for changing the formatting (trying to set the field's value to "42.00" in JavaScript doesn't work either). This is clearly not desirable behavior.

Comment 1

[Robert Utasi [:hunboy]]

http://www.w3.org/TR/html5/forms.html#number-state-%28type=number%29

"If the user agent provides a user interface for selecting a number, then the value must be set to the best representation of the number representing the user's selection as a floating-point number."

?

Comment 2

[Robert Utasi [:hunboy]]

However round algorithm is buggy. 1.1105 already must be 1.111 when rounded

Comment 3

[Boris Zbarsky [:bzbarsky]]

> However round algorithm is buggy. 1.1105 already must be 1.111 when rounded

That depends on whether you want to do elementary-school rounding or rounding that reduces the errors introduced.  See http://en.wikipedia.org/wiki/Rounding#Round_half_to_even which is typically the default floating point rounding mode.

Comment 4

[Robert Utasi [:hunboy]]

> That depends on whether you want to do elementary-school rounding or
> rounding that reduces the errors introduced.  See
> http://en.wikipedia.org/wiki/Rounding#Round_half_to_even which is typically
> the default floating point rounding mode.

And what about financial and tax rules? Those say 5 or above must be ceil, less than 5 is floor.

Comment 5

[Boris Zbarsky [:bzbarsky]]

> Those say 5 or above must be ceil

Tax rules use elementary-school rounding, yes, because they care about people easily following the directions more than they do about the statistical distribution of tax payments. ;)

Financial rules vary.  Some of them (e.g. currency conversions) seem to use rounding up.  Others require the ties-to-even algorithm (which is called "Banker's Rounding" for a reason).

All of which is to say, if you're relying on one particular rounding mode to fit all use cases you will be disappointed.  :(

Comment 6

[Jonathan Watt [:jwatt]]

Taking a look at Chrome, they do seem to preserve the fractional digits when the page first loads, but if the value is incremented and then decremented the text displayed is "42" not the original "42.00". Same if you increment from 42.09 (you get 42.1 not 42.10). Etc.

ICU does provide us with a mechanism to control the number of significant fractional digits (using UNUM_FRACTION_DIGITS similar to the way that UNUM_MAX_FRACTION_DIGITS is used in the patch for bug 1004327). But the question is how would we tell when we should do that. I think that should really be discussed on the whatwg list. Gordon, can you bring up the issue there?

Comment 7

[Gordon Edmands Myers]

Jonathan, I must apologize but I am unfamiliar with the "whatwg" list. I would be happy to submit this bug report wherever is best suited but you'll have to give me a little more than just the name if you'd prefer it be submitted there (wherever that is!).

I think Chrome got it right with their implementation of this. They preserve the fractional component not only on page load but also if you change the value explicitly with JavaScript. That's what I would expect should happen. Losing the precision when you use the spinner is fine IMO, although that could be a separate discussion I suppose. Personally I'm less concerned with the spinner behavior and more concerned with the current inability to set the value to anything that looks like a dollar amount.

Comment 8

[Alex Bell]

Agree with Jonathan that this seems like a spec bug. There are a wide variety of use cases (currency the most obvious) in which an author would want to be able to specify a fixed number of decimal places. A user seeing "$5.1" is just bad UX. It's disorienting, and defeats some of the point of moving these validations out of javascript into native. One solution would be the addition of a "decimals" attribute to type number, with proper allowances for internationalization. "decimals" would accept any non-negative integer. When "decimals" was supplied, the spinner would increment/decrement the smallest decimal place by one, with no rounding. The toString() style rounding would only occur when the attribute was absent/empty/invalid.

Comment 9

[Mike Gratton]

+1. This is problematic for a business management webapp I maintain for a client - the company requires certain fields to be presented with specific numeric decimal precision, currency being the obvious example - it is unacceptable for them that a currency amount of $0 to be presented as "0" instead of "0.00". This behaviour is currently preventing them from upgrading to FF 29/30.

Surely if the step attribute is specified, and that is being used to determine the precision of numbers that users must enter for validation purposes, then it should also be used for determining display precision?

Comment 10

[Mike Gratton]

I have just raised this on the whatwg list: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2014-July/297280.html

Comment 11

[Rémy DANIEL]

Hi, is there any progress on this issue?
The <input type="number" /> fails on all the use cases where users need to read and enter a currency...

Comment 12

[Boris Zbarsky [:bzbarsky]]

The problem is really that currency us not really "a number" in the sense that you can just put in a number in the usual way and have it look right.  It's a string that happens to look sort of like a number in some, but not all, cases.  The pre-1971 British currency, for example, makes this abundantly clear.

Comment 13

[Dario Martins Silva]

Is there any update on this bug? Personally, I feel like the number should not be truncated beyond the step specified.

Comment 14

[Robert Utasi [:hunboy]]

I confirm this bug based on popularity and because the spec has been changed so now it could be valid.

Comment 15

[Mike Gratton]

(In reply to Robert Utasi [:hunboy] from comment #14)
> I confirm this bug based on popularity and because the spec has been changed
> so now it could be valid.

Do you have a link to the spec change?

When I raised the issue on the WhatWG list no one seemed interested in fixing it. The one response pointed out that use cases like currency and other fixed precision values require a decimal number datatype, not floating point number: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2015-January/298178.html

Comment 16

[Robert Utasi [:hunboy]]

Mike, the link is at the Comment 1

Comment 17

[Mike Gratton]

(In reply to Robert Utasi [:hunboy] from comment #16)
> Mike, the link is at the Comment 1

Yes, note it still says "floating point number" throughout, not "decimal number". So this bug is actually invalid, because Gecko is doing the correct thing per the spec.

If we want to get support for decimal numbers, we should be filing an enhancement request for <INPUT TYPE=DECIMAL> or similar.

Comment 19

[Jonathan Watt [:jwatt]]

This would be implemented by calling

  unum_setAttribute(format, UNUM_MIN_SIGNIFICANT_DIGITS, userSpecifiedNumber)

in ICUUtils::LocalizeNumber.

Comment 20

[Jonathan Watt [:jwatt]]

Or more likely UNUM_MIN_FRACTION_DIGITS.

Comment 21

[Kevin Benton]

In this case, I'm forced to decide whether or not I should use input type="number" or go back to input type=text because my wife uses Firefox to enter financial data in her business tracking website. She can't enter amounts like 11.15 because Firefox won't let her input floating-point numbers. She can only input whole numbers. If she uses her iPhone, she can input the data without an issue when using input type=number. I hate to have to go back to input type=text, but I don't see another option today. Please make this a priority.

Comment 22

[Boris Zbarsky [:bzbarsky]]

> She can only input whole numbers.

That's something you can solve easily by setting step to 0.01.  It's not directly related to this bug, except for the fact that "11.10" will look like "11.1"...

Comment 23

[Joe Theuerkauf]

Firefox is the only major browser at this point that doesn't support manually setting value with trailing zeros. MS Edge and Chrome both allow setting a Number.toFixed(#) string as the input value, and will preserve the trailing zeros for display.

If a feature isn't added to support fixed display formats, at LEAST make the input align with other implementations.

Comment 24

[Joe Theuerkauf]

PS: Display value doesn't even match input value when there are trailing zeros.

<input type="number" value="10.00" step="0.01"> displays 10

This inconsistency reinforces the need to correct the problem.

Comment 25

[chad.callahan]

+1

Comment 26

[john.robinson]

+1

Comment 27

[ultimateanu]

+1

Comment 28

[gcugamoylan]

+1

Comment 29

[rogue.thiago]

+1 (Definetely)

Comment 30

[Karan Sharma]

+1 (Affected) 

I have been fixing IE issues and suddenly noticed this one in FireFox. Isn't it feels odd that IE, Chrome are working fine with same and Firefox adding exceptional formatting. 

ie 10.00 !== 10

Error is quite famous,Seems like firefox is running around with this. Better provide us some attribute to override this formatting. I know step can be adjusted to 0.01 to make the float working. But still additional formatting is an issue. 

Examples to text for output comparison :
 
<input type="number" value="10.00" step="0.01" />
<input type="number" value="10.00" step="0.10" />
<input type="number" value="10.00" step="1.00" lang="en" />

Firefox Version : 53.0 (64bit)

Comment 31

[Les Posner]

+1 (Affected)

I'm writing a pricing module where I want to use type="number" step="0.01" for pricing fields and require said fields to display values with an accuracy of 2 digits after the decimal point.

As stated above, Chrome & IE/Edge achieve this.

Any news on when FF will also?

Firefox version: 54.0.1 (64 bit)

Comment 32

[danny]

Similar to the user above I'm also using number for pricing fields as that's the most suitable type. Every other browser I've tested at least allows you to display the trailing zeros by providing the value as a string, Firefox is the exception, so this should be fixed at least to allow that functionality.

Comment 33

[Ricardoamercado]

I am only having this issue on firefox, it works as expected on chrome.

If I have a number input with a value of "20.00" or 20.00 (as a string or number) it always shows 20 without the decimal spaces inside the input box.

I need the type="number" so avoid other inputs that aren't numbers because of internal calculations that are done after the input.

For example:

https://jsfiddle.net/fys1c1am/

How can I have the value inside the input show with the 2 decimal values?

As far as I have read around the web, there is no solution to this issue and it is probably an issue to be solved internally by the mozilla firefox dev team.

Comment 34

[djd0815]

you could try a way like this on your control.

 onchange="(function(el){el.value=parseFloat(el.value).toFixed(2);})(this)"

Comment 35

[Guillaume .J]

a me too dumb comment, i also want to user type="number" for pricing field.

Comment 36

[carlosbvz]

Hey Guys, 
Any update on this one?

Funny thing is that even if I force it with js to 1.00 (for example) it still will round it to 1.