Open
Bug 1003896
Opened 11 years ago
Updated 2 years ago
Provide a way to allow <input type=number> to display its number using a fixed number of decimal places (append trailing zeros if necessary)
Categories
(Core :: Layout: Form Controls, enhancement, P4)
Core
Layout: Form Controls
Tracking
()
NEW
People
(Reporter: soapergem, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: dev-doc-needed)
User Story
Even if bug 1005603 is fixed to allow the number format set in the 'value' attribute (or assigned to input.value) to be preserved, trailing zeros will be lost when the input is stepped. This bug is about allowing content authors to specify that they want a fixed number of decimal places to be used when a number is displayed, even when stepping occurs. Currently this would require changes to the specification.
Attachments
(1 file)
(deleted),
text/html
|
Details |
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.
Updated•11 years ago
|
Component: DOM: Core & HTML → Layout: Form Controls
OS: Windows 7 → All
Hardware: x86_64 → All
Version: unspecified → Trunk
Comment 1•11 years ago
|
||
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•11 years ago
|
||
However round algorithm is buggy. 1.1105 already must be 1.111 when rounded
Comment 3•11 years ago
|
||
> 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.
Blocks: 344616
Comment 4•11 years ago
|
||
> 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•11 years ago
|
||
> 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•11 years ago
|
||
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?
Reporter | ||
Comment 7•11 years ago
|
||
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.
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•10 years ago
|
||
+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•10 years ago
|
||
I have just raised this on the whatwg list: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2014-July/297280.html
Whiteboard: 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.
Updated•10 years ago
|
Whiteboard: 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 11•10 years ago
|
||
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•10 years ago
|
||
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•9 years ago
|
||
Is there any update on this bug? Personally, I feel like the number should not be truncated beyond the step specified.
Comment 14•9 years ago
|
||
I confirm this bug based on popularity and because the spec has been changed so now it could be valid.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 15•9 years ago
|
||
(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•9 years ago
|
||
Mike, the link is at the Comment 1
Comment 17•9 years ago
|
||
(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.
Updated•9 years ago
|
User Story: (updated)
Summary: Number Input type forcibly truncates numeric precision → Provide a way to allow <input type=number> to display its number using a fixed number of decimal places (append trailing zeros if necessary)
Updated•9 years ago
|
Comment 19•9 years ago
|
||
This would be implemented by calling
unum_setAttribute(format, UNUM_MIN_SIGNIFICANT_DIGITS, userSpecifiedNumber)
in ICUUtils::LocalizeNumber.
Comment 20•9 years ago
|
||
Or more likely UNUM_MIN_FRACTION_DIGITS.
Updated•9 years ago
|
Severity: normal → enhancement
Priority: -- → P4
Comment 21•9 years ago
|
||
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•9 years ago
|
||
> 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•9 years ago
|
||
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•9 years ago
|
||
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•9 years ago
|
||
+1
Comment 26•9 years ago
|
||
+1
Comment 27•8 years ago
|
||
+1
Comment 28•8 years ago
|
||
+1
Comment 29•8 years ago
|
||
+1 (Definetely)
Comment 30•8 years ago
|
||
+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)
Updated•8 years ago
|
Keywords: dev-doc-needed
Comment 31•7 years ago
|
||
+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•7 years ago
|
||
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•7 years ago
|
||
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•7 years ago
|
||
you could try a way like this on your control.
onchange="(function(el){el.value=parseFloat(el.value).toFixed(2);})(this)"
Comment 35•7 years ago
|
||
a me too dumb comment, i also want to user type="number" for pricing field.
Comment 36•7 years ago
|
||
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.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•