Implement <input type="number">

RESOLVED FIXED in mozilla29

Status

()

Core
DOM: Core & HTML
RESOLVED FIXED
11 years ago
a year ago

People

(Reporter: WeirdAl, Assigned: jwatt)

Tracking

(Depends on: 4 bugs, Blocks: 3 bugs, {dev-doc-needed, feature, html5})

Trunk
mozilla29
dev-doc-needed, feature, html5
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 obsolete attachments)

(Reporter)

Description

11 years ago
I'm willing to take a shot at implementing <input type="number"> as described in
Web Forms 2.0.
(Reporter)

Updated

11 years ago
Depends on: 344618

Updated

11 years ago
Blocks: 344618
No longer depends on: 344618

Updated

9 years ago
Component: DOM: HTML → DOM: Core & HTML
QA Contact: ian → general

Updated

7 years ago
Blocks: 559761
Assignee: ajvincent → mounir.lamouri
Status: NEW → ASSIGNED
OS: Windows XP → All
Hardware: x86 → All

Comment 1

7 years ago
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?
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.
I will need bug 534785 for the value owning. It would be better so I will not re-create the mess we already have.
Depends on: 534785

Updated

7 years ago
Blocks: 566348
Depends on: 345624
Depends on: 549475
Keywords: html5
Created attachment 450253 [details] [diff] [review]
Patch - WIP (content part)

This is still WIP. Everything related to constraint validation is missing.
Keywords: dev-doc-needed

Comment 5

7 years ago
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
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.
No longer blocks: 566348

Comment 7

7 years ago
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!
Unfortunately, this is not going to be in Firefox 4.0.
This will probably be implemented for the following release.
Created attachment 482834 [details] [diff] [review]
Patch - WIP (content part)
Attachment #450253 - Attachment is obsolete: true
Depends on: 635240
Depends on: 635281
Depends on: 635498
Depends on: 635499
Depends on: 635553
Depends on: 635554
Depends on: 556009
Depends on: 636627
Depends on: 636634
Depends on: 636737
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.
Attachment #482834 - Attachment is obsolete: true
Depends on: 638143
Depends on: 638293

Comment 11

6 years ago
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
(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.
(In reply to comment #12)
> By default <input type='number'> should only accept *numbers*.

I meant 'integers'.

Comment 14

6 years ago
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?
(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

6 years ago
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="#.###,##"
(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

6 years ago
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...
(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 .
(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

6 years ago
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

6 years ago
(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 :-)
(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?
(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?)
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

6 years ago
(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

6 years ago
And the same goes for the date format:

US: MM-dd-yyyy
GB: dd-MM-yyyy

Comment 28

6 years ago
(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

6 years ago


(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

6 years ago
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.
(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

6 years ago
(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

6 years ago
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

6 years ago
(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
(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.
(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

6 years ago
(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

6 years ago
> 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.
(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

6 years ago
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.
(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

6 years ago
"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

6 years ago
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

6 years ago
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

6 years ago
(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.
No longer depends on: 638293
Depends on: 665528
Depends on: 665884
Depends on: 679220

Comment 46

6 years ago
Hi Mounir,

When do you expect that this bug will be fixed? Maybe for Firefox 13 or 14?

Comment 47

5 years ago
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.
Blocks: 748250
Depends on: 765772
No longer blocks: 344618
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.
Depends on: 771492
Depends on: 771559
Depends on: 771561

Comment 49

5 years ago
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

5 years ago
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

5 years ago
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

5 years ago
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.
Blocks: 802882

Comment 53

5 years ago
(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

5 years ago
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

5 years ago
(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

5 years ago
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

4 years ago
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

4 years ago
(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.
Assignee: mounir → jwatt

Updated

4 years ago
Depends on: 912511
(Assignee)

Updated

4 years ago
Depends on: 915758
(Assignee)

Updated

4 years ago
Depends on: 917386
(Assignee)

Updated

4 years ago
Depends on: 926412
(Assignee)

Updated

4 years ago
Depends on: 926419
(Assignee)

Updated

4 years ago
Depends on: 927435
(Assignee)

Updated

4 years ago
Depends on: 930010
(Assignee)

Updated

4 years ago
Depends on: 935501
(Assignee)

Updated

4 years ago
Depends on: 935506
(Assignee)

Updated

4 years ago
Depends on: 935508
(Assignee)

Updated

4 years ago
Depends on: 935544
(Assignee)

Updated

4 years ago
Depends on: 935549
(Assignee)

Updated

4 years ago
Depends on: 939248
(Assignee)

Updated

4 years ago
Depends on: 939635
(Assignee)

Updated

4 years ago
Depends on: 940006
(Assignee)

Updated

4 years ago
Depends on: 940696
(Assignee)

Updated

4 years ago
Depends on: 940760
(Assignee)

Updated

4 years ago
Depends on: 940764

Comment 59

4 years ago
Do not forget to implement checkValidity() for it.
(Assignee)

Updated

4 years ago
Depends on: 941367

Comment 60

4 years ago
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.
(Assignee)

Updated

4 years ago
Depends on: 943047
(Assignee)

Updated

4 years ago
Blocks: 945309
(Assignee)

Updated

4 years ago
No longer depends on: 939248

Comment 61

4 years ago
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?
Flags: needinfo?(jwatt)
(Assignee)

Updated

4 years ago
Depends on: 945784

Updated

4 years ago
Depends on: 946184
(Assignee)

Updated

4 years ago
Depends on: 946262
(Assignee)

Updated

4 years ago
Depends on: 946390
(Assignee)

Updated

4 years ago
Depends on: 946398

Comment 62

4 years ago
Pretty much answered by Bug 946398.
Flags: needinfo?(jwatt)
(Assignee)

Comment 63

4 years ago
(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.
(Assignee)

Updated

4 years ago
No longer depends on: 946262
(Assignee)

Updated

4 years ago
Depends on: 947728
(Assignee)

Updated

4 years ago
Depends on: 947740

Updated

4 years ago
Depends on: 949117
(Assignee)

Updated

4 years ago
No longer blocks: 559761
Depends on: 948433, 948549, 559761, 948475, 949134

Updated

4 years ago
Depends on: 951310
(Assignee)

Updated

4 years ago
Depends on: 791653
(Assignee)

Updated

4 years ago
Depends on: 949891
Blocks: 791653
No longer depends on: 791653

Updated

3 years ago
Depends on: 966844

Updated

3 years ago
Depends on: 966861

Comment 64

3 years ago
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

3 years ago
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

3 years ago
(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

3 years ago
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).

Updated

3 years ago
QA Contact: petruta.rasa
(Assignee)

Updated

3 years ago
No longer depends on: 966844

Updated

3 years ago
Keywords: feature

Comment 68

3 years ago
Well, right now ff28beta simply crashes on the page I've posted above.
I'm on win7 x64
(Assignee)

Comment 69

3 years ago
Working on the crasher in bug 973344.
(Assignee)

Comment 70

3 years ago
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Depends on: 967429, 970257
Resolution: --- → FIXED
Target Milestone: --- → mozilla29
Does this have automation coverage?
Flags: needinfo?(jwatt)
(Assignee)

Comment 72

3 years ago
Yes, lots of reftests and mochitests were included in the patches for various dependencies and follow-up bugs.
Flags: needinfo?(jwatt)

Updated

3 years ago
Blocks: 982189

Comment 73

3 years ago
This feature most certainly is not implemented.

Firefox 28.0, Windows 7 Pro x64
(Assignee)

Comment 74

3 years ago
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

3 years ago
Please correct the chart included here:

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Input#Browser_compatibility
(Assignee)

Comment 76

3 years ago
Ah, thanks for pointing that out! Fixed.

Comment 77

3 years ago
No problem. Good to see this is finally coming about.

Comment 78

3 years ago
(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).

Updated

3 years ago
Depends on: 1003741
Depends on: 1004327
Depends on: 1004130
Depends on: 1003896

Comment 79

3 years ago
<input type="number" readonly="readonly"> allow to change value with spin buttons

Updated

3 years ago
Depends on: 1010184

Updated

3 years ago
Depends on: 1010158

Comment 80

3 years ago
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.

Updated

3 years ago
Depends on: 1012818

Updated

3 years ago
Depends on: 1012976

Comment 81

3 years ago
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/
(Assignee)

Comment 82

3 years ago
Native theming makes that non-trivial to fix. It's covered by bug 947340 and bug 947365.

Updated

3 years ago
Depends on: 1033400

Updated

2 years ago
Depends on: 1191519
(Assignee)

Updated

2 years ago
No longer depends on: 1003896

Updated

a year ago
Depends on: 1210595
You need to log in before you can comment on or make changes to this bug.