Closed
Bug 344616
Opened 18 years ago
Closed 11 years ago
Implement <input type="number">
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
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.
Updated•18 years ago
|
Updated•15 years ago
|
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?
Comment 2•15 years ago
|
||
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•15 years ago
|
||
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
Comment 4•14 years ago
|
||
This is still WIP. Everything related to constraint validation is missing.
Updated•14 years ago
|
Keywords: dev-doc-needed
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•14 years ago
|
||
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•14 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!
Comment 8•14 years ago
|
||
Unfortunately, this is not going to be in Firefox 4.0.
This will probably be implemented for the following release.
Comment 9•14 years ago
|
||
Attachment #450253 -
Attachment is obsolete: true
Comment 10•14 years ago
|
||
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
Comment 11•14 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
Comment 12•14 years ago
|
||
(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•14 years ago
|
||
(In reply to comment #12)
> By default <input type='number'> should only accept *numbers*.
I meant 'integers'.
Comment 14•14 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•14 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="#.###,##"
Comment 17•14 years ago
|
||
(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•14 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...
Comment 19•14 years ago
|
||
(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•14 years ago
|
||
(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•14 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•14 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 :-)
Comment 23•14 years ago
|
||
(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•14 years ago
|
||
(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•14 years ago
|
||
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•14 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•14 years ago
|
||
And the same goes for the date format:
US: MM-dd-yyyy
GB: dd-MM-yyyy
Comment 28•14 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•14 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•14 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.
Comment 31•14 years ago
|
||
(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•14 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•14 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•14 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
Comment 35•14 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.
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•14 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•14 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•14 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•14 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•14 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•14 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•14 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.
Comment 46•13 years ago
|
||
Hi Mounir,
When do you expect that this bug will be fixed? Maybe for Firefox 13 or 14?
Comment 47•13 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.
Updated•13 years ago
|
Blocks: ringmark-ring1
Comment 48•12 years ago
|
||
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•12 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•12 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•12 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•12 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: html5test
Comment 53•12 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•12 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•12 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•12 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•11 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•11 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.
Updated•11 years ago
|
Assignee: mounir → jwatt
Comment 59•11 years ago
|
||
Do not forget to implement checkValidity() for it.
Comment 60•11 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•11 years ago
|
Blocks: number-input
Comment 61•11 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 | ||
Comment 63•11 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•11 years ago
|
Updated•11 years ago
|
Comment 64•11 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•11 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•11 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•11 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•11 years ago
|
QA Contact: petruta.rasa
Comment 68•11 years ago
|
||
Well, right now ff28beta simply crashes on the page I've posted above.
I'm on win7 x64
Assignee | ||
Comment 69•11 years ago
|
||
Working on the crasher in bug 973344.
Assignee | ||
Comment 70•11 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.
Assignee | ||
Comment 72•11 years ago
|
||
Yes, lots of reftests and mochitests were included in the patches for various dependencies and follow-up bugs.
Flags: needinfo?(jwatt)
Comment 73•11 years ago
|
||
This feature most certainly is not implemented.
Firefox 28.0, Windows 7 Pro x64
Assignee | ||
Comment 74•11 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•11 years ago
|
||
Please correct the chart included here:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Input#Browser_compatibility
Assignee | ||
Comment 76•11 years ago
|
||
Ah, thanks for pointing that out! Fixed.
Comment 77•11 years ago
|
||
No problem. Good to see this is finally coming about.
Comment 78•11 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).
Comment 79•11 years ago
|
||
<input type="number" readonly="readonly"> allow to change value with spin buttons
Comment 80•11 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.
Comment 81•11 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•11 years ago
|
||
Native theming makes that non-trivial to fix. It's covered by bug 947340 and bug 947365.
You need to log in
before you can comment on or make changes to this bug.
Description
•