Closed Bug 344616 Opened 18 years ago Closed 11 years ago

Implement <input type="number">

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla29

People

(Reporter: WeirdAl, Assigned: jwatt)

References

(Blocks 1 open bug, )

Details

(Keywords: dev-doc-needed, feature, html5)

Attachments

(2 obsolete files)

I'm willing to take a shot at implementing <input type="number"> as described in Web Forms 2.0.
Depends on: 344618
Blocks: 344618
No longer depends on: 344618
Component: DOM: HTML → DOM: Core & HTML
QA Contact: ian → general
Assignee: ajvincent → mounir.lamouri
Status: NEW → ASSIGNED
OS: Windows XP → All
Hardware: x86 → All
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
Blocks: 566348
Depends on: 345624
Depends on: 549475
Keywords: html5
Attached patch Patch - WIP (content part) (obsolete) — Splinter Review
This is still WIP. Everything related to constraint validation is missing.
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
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.
Attached patch Patch - WIP (content part) (obsolete) — Splinter Review
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
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'.
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.
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.
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. :-)
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.
(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.
(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 (,)
And the same goes for the date format: US: MM-dd-yyyy GB: dd-MM-yyyy
(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.
(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...
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?
(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?
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.
(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.
(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.
> 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.
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?
"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!
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.
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).
(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
Hi Mounir, When do you expect that this bug will be fixed? Maybe for Firefox 13 or 14?
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.
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
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.
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
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?
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.
(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.
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
(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.
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/
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.
(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
Depends on: 912511
Depends on: 915758
Depends on: 917386
Depends on: 926412
Depends on: 926419
Depends on: 927435
Depends on: 930010
Depends on: 935501
Depends on: 935506
Depends on: 935508
Depends on: 935544
Depends on: 935549
Depends on: 939248
Depends on: 939635
Depends on: 940006
Depends on: 940696
Depends on: 940760
Depends on: 940764
Do not forget to implement checkValidity() for it.
Depends on: 941367
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.
Depends on: 943047
Blocks: number-input
No longer depends on: 939248
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)
Depends on: 945784
Depends on: 946184
Depends on: 946262
Depends on: 946390
Depends on: 946398
Pretty much answered by Bug 946398.
Flags: needinfo?(jwatt)
(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.
No longer depends on: 946262
Depends on: 947728
Depends on: 947740
Depends on: 949117
No longer blocks: 559761
Depends on: 948433, 948549, 559761, 948475, 949134
Depends on: 951310
Depends on: 791653
Depends on: 949891
Blocks: 791653
No longer depends on: 791653
Depends on: 966844
Depends on: 966861
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?
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).
(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
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).
QA Contact: petruta.rasa
No longer depends on: 966844
Keywords: feature
Well, right now ff28beta simply crashes on the page I've posted above. I'm on win7 x64
Working on the crasher in bug 973344.
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
Closed: 11 years ago
Depends on: 967429, 970257
Resolution: --- → FIXED
Target Milestone: --- → mozilla29
Does this have automation coverage?
Flags: needinfo?(jwatt)
Yes, lots of reftests and mochitests were included in the patches for various dependencies and follow-up bugs.
Flags: needinfo?(jwatt)
Blocks: 982189
This feature most certainly is not implemented. Firefox 28.0, Windows 7 Pro x64
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
Ah, thanks for pointing that out! Fixed.
No problem. Good to see this is finally coming about.
(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).
Depends on: 1003741
Depends on: 1004327
Depends on: 1004130
Depends on: 1003896
<input type="number" readonly="readonly"> allow to change value with spin buttons
Depends on: 1010184
Depends on: 1010158
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.
Depends on: 1012818
Depends on: 1012976
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/
Native theming makes that non-trivial to fix. It's covered by bug 947340 and bug 947365.
Depends on: 1033400
Depends on: 1191519
No longer depends on: 1003896
Depends on: 1210595
Depends on: 1315531
Depends on: 1542483
No longer depends on: 1012818
No longer depends on: 926412
No longer depends on: 1315531
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: