Last Comment Bug 344616 - Implement <input type="number">
: Implement <input type="number">
Status: RESOLVED FIXED
: dev-doc-needed, feature, html5
Product: Core
Classification: Components
Component: DOM: Core & HTML (show other bugs)
: Trunk
: All All
: -- normal with 79 votes (vote)
: mozilla29
Assigned To: Jonathan Watt [:jwatt] (back in October - email directly if necessary)
: Petruta Rasa [QA] [:petruta] (PTO: 26th Sep - 7th Oct)
:
Mentors:
http://www.whatwg.org/specs/web-forms...
Depends on: 926412 1012818 1191519 1210595 345624 534785 549475 556009 559761 635240 635281 635498 635499 635553 635554 636627 636634 636737 638143 665528 665884 679220 765772 771492 771559 771561 912511 915758 917386 926419 927435 930010 935501 935506 935508 935544 935549 939635 940006 940696 940760 940764 941367 943047 945784 946184 946390 946398 947728 947740 948433 948475 948549 949117 949134 949891 951310 966861 967429 970257 1003741 1004130 1004327 1010158 1010184 1012976 1033400
Blocks: html5forms html5test 945309 ringmark-ring1 791653 982189
  Show dependency treegraph
 
Reported: 2006-07-13 17:26 PDT by Alex Vincent [:WeirdAl]
Modified: 2016-05-15 23:49 PDT (History)
95 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Patch - WIP (content part) (38.94 KB, patch)
2010-06-09 17:24 PDT, Mounir Lamouri (:mounir)
no flags Details | Diff | Splinter Review
Patch - WIP (content part) (33.22 KB, patch)
2010-10-13 05:43 PDT, Mounir Lamouri (:mounir)
no flags Details | Diff | Splinter Review

Description Alex Vincent [:WeirdAl] 2006-07-13 17:26:51 PDT
I'm willing to take a shot at implementing <input type="number"> as described in
Web Forms 2.0.
Comment 1 d 2010-04-26 12:20:08 PDT
I think http://docs.google.com/View?id=dch3zh37_0cf8kc8c4 includes what we want to do in UI-way too (although I can't really see why a button is only present on Windows, I suppose it's for the list attribute, but why not on the other OS's?). The arrow-buttons adjust the value depending on the "step" attribute.

Without having looked at the spec, I also suppose we either prevent the user from entering anything other than numbers, or flag anything other than numbers as an input, as invalid?
Comment 2 Mounir Lamouri (:mounir) 2010-04-26 12:48:38 PDT
I will keep the style used for the XUL number element (Preferences -> Advanced -> Network).
The text field will filter non-numeric values as asked by the specifications: the value in <input type='number'> has to be a number and the UA should not let the user setting something else.
Comment 3 Mounir Lamouri (:mounir) 2010-04-29 10:04:33 PDT
I will need bug 534785 for the value owning. It would be better so I will not re-create the mess we already have.
Comment 4 Mounir Lamouri (:mounir) 2010-06-09 17:24:26 PDT
Created attachment 450253 [details] [diff] [review]
Patch - WIP (content part)

This is still WIP. Everything related to constraint validation is missing.
Comment 5 Nathan 2010-07-16 14:46:26 PDT
It works great in Chrome. 
Any chance it can be implemented before Firefox 4?
Or actually, will it even be implemented in Firefox 4 at all?
http://stackoverflow.com/questions/3269004/html-5-input-type-number-in-firefox
Comment 6 Mounir Lamouri (:mounir) 2010-07-16 18:39:54 PDT
Unfortunately, <input type='number'> isn't one of the top HTML5 Forms priorities for Firefox 4. If time permits, it will be implemented but keep in mind that's not a top priority so don't expect to see it in Firefox 4. This said, with no doubt, it will be done at least for the release right after Firefox 4.
Comment 7 Michael Newton 2010-09-07 10:52:38 PDT
Is this still looking like it won't make the 4.0 release? It would be great to have a basic implementation that checks if the content is numeric, with the more complex features like @step and its UI in a point release.

For us, @type=number is second only to @type=date on the wishlist!
Comment 8 Mounir Lamouri (:mounir) 2010-09-24 19:13:23 PDT
Unfortunately, this is not going to be in Firefox 4.0.
This will probably be implemented for the following release.
Comment 9 Mounir Lamouri (:mounir) 2010-10-13 05:43:52 PDT
Created attachment 482834 [details] [diff] [review]
Patch - WIP (content part)
Comment 10 Mounir Lamouri (:mounir) 2011-02-25 08:43:22 PST
Comment on attachment 482834 [details] [diff] [review]
Patch - WIP (content part)

Marking this patch obsolete: all bits of this patches have been moved to patches in blocking bugs.
Comment 11 Ole Dormann 2011-03-20 07:18:28 PDT
Hi Mounir, 

You are doing a really good job implementing form elements and attributes, but I have one question for you and others who are implementing this feature..

If number is a float or double and you can type in fx, 3.14 how can I limit it only to integers? should'nt their be a attribute or something for this behavior or i'm I missing something in the standard?

I know you can limit it by Javascript, but now when you are in the middle of implementing it, I just wanted to point it out.

Maybe you have already thought of it, if not, you are thinking of it now :o)

/Ole
Comment 12 Mounir Lamouri (:mounir) 2011-03-20 16:43:29 PDT
(In reply to comment #11)
> If number is a float or double and you can type in fx, 3.14 how can I limit it
> only to integers? should'nt their be a attribute or something for this behavior
> or i'm I missing something in the standard?

By default <input type='number'> should only accept numbers. You can use the step attribute to define which values are accepted. By default step=1. If you set <input type='number' step='0.01'>, 3.14 would be a valid value, as 3 but not 3.141.
If <input type='number'> has an invalid value, the form wouldn't be submittable. It's up to the browser UI to make impossible to the user to set an invalid value.
Comment 13 Mounir Lamouri (:mounir) 2011-03-20 16:44:08 PDT
(In reply to comment #12)
> By default <input type='number'> should only accept *numbers*.

I meant 'integers'.
Comment 14 Ole Dormann 2011-03-21 09:07:00 PDT
That sounds reasonable, thank you...

what about localization? 

US: <input type='number' step='0.01'> 3.14 is valid, 3,14 is not valid
Europe: <input type='number' step='0.01'> 3,14 is valid, 3.14 is not valid

I guess the browser UI will handle that too?
Comment 15 Daniel Glazman (:glazou) 2011-03-21 09:22:14 PDT
(In reply to comment #14)
> That sounds reasonable, thank you...
> 
> what about localization? 
> 
> US: <input type='number' step='0.01'> 3.14 is valid, 3,14 is not valid
> Europe: <input type='number' step='0.01'> 3,14 is valid, 3.14 is not valid
> 
> I guess the browser UI will handle that too?

Good catch. Let me give an example here: on mac, the french keyboard's decimal
separator creates a "," and not a "." because the normal decimal separator in
french is a comma... You just cannot expect french users are going to use the
period as a decimal separator. The field must be localized, or at least accept
the en-US *and* the localized version of the number.
Comment 16 Ole Dormann 2011-03-21 09:59:08 PDT
since many websites do not use the language of the browser to localize the page, the best solution would be one of the following: 

1. 
extract it from the step attribute
US: <input type='number' step='0.01'>
FRENCH: <input type='number' step='0,01'>

2. 
new attribute: decimal-separator
US: <input type='number' step='0.01' decimal-separator=".">
FRENCH: <input type='number' step='0.01' decimal-separator=",">

3. 
new attribute: format
US: <input type='number' step='0.01' format="#.##">
FRENCH: <input type='number' step='0.01' format="#,##">

I think solution 3 is the most flexible one, since the "output" element would require the same behavior and with the "output" element you properly also want to take the thousand-separator into account, like:
US: format="#,###.##"
FRENCH: format="#.###,##"
Comment 17 Mounir Lamouri (:mounir) 2011-03-21 11:26:10 PDT
(In reply to comment #14)
> That sounds reasonable, thank you...
> 
> what about localization? 
> 
> US: <input type='number' step='0.01'> 3.14 is valid, 3,14 is not valid
> Europe: <input type='number' step='0.01'> 3,14 is valid, 3.14 is not valid
> 
> I guess the browser UI will handle that too?

Yes. I was thinking of using the decimal separator that corresponds to the browser UI. IOW, if you are using Firefox in english, the decimal separator would be '.' and if you use it in french, it would be ','.
I do not think it makes sens to let the authors specify the decimal separator. At least, not for the moment.
Comment 18 Ole Dormann 2011-03-21 12:15:30 PDT
I would characterize the browser UI solution as a default behavior, but okay for now. In a future version, it would be nice to be able to overwrite these values.

Thank you all for your comments and feedback...
Comment 19 Olli Pettay [:smaug] (reviewing overload) 2011-03-21 12:32:48 PDT
(In reply to comment #17)
> Yes. I was thinking of using the decimal separator that corresponds to the
> browser UI. IOW, if you are using Firefox in english, the decimal separator
> would be '.' and if you use it in french, it would be ','.
> I do not think it makes sens to let the authors specify the decimal separator.
> At least, not for the moment.
Actually, page author should be able to define the separator.
I use always English FF, but on Finnish page I may *have to* use , not .
Comment 20 :Ehsan Akhgari 2011-03-21 14:56:43 PDT
(In reply to comment #19)
> (In reply to comment #17)
> > Yes. I was thinking of using the decimal separator that corresponds to the
> > browser UI. IOW, if you are using Firefox in english, the decimal separator
> > would be '.' and if you use it in french, it would be ','.
> > I do not think it makes sens to let the authors specify the decimal separator.
> > At least, not for the moment.
> Actually, page author should be able to define the separator.
> I use always English FF, but on Finnish page I may *have to* use , not .

And we have the @lang attribute for exactly that kind of situation.  :-)
Comment 21 Michael Newton 2011-03-21 15:13:34 PDT
Just to make it clear, the spec defines the only valid separator as U+002E FULL STOP (.) so any other behaviour may not be repeated in other browsers.

http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#rules-for-parsing-floating-point-number-values

May be worth trying to get the spec updated, but I can imagine reluctance; seems like the sort of thing that could consume a lot of time and resources.
Comment 22 Ole Dormann 2011-03-21 15:47:31 PDT
(In reply to comment #21)
> Just to make it clear, the spec defines the only valid separator as U+002E FULL
> STOP (.) so any other behaviour may not be repeated in other browsers.
> 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#rules-for-parsing-floating-point-number-values
> 
> May be worth trying to get the spec updated, but I can imagine reluctance;
> seems like the sort of thing that could consume a lot of time and resources.

Yes, but thats not right, since (.) only accounts for relatively small number of Internet users - I think (,) is more widely used. So if it is not chanced now, it would/should be in the future :-)
Comment 23 :Ms2ger (⌚ UTC+1/+2) 2011-03-22 05:58:39 PDT
(In reply to comment #19)
> Actually, page author should be able to define the separator.
> I use always English FF, but on Finnish page I may *have to* use , not .

Why?

In any case, the internal value and the value that's submitted to the server needs to be consistent across all languages. Anything else will be a constant source of site incompatibility bugs.

If the UI always shows me a comma instead, that's fine. Having it show either a comma or a period based on the page's metadata seems unnecessarily confusing for the user, especially because that metadata is generally not very reliable. Even if it was considered a good idea, I think it would be considerable complexity for a limited gain.

What do the XUL number controls do, by the way?
Comment 24 Olli Pettay [:smaug] (reviewing overload) 2011-03-22 07:04:44 PDT
(In reply to comment #23)
> (In reply to comment #19)
> > Actually, page author should be able to define the separator.
> > I use always English FF, but on Finnish page I may *have to* use , not .
> 
> Why?

Typing '3.14' in Finnish does not mean anything, so it must be '3,14'
Yet on English page I'd expect to be able use valid English
(though, I don't know the exact rules in English. Does 3,14 mean the same
thing as 3.14?)
Comment 25 Emanuel Hoogeveen [:ehoogeveen] 2011-03-22 09:42:02 PDT
In English the period is used as a decimal mark / radix point and the comma is used as a thousands separator. In (most?) other languages it's the other way around.
Comment 26 Ole Dormann 2011-03-22 11:13:44 PDT
(In reply to comment #25)
> In English the period is used as a decimal mark / radix point and the comma is
> used as a thousands separator. In (most?) other languages it's the other way
> around.

Thats not true. Only America uses (.) as decimal separator.
England and Australia use the same notation as the rest of Europe, with the (,)
Comment 27 Ole Dormann 2011-03-22 11:15:53 PDT
And the same goes for the date format:

US: MM-dd-yyyy
GB: dd-MM-yyyy
Comment 28 Ryan Jones 2011-03-22 11:18:39 PDT
(In reply to comment #26)
> (In reply to comment #25)
> > In English the period is used as a decimal mark / radix point and the comma is
> > used as a thousands separator. In (most?) other languages it's the other way
> > around.
> 
> Thats not true. Only America uses (.) as decimal separator.
> England and Australia use the same notation as the rest of Europe, with the (,)

I come from Wales in the UK and everyone around here uses the period (.)
separator for decimal separation.

That is what is currently taught in schools and used in practice that is the
default standard for UK unless they changed it in the last few months and
didn't bother to tell anyone.

I think this would be quite tricky to handle and making the separator variable
would cause complications with form processing systems and such.

Either way this has to be done per the spec so if you want that changed I suggest you take it up with WhatWG.
Comment 29 Ole Dormann 2011-03-22 11:46:30 PDT


(In reply to comment #28)
> (In reply to comment #26)
> > (In reply to comment #25)
> > > In English the period is used as a decimal mark / radix point and the comma is
> > > used as a thousands separator. In (most?) other languages it's the other way
> > > around.
> > 
> > Thats not true. Only America uses (.) as decimal separator.
> > England and Australia use the same notation as the rest of Europe, with the (,)
> 
> I come from Wales in the UK and everyone around here uses the period (.)
> separator for decimal separation.
> 
> That is what is currently taught in schools and used in practice that is the
> default standard for UK unless they changed it in the last few months and
> didn't bother to tell anyone.

Sorry, i've just spoken to my London-family and your right, English uses (.), but the date format is correct...

> I think this would be quite tricky to handle and making the separator variable
> would cause complications with form processing systems and such.

I do not think its tricky to make, if you go with the browser UI solution.

> Either way this has to be done per the spec so if you want that changed I
> suggest you take it up with WhatWG.

Your right, but you have hands on, I don't...
Comment 30 Robert Kaiser 2011-03-22 12:26:50 PDT
IMHO, there should be one single format that is submitted actually, which should preferably be the . as decimal separator as that is what most programming language understand natively.

To the user, the preferred format for the locale of the *website* should be used, though. Note that this is different from his browser's locale.
Comment 31 Emanuel Hoogeveen [:ehoogeveen] 2011-03-22 13:24:00 PDT
(In reply to comment #30)
> To the user, the preferred format for the locale of the *website* should be
> used, though. Note that this is different from his browser's locale.
Won't this just confuse users? What's the advantage from a web designer's perspective?
Comment 32 Ole Dormann 2011-03-22 13:51:33 PDT
(In reply to comment #31)
> (In reply to comment #30)
> > To the user, the preferred format for the locale of the *website* should be
> > used, though. Note that this is different from his browser's locale.
> Won't this just confuse users? What's the advantage from a web designer's
> perspective?

In Facebook you can chance the locale of the page without changing the browser language. If Facebook used the number attribute, 500.000.000 people should know that (.) is the decimal separator, but what if only a couple of people at Facebook knew that they could overwrite the default behavior (.), would'nt that be the best solution?
Comment 33 Ryan Jones 2011-03-22 13:54:13 PDT
I don't think this is helping guys. Mozilla will implement this as the spec stands. I doubt they'd go off and redefine the spec just in case the WhatWG didn't approve of the behaviour changes.

I'd suggest taking this discussion there and keeping the bug for the implementation only.
Comment 34 Ole Dormann 2011-03-22 14:04:27 PDT
(In reply to comment #33)
> I don't think this is helping guys. Mozilla will implement this as the spec
> stands. I doubt they'd go off and redefine the spec just in case the WhatWG
> didn't approve of the behaviour changes.

Sorry Ryan, you should implement it as the spec stands - it was only a suggestion :-)

PS! thank you for Firefox 4, just downloaded it, and it's great! :-) i'm off
Comment 35 Mounir Lamouri (:mounir) 2011-03-23 03:24:25 PDT
(In reply to comment #33)
> I don't think this is helping guys. Mozilla will implement this as the spec
> stands. I doubt they'd go off and redefine the spec just in case the WhatWG
> didn't approve of the behaviour changes.

The specs only specify the submitted format which is going to contain a ".". UA's can do whatever they want for the UI. But yes, we should not argue here. When I will have a patch for these, feel free to discuss about it in the related bug.
Comment 36 Daniel Glazman (:glazou) 2011-03-23 03:40:37 PDT
(In reply to comment #30)

> To the user, the preferred format for the locale of the *website* should be
> used, though. Note that this is different from his browser's locale.

Yeah, because all users know locales and decimal separators...
Come on, this is not reasonable at all... You really expect from an average
european user browsing an american web site to be able to use "." as a decimal
separator ? 

> I don't think this is helping guys. Mozilla will implement this as the spec
> stands. I doubt they'd go off and redefine the spec just in case the WhatWG
> didn't approve of the behaviour changes.

With my W3C WG co-chair hat on, I respectfully disagree. If this bug shows there
is a localization/I18N problem in the spec, this bug will help refine the
spec and resolve the issue. Hence the importance of the discussion here.
Comment 37 Robert Kaiser 2011-03-23 10:13:16 PDT
(In reply to comment #36)
> (In reply to comment #30)
> 
> > To the user, the preferred format for the locale of the *website* should be
> > used, though. Note that this is different from his browser's locale.
> 
> Yeah, because all users know locales and decimal separators...
> Come on, this is not reasonable at all... You really expect from an average
> european user browsing an american web site to be able to use "." as a decimal
> separator ? 

Yes. Take e.g. a site that displays base prices for products, and lets you enter a custom price (say, you're creating your own shop on a T-shirt-printing site). Of course they display their base prices in American format, as the complete site is lang="en-US". If now the input box with the custom price uses a completely different format just because you happen to use a, say, German browser, that's strange and ugly.
Comment 38 Ole Dormann 2011-03-23 11:01:42 PDT
> Yes. Take e.g. a site that displays base prices for products, and lets you
> enter a custom price (say, you're creating your own shop on a T-shirt-printing
> site). Of course they display their base prices in American format, as the
> complete site is lang="en-US". If now the input box with the custom price uses
> a completely different format just because you happen to use a, say, German
> browser, that's strange and ugly.

Which is why you should be able to override the default behaviour... 

What if it was a German shop with a German price-format? As it is now, you whould have to use the American format.
Comment 39 Daniel Glazman (:glazou) 2011-03-23 11:49:30 PDT
(In reply to comment #37)

> Yes. Take e.g. a site that displays base prices for products, and lets you
> enter a custom price (say, you're creating your own shop on a T-shirt-printing
> site). Of course they display their base prices in American format, as the
> complete site is lang="en-US". If now the input box with the custom price uses
> a completely different format just because you happen to use a, say, German
> browser, that's strange and ugly.

And I dispute that entirely. Uglyness is not in question here, it's a question
of usability. Some users will not even understand they have to use another
decimal separator than the one they use for everything, every day.
Comment 40 Danny Moules 2011-04-14 15:27:30 PDT
Excuse me for butting in a little here but this discussion does not seem to be leading to a solution. This is a complex problem. How do you deal with sites that have multiple language attributes, eg. embedded items? How do you handle user overrides and where? What if you actually want multiple cultures on the page?

What are other browsers doing? Why is the specification like that?

In fact, let me suggest an answer for that last one:

Commas already have a defined purpose when defining numbers in the spec. They are used to specify lists of numbers. Are their locale specific rules for dealing with 1.0,2.0,3.0,4.0? There certainly aren't in the spec.

For the most part these are not technical issues. As such I'm not sure they belong on Bugzilla. This bug does not exist for the purpose of incubating ideas for a W3C specification. The bug is not 'come up with an idealised interpretation of input type="number"'. It is a place to discuss the technicalities of implementing a patch to solve a problem. We have a definition for that problem: the specification.
Comment 41 Daniel Glazman (:glazou) 2011-04-14 23:31:19 PDT
(In reply to comment #40)

> For the most part these are not technical issues. As such I'm not sure they
> belong on Bugzilla. This bug does not exist for the purpose of incubating ideas
> for a W3C specification. The bug is not 'come up with an idealised
> interpretation of input type="number"'. It is a place to discuss the
> technicalities of implementing a patch to solve a problem. We have a definition
> for that problem: the specification.

Hilarious. Seriously.

No we have no spec. The HTML spec is now a "live specification"
meaning it can change any time to fix something. And a specification has IMHO
never been and will never be an excuse to implement things that are going to
raise huge problems or that are known to contain severe flaws. Bugzilla bugs
help making the decision: is it something good enough and stable enough Gecko
wants it?
Comment 42 Danny Moules 2011-04-15 10:32:16 PDT
"Bugzilla bugshelp making the decision: is it something good enough and stable enough Gecko
wants it?" 

Exactly. We are discussing whether to implement the spec as it stands now or not. To address "do we implement input type="number" or not".

My point is that if we start doing our own thing, this bug ceases to be "Implement <input type="number">". It becomes something different. It becomes "come up with a better solution in place of implementing <input type="number">" as we understand it now".

If we don't want to implement this, then surely we WONTFIX and start a new bug which actually deals with a hypothetical implementation? Either we implement the spec... or we don't. If we don't, then this isn't the right bug for it. If a spec is so 'live' and 'fluid' we can completely pretend it doesn't exist, it might as well not exist!
Comment 43 Alexander Farkas 2011-05-20 03:43:40 PDT
About the format discussion:

I think you are mixing two different things. The format of value property and the UI for the value.

The newest version of Chrome (12 or 13) has implemented it right. The format of the value send to the server/accessed by script etc. uses always a "." seperator, while the UI accessed by the user is localized. The UI for numbers follows the method 'toLocaleString' (i.e.: (1.1).toLocaleString() ).

There is no spec violation about showing the user a localized format, if the value itself stays consistent and uses a "." as a seperator.
Comment 44 f.a.p.hollebrandse 2011-05-21 15:19:42 PDT
In my reading of the spec, the "value" of the element should be a "valid floating point number", defined as using a "full stop" as a decimal separator. This "value" is simply the "value"-attribute, a string! That means there is no difference between the "value property" and the "display value".

I'm building a web app with the Zend Framework. I sent values to the user in the user's locale (if specified), I also need to rely on the user entering values in this locale. According to the spec, you can't. For example a default value must be set using a full stop, otherwise it's not valid. If Chrome sends me back a value using a full stop, that won't work if I'm validating using the user's locale's conventions.

If browser's are going to handle normalised to localised conversions (on display), and localised to normalised (on submission) that's fine by me. But then this needs to be done for everything, including dates etc. But then I get the problem that I can't support localised display for non html5 browsers. If the spec is not defining how this process should be handled, it would be dangerous to assume one way or the other (client side, versus server side).
Comment 45 f.a.p.hollebrandse 2011-05-22 02:33:58 PDT
(In reply to comment #44)
> In my reading of the spec, the "value" of the element should be a "valid
> floating point number", defined as using a "full stop" as a decimal
> separator. This "value" is simply the "value"-attribute, a string! That
> means there is no difference between the "value property" and the "display
> value".
> 
> I'm building a web app with the Zend Framework. I sent values to the user in
> the user's locale (if specified), I also need to rely on the user entering
> values in this locale. According to the spec, you can't. For example a
> default value must be set using a full stop, otherwise it's not valid. If
> Chrome sends me back a value using a full stop, that won't work if I'm
> validating using the user's locale's conventions.
> 
> If browser's are going to handle normalised to localised conversions (on
> display), and localised to normalised (on submission) that's fine by me. But
> then this needs to be done for everything, including dates etc. But then I
> get the problem that I can't support localised display for non html5
> browsers. If the spec is not defining how this process should be handled, it
> would be dangerous to assume one way or the other (client side, versus
> server side).

I have just been reading the spec on the date input element. What they say there is: 

"The format shown to the user is independent of the format used for form submission. Browsers are encouraged to use user interfaces that present dates and times according to the conventions of the user's preferred locale."

I suppose it would be fairly safe to adopt an equivalent principle for the number input element. Note that this process of normalised<->localised must be applied on a default value level and form submission level.
Comment 46 Ole Dormann 2012-01-15 01:42:04 PST
Hi Mounir,

When do you expect that this bug will be fixed? Maybe for Firefox 13 or 14?
Comment 47 KLB 2012-04-24 06:11:00 PDT
This comment is related to the comma vs. period issue for decimal separators. 

Both commas and periods need to be supported for decimal numbers.  Which one is used should be dependent on the language specified by the webpage (e.g. <HTML lang="en-US">), NOT the OS so that data is in the format expected by the server. 

If it is too difficult to decide whether to allow commas or periods, then both should be allowed.

Failure to allow for periods will make using the input type number a non-starter here in the U.S. because there will be a large population of users who do not even know that commas are the typical decimal separator elsewhere in the world.
Comment 48 Mounir Lamouri (:mounir) 2012-07-05 09:06:06 PDT
A UI-less version of <input type='number'> will be available with the following Nightly behind a preference: "dom.experimental_forms".
If you enable the preference, <input type='number'> will be enabled but will look like a basic text field. This preference might be enabled by default for Android and B2G later. As long as we do not have a UI on desktop, the preference will stay false there.
Comment 49 Nicolas FROIDURE 2012-10-02 01:22:02 PDT
I've got many french users telling me comma should be supported in the Number fields.

You should probably take a look to the way Chrome do it. It displays Number Date inputs in the user language but send it to the server in the en-US format so that received datas doesn't depends on the user language.

I think it's the way how Number inputs must be implemented. I think french users uses French Firefox so it's probably better to implement inputs behavior for the user defined language. It's the common behavior for other browser buttons like submit inputs for which no value attribute is given.
Comment 50 bartosztuszynski 2012-10-02 11:59:53 PDT
Number format for HTTP requests and HTMLInputElement.value: http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#floating-point-numbers

Digits in different cultures: https://en.wikipedia.org/wiki/Numerical_digit

Decimal marks (https://en.wikipedia.org/wiki/Decimal_mark):
1) . (dot) - USA
2) , (comma) - Europe
3) ٫ (Arabic Momayyez) - Arabia
4) / (Persian Momayyez) - Persia

Group separator (https://en.wikipedia.org/wiki/Decimal_mark#Digit_grouping):
1) , (comma) - USA
2)   (space) - Europe (for example 12 345 567,89)
3) ٬ (Arabic Thousands Separator) - Arabia
4) ٫ (Arabic Momayyez) - Persia
5) do not use grouping

Group size in different cultures: three digits
Comment 51 Jean Claveau 2012-10-03 05:00:25 PDT
Shouldn't this bug be related to bugs concerning Number.toLocaleString() (and maybe others)?

For example :
https://bugzilla.mozilla.org/show_bug.cgi?id=545231
https://bugzilla.mozilla.org/show_bug.cgi?id=368838
https://bugzilla.mozilla.org/show_bug.cgi?id=542502
https://bugzilla.mozilla.org/show_bug.cgi?id=769871 (interesting WIP)
https://bugzilla.mozilla.org/show_bug.cgi?id=542502


I was speaking with a friend and giving a look he found something else interesting for webapps devs (in Qt) :
http://doc-snapshot.qt-project.org/5.0/qml-qtquick2-number.html#fromLocaleString-method


Finally, what if we want to display two numbers in two different locals on the same page?
Comment 52 Nicolas FROIDURE 2012-10-03 05:06:21 PDT
Hi Jean,

If it make sense to display Numbers in different locales, i think it should be related to the closer parent element with a lang attribute.

Excluding input elements for wich it has no sense in my opinion.
Comment 53 Simon Charette 2013-01-28 12:51:52 PST
(In reply to Nicolas FROIDURE from comment #52)
> If it make sense to display Numbers in different locales, i think it should
> be related to the closer parent element with a lang attribute.

Ideally number input should have some attributes to specify the decimal mark, group size and separator. Just like date and time inputs should allow a format to be specified.
Comment 54 Nicolas FROIDURE 2013-01-29 00:23:46 PST
I disagree, i think the good format is the user locale format and the browser has its information.

Just a small request for the localization implementation, even if the point is not the decimal separator, please allow its use. Here is the issue i posted for the chromium project :
http://code.google.com/p/chromium/issues/detail?id=163325

Thanks
Comment 55 Simon Charette 2013-01-29 00:39:50 PST
(In reply to Nicolas FROIDURE from comment #54)
> I disagree, i think the good format is the user locale format and the
> browser has its information.

I agree that the DISPLAYED format should be the user locale one, but the format parsing the initial value and the data format sent back to the server should be specified using attributes.

i.e
<input type="number" value="100.000,45" groupsize="3" groupsep="." decmark="," />

Would be rendered as "100000.45" if your user locale's decimal mark is "." and your group separator is an empty string. But would be sent back to the server in the format specified by those attributes.

This would allow browsers not supporting the "number" input to degrade gracefully while defining a format expected by the server.
Comment 56 Nicolas FROIDURE 2013-01-29 01:19:59 PST
It would simplify the transition, but will be useless, or worst, perpertuate bad uses. Servers, i mean, must use the international standard representations.

But anyway, i mean this is not the place to discuss about that. Submit you're proposal to the WhatWG Group instead.

http://www.w3.org/community/whatwg/
Comment 57 Ben 2013-07-01 16:26:51 PDT
It's been almost a year since this landed behind a preference. When will this come out from behind the flag and also get some "spinbox" up/down increment buttons in the UI? FF is starting to look like the straggler here:

http://caniuse.com/input-number

The spec doesn't require a spinbox but it suggests one:

http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#number-state-%28type=number%29

and FWIW Chrome uses a spinbox. If there needs to be a technical discussion on this can it happen now? This isn't just about a UI enhancement, it's about simplifying complex input validation for apps.
Comment 58 Sebas 2013-07-14 08:05:38 PDT
(In reply to Nicolas FROIDURE from comment #56)
> It would simplify the transition, but will be useless, or worst, perpertuate
> bad uses. Servers, i mean, must use the international standard
> representations.
> 
> But anyway, i mean this is not the place to discuss about that. Submit
> you're proposal to the WhatWG Group instead.
> 
> http://www.w3.org/community/whatwg/

Hi there,

I'd like to add my 50cts on the thread: I believe that in an international environment a user should be able to change the visible aspect of the numbers independently from the computer's locals. 

It would be like asking google to show german results while navigating from Canada: it makes sense if the user is german and does not want to reconfigurate his whole computer to show german results.

Don't forget that web forms are more and more intended for cloud "desktop style" apps that very often include an applicative language/country selector, which does not modify the conputer locals. In this context, keeping in mind html5 is a highly applicative specification, having the option within available along with the tag does make sense.

Hope it helped!
Good luck,
S.
Comment 59 Binyamin 2013-11-19 21:47:41 PST
Do not forget to implement checkValidity() for it.
Comment 60 Alvaro 2013-11-23 13:18:16 PST
A couple more cents:

I suggest to look at Chrome's implementation which is very handy (well, I guess this is already being done).

Regarding i18n, it uses an internal format (e.g. 3.14) for the field value (HTML source and DOM value), but renders using the localized decimal separator (e.g. 3,14). Interestingly, it accepts both dot or comma as user input and interprets as decimal separator.

Then it adds spin up/down buttons, handles the up/down arrow keys to increment/decrement, as well as the mouse wheel. All of those use the "step" attribute for increment and the min and max as limits.
Comment 61 Florian Bender 2013-12-03 00:13:43 PST
Jonathan, is it possible to land the pref-on for 28 so it can ride the train to release? Tom's Hardware WBGP (next test is probably with Fx 27 or 28 if we're lucky) depends on HTML5Test, and input[type=number] would allocate quite a few points (because other feature tests depend on it).

If not, and you're finished early in the cycle, can you uplift, please?
Comment 62 Florian Bender 2013-12-05 01:06:44 PST
Pretty much answered by Bug 946398.
Comment 63 Jonathan Watt [:jwatt] (back in October - email directly if necessary) 2013-12-05 04:13:38 PST
(In reply to Florian Bender from comment #61)
> Jonathan, is it possible to land the pref-on for 28 so it can ride the train
> to release? If not, and you're finished early in the cycle, can you uplift,
> please?

I've been trying really hard to make that happen, but there have been a lot of unforeseen complications, seemingly at every turn. It's going to be very tight, so I'm not really sure if this will happen or not.
Comment 64 Markus Popp 2014-02-02 20:08:16 PST
There were quite many fixes for <input type="number"> during the 29.0 Nightly cycle which haven't been uplifted to Aurora. Will that be done as 28.0 goes beta?
Comment 65 Yuriy Chernyshov 2014-02-07 23:10:34 PST
I think you are already informed, but
1) Custom font inside input[type="number"] breaks the display of arrow buttons. Here is the example:
http://leftparagraphs.com/bib/index.html (compare ff27 & ff28).
2) Some validation routines don't work. In Chrome, for example, typing letters in such field would cause :invalid style to be applied. This doesn't happen in firefox.
3) Pattern atribute seems to be disappeared (I didn't have much time to analyze the problem, but this is possibly my code).
Comment 66 Jeroen van der Gun 2014-02-08 03:23:00 PST
(In reply to Yuriy Chernyshov from comment #65)
> 3) Pattern atribute seems to be disappeared (I didn't have much time to
> analyze the problem, but this is possibly my code).

The pattern attribute is invalid on input type number:
> The following content attributes must not be specified and do not apply to the element: accept, alt, checked, dirname, formaction, formenctype, formmethod, formnovalidate, formtarget, height, maxlength, minlength, multiple, pattern, size, src, and width.

http://www.w3.org/TR/html5/forms.html#number-state-%28type=number%29
Comment 67 Yuriy Chernyshov 2014-02-08 03:26:29 PST
Thanks, Jeroen.
I knew that it's quite simple. I just have to rewrite some validation javascript to make it work in both cases (with and without number support).
Comment 68 Yuriy Chernyshov 2014-02-17 10:43:56 PST
Well, right now ff28beta simply crashes on the page I've posted above.
I'm on win7 x64
Comment 69 Jonathan Watt [:jwatt] (back in October - email directly if necessary) 2014-02-17 10:47:17 PST
Working on the crasher in bug 973344.
Comment 70 Jonathan Watt [:jwatt] (back in October - email directly if necessary) 2014-02-19 06:21:16 PST
Let's call this done. There are always further tweaks and improvements that can be made, but the implementation is complete enough to ship this.

If anyone finds any further issues please don't comment here, since there are a lot of CC's on this bug, and most probably only care about the answer to the question "is <input type=number> implemented". Instead, please test in current Nightly ( http://nightly.mozilla.org/ ), file new bugs, CC me, and mark them blocking bug 946398 or bug 945309. Anyone who wants to be aware of any follow-up bugs can CC themself on those bugs.
Comment 71 Mihaela Velimiroviciu (:mihaelav) 2014-03-05 05:39:37 PST
Does this have automation coverage?
Comment 72 Jonathan Watt [:jwatt] (back in October - email directly if necessary) 2014-03-05 06:59:16 PST
Yes, lots of reftests and mochitests were included in the patches for various dependencies and follow-up bugs.
Comment 73 Alan O. 2014-04-04 11:33:41 PDT
This feature most certainly is not implemented.

Firefox 28.0, Windows 7 Pro x64
Comment 74 Jonathan Watt [:jwatt] (back in October - email directly if necessary) 2014-04-04 11:39:55 PDT
The "Target Milestone" field of this bug says "mozilla29". It's not implemented in Firefox 28, but is in 29. Try an Aurora build: https://www.mozilla.org/en-US/firefox/channel/#aurora
Comment 75 Alan O. 2014-04-04 12:30:50 PDT
Please correct the chart included here:

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Input#Browser_compatibility
Comment 76 Jonathan Watt [:jwatt] (back in October - email directly if necessary) 2014-04-04 12:41:39 PDT
Ah, thanks for pointing that out! Fixed.
Comment 77 Alan O. 2014-04-04 12:45:33 PDT
No problem. Good to see this is finally coming about.
Comment 78 Markus Popp 2014-04-04 13:00:45 PDT
(In reply to Jonathan Watt [:jwatt] from comment #76)
> Ah, thanks for pointing that out! Fixed.

You may want to do the same for <input type="color">, same story (not in 28.0, but in 29.0).
Comment 79 Raphael Dzheksenov 2014-05-13 07:59:14 PDT
<input type="number" readonly="readonly"> allow to change value with spin buttons
Comment 80 sea@dcllabs.net 2014-05-15 10:10:54 PDT
In regards to comment #12. All I know is that mozilla browsers have been supporting real numbers in the number field for at least the last 15 years or so.  With no other parameter needed.
Comment 81 Jan Melcher 2014-05-21 04:31:35 PDT
Great to finnaly have this in Firefox, too. One nitpick: the input buttons do not scale with the input's height, so they stay pretty small and hard to click. Is this intended? http://jsfiddle.net/C3Fgn/2/
Comment 82 Jonathan Watt [:jwatt] (back in October - email directly if necessary) 2014-05-21 04:41:25 PDT
Native theming makes that non-trivial to fix. It's covered by bug 947340 and bug 947365.

Note You need to log in before you can comment on or make changes to this bug.