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)

enhancement

Tracking

()

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)

Attached file HTML Example (deleted) —
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.
Component: DOM: Core & HTML → Layout: Form Controls
OS: Windows 7 → All
Hardware: x86_64 → All
Version: unspecified → Trunk
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." ?
However round algorithm is buggy. 1.1105 already must be 1.111 when rounded
> 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
> 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.
> 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. :(
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?
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.
+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?
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.
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.
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...
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.
Is there any update on this bug? Personally, I feel like the number should not be truncated beyond the step specified.
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
(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
Mike, the link is at the Comment 1
(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.
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)
Blocks: number-input
No longer blocks: 344616
This would be implemented by calling unum_setAttribute(format, UNUM_MIN_SIGNIFICANT_DIGITS, userSpecifiedNumber) in ICUUtils::LocalizeNumber.
Or more likely UNUM_MIN_FRACTION_DIGITS.
Severity: normal → enhancement
Priority: -- → P4
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.
> 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"...
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.
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.
+1
+1
+1
+1
+1 (Definetely)
+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)
+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)
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.
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.
you could try a way like this on your control. onchange="(function(el){el.value=parseFloat(el.value).toFixed(2);})(this)"
a me too dumb comment, i also want to user type="number" for pricing field.
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.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: