Bugzilla

(In reply to thecodemonk from comment #34)
> If this isn't going to be fixed, then the MDN docs [here](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/number#browser_compatibility) need to be updated to show that FireFox isn't supported. I have submitted a request to have this changed.

(This request seems to have been https://github.com/mdn/browser-compat-data/issues/18050 which was closed no-change, essentially for reasons described above in comment 3.)

(In reply to chrissigrilus from comment #35)
> I can personally barely see a use case for the current behavior

The current permissive behavior isn't really a "use-case"; it's more that **the space-of-use-cases is sparsely distributed around lots of invalid input**.  If we were to add validity checking to attempt to prevent invalid input from being typed, then it's likely our validity-checking will be incomplete, or will prevent valid input from some locale, or both.

Put another way: we're in the situation we are right now because proper user-typing-restrictions here are unspecified and would be quite complex to design and implement robustly, especially in light of variation between locales in number formatting.

See comment 4 and https://learn.microsoft.com/en-us/globalization/locale/number-formatting for simple examples of the complexity here, for folks unfamiliar with internationalized number formatting differences, plus https://unicode.org/reports/tr35/tr35-numbers.html#23-number-symbols

> other browsers feel more intuitive in that regard.

From some brief testing on my end to check the state-of-things in other browsers, I found:
(1) WebKit/Safari continues to allow users to type arbitrary text into input type=number fields (similar to Firefox).  e.g. I can just type "banana" into an `<input type="number">` field there. Are you seeing something different?

(2) Chromium has some character-blocking restrictions (e.g. I can't type "banana"), but they seem fairly incomplete and also possibly over-reaching.   Chrome allow the letter `e`, as well as `-+` or `+-`.  They let me type `++`, `+-`, `1+2-7`, `++e` -- but not `e++` and not `1+2-7+5`. I suspect this is all a way of allowing expressions like `-5e+10`, but of course it allows a variety of bogus input to be typed, as noted above.  They also have some input-blocking rules around the period character, `.` -- e.g. `.3` is allowed, and so is `.++` and `.e`, but `e.` is forbidden.

Also, my Chrome seems to forbid the comma character `,` entirely in number fields, despite that being the proper decimal separator for German users.  (Maybe German-localized Chrome allows that and forbids the period character instead? I'm not sure.)
 
> If not I think that my team will have to provide some monkeypatch if there is none already. In case this behavior is up for discussion maybe we can help with that as well.

Can you elaborate on what you're having to handle, and what part of it is Firefox-specific (and isn't also-needed-for-WebKit)?  (Do you also need to exclude e.g. bogus values like `-+.e` in Chromium)?

Also: note that the `required` flag *might* help you here.[1]  That triggers client-side validation to be sure that the browser has actually been able to parse a number from what you provided, according to your locale.  (Though obviously if you don't want to strictly require a value to be entered into your number field, then `required` won't be the tool that you want to reach for.)

[1] e.g. if I load `data:text/html,<form><input type="number" required><input type="submit">` and type in "abc" and press submit, I get a prompt telling me that I need to enter a number into that field.

(In reply to thecodemonk from comment #34)
> If this isn't going to be fixed, then the MDN docs [here](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/number#browser_compatibility) need to be updated to show that FireFox isn't supported. I have submitted a request to have this changed.

(This request seems to have been https://github.com/mdn/browser-compat-data/issues/18050 which was closed no-change, essentially for reasons described above in comment 3.)

(In reply to chrissigrilus from comment #35)
> I can personally barely see a use case for the current behavior

The current permissive behavior isn't really a "use-case"; it's more that **the space-of-use-cases is sparsely distributed around lots of invalid input**.  If we were to add validity checking to attempt to prevent invalid input from being typed, then it's likely our validity-checking will be incomplete, or will prevent valid input from some locale, or both.

Put another way: we're in the situation we are right now because proper user-typing-restrictions here are unspecified and would be quite complex to design and implement robustly, especially in light of variation between locales in number formatting.

See comment 4 and https://learn.microsoft.com/en-us/globalization/locale/number-formatting for simple examples of the complexity here, for folks unfamiliar with internationalized number formatting differences, plus https://unicode.org/reports/tr35/tr35-numbers.html#23-number-symbols

> other browsers feel more intuitive in that regard.

From some brief testing on my end to check the state-of-things in other browsers, I found:
(1) WebKit/Safari continues to allow users to type arbitrary text into input type=number fields (similar to Firefox).  e.g. I can just type "banana" into an `<input type="number">` field there. Are you seeing something different?

(2) Chromium has some character-blocking restrictions (e.g. I can't type "banana"), but they seem fairly incomplete and also possibly over-reaching (though maybe the overreach is just locale-specific strictness).
* RE incompleteness: Chrome allow the letter `e`, as well as `-+` or `+-`.  They let me type `++`, `+-`, `1+2-7`, `++e` -- but not `e++` and not `1+2-7+5`. I suspect this is all a way of allowing expressions like `-5e+10`, but of course it allows a variety of bogus input to be typed, as noted above.  They also have some input-blocking rules around the period character, `.` -- e.g. `.3` is allowed, and so is `.++` and `.e`, but `e.` is forbidden.
* RE possible-overreach: Also, my Chrome seems to forbid the comma character `,` entirely in number fields, despite that being the proper decimal separator for German users.  (Maybe German-localized Chrome allows that and forbids the period character instead? I'm not sure.)
 
> If not I think that my team will have to provide some monkeypatch if there is none already. In case this behavior is up for discussion maybe we can help with that as well.

Can you elaborate on what you're having to handle, and what part of it is Firefox-specific (and isn't also-needed-for-WebKit)?  (Do you also need to exclude e.g. bogus values like `-+.e` in Chromium)?

Also: note that the `required` flag *might* help you here.[1]  That triggers client-side validation to be sure that the browser has actually been able to parse a number from what you provided, according to your locale.  (Though obviously if you don't want to strictly require a value to be entered into your number field, then `required` won't be the tool that you want to reach for.)

[1] e.g. if I load `data:text/html,<form><input type="number" required><input type="submit">` and type in "abc" and press submit, I get a prompt telling me that I need to enter a number into that field.

(In reply to thecodemonk from comment #34)
> If this isn't going to be fixed, then the MDN docs [here](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/number#browser_compatibility) need to be updated to show that FireFox isn't supported. I have submitted a request to have this changed.

(This request seems to have been https://github.com/mdn/browser-compat-data/issues/18050 which was closed no-change, essentially for reasons described above in comment 3.)

(In reply to chrissigrilus from comment #35)
> I can personally barely see a use case for the current behavior

The current permissive behavior isn't really a "use-case"; it's more that **the space-of-use-cases is sparsely distributed around lots of invalid input**.  If we were to add validity checking to attempt to prevent invalid input from being typed, then it's likely our validity-checking will be incomplete, or will prevent valid input from some locale, or both.

Put another way: we're in the situation we are right now because proper user-typing-restrictions here are unspecified and would be quite complex to design and implement robustly, especially in light of variation between locales in number formatting.

See comment 4 and https://learn.microsoft.com/en-us/globalization/locale/number-formatting for simple examples of the complexity here, for folks unfamiliar with internationalized number formatting differences, plus https://unicode.org/reports/tr35/tr35-numbers.html#23-number-symbols

> other browsers feel more intuitive in that regard.

From some brief testing on my end to check the state-of-things in other browsers, I found:
(1) WebKit/Safari continues to allow users to type arbitrary text into input type=number fields (similar to Firefox).  e.g. I can just type "banana" into an `<input type="number">` field there. Are you seeing something different?

(2) Chromium has some character-blocking restrictions (e.g. I can't type "banana"), but they seem fairly incomplete and also possibly over-reaching (though maybe the overreach is just locale-specific strictness).
* RE incompleteness: Chrome allow the letter `e`, as well as `-+` or `+-`.  They let me type `++`, `+-`, `1+2-7`, `++e`, but not `e++` and not `1+2-7+5`. I suspect this is all a way of allowing expressions like `-5e+10`, but of course it allows a variety of bogus input to be typed, as noted above.  They also have some input-blocking rules around the period character, `.` -- e.g. `.3` is allowed, and so is `.++` and `.e`, but `e.` is forbidden.
* RE possible-overreach: Also, my Chrome seems to forbid the comma character `,` entirely in number fields, despite that being the proper decimal separator for German users.  (Maybe German-localized Chrome allows that and forbids the period character instead? I'm not sure.)
 
> If not I think that my team will have to provide some monkeypatch if there is none already. In case this behavior is up for discussion maybe we can help with that as well.

Can you elaborate on what you're having to handle, and what part of it is Firefox-specific (and isn't also-needed-for-WebKit)?  (Do you also need to exclude e.g. bogus values like `-+.e` in Chromium)?

Also: note that the `required` flag *might* help you here.[1]  That triggers client-side validation to be sure that the browser has actually been able to parse a number from what you provided, according to your locale.  (Though obviously if you don't want to strictly require a value to be entered into your number field, then `required` won't be the tool that you want to reach for.)

[1] e.g. if I load `data:text/html,<form><input type="number" required><input type="submit">` and type in "abc" and press submit, I get a prompt telling me that I need to enter a number into that field.

(In reply to thecodemonk from comment #34)
> If this isn't going to be fixed, then the MDN docs [here](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/number#browser_compatibility) need to be updated to show that FireFox isn't supported. I have submitted a request to have this changed.

(This request seems to have been https://github.com/mdn/browser-compat-data/issues/18050 which was closed no-change, essentially for reasons described above in comment 3.)

(In reply to chrissigrilus from comment #35)
> I can personally barely see a use case for the current behavior

The current permissive behavior isn't really a "use-case"; it's more that **the space-of-use-cases is sparsely distributed around lots of invalid input**.  If we were to add validity checking to attempt to prevent invalid input from being typed, then it's likely our validity-checking will be incomplete, or will prevent valid input from some locale, or both.

Put another way: we're in the situation we are right now because proper user-typing-restrictions here are unspecified and would be quite complex to design and implement robustly, especially in light of variation between locales in number formatting.

See comment 4 and https://learn.microsoft.com/en-us/globalization/locale/number-formatting for simple examples of the complexity here, for folks unfamiliar with internationalized number formatting differences, plus https://unicode.org/reports/tr35/tr35-numbers.html#23-number-symbols

> other browsers feel more intuitive in that regard.

From some brief testing on my end to check the state-of-things in other browsers, I found:
(1) WebKit/Safari continues to allow users to type arbitrary text into input type=number fields (similar to Firefox).  e.g. I can just type "banana" into an `<input type="number">` field there. Are you seeing something different?

(2) Chromium has some character-blocking restrictions (e.g. I can't type "banana"), but they seem fairly incomplete and also possibly over-reaching (though maybe the overreach is just locale-specific strictness).
* RE incompleteness: Chrome allow the letter `e`, as well as `-+` or `+-`.  They let me type `++`, `+-`, `1+2-7`, `++e`, but not `e++` and not `1+2-7+5`. I suspect this is all a way of allowing expressions like `-5e+10`, but of course it allows a variety of bogus input to be typed, as noted above.  They also have some input-blocking rules around the period character, `.` -- e.g. `.3` is allowed, and so is `.++` and `.e`, but `e.` is forbidden.
* RE possible-overreach: Chrome on my machine seems to forbid the comma character `,` entirely in number fields, despite that being the proper decimal separator for German users.  (Maybe German-localized Chrome allows that and forbids the period character instead? I'm not sure.)
 
> If not I think that my team will have to provide some monkeypatch if there is none already. In case this behavior is up for discussion maybe we can help with that as well.

Can you elaborate on what you're having to handle, and what part of it is Firefox-specific (and isn't also-needed-for-WebKit)?  (Do you also need to exclude e.g. bogus values like `-+.e` in Chromium)?

Also: note that the `required` flag *might* help you here.[1]  That triggers client-side validation to be sure that the browser has actually been able to parse a number from what you provided, according to your locale.  (Though obviously if you don't want to strictly require a value to be entered into your number field, then `required` won't be the tool that you want to reach for.)

[1] e.g. if I load `data:text/html,<form><input type="number" required><input type="submit">` and type in "abc" and press submit, I get a prompt telling me that I need to enter a number into that field.

(In reply to thecodemonk from comment #34)
> If this isn't going to be fixed, then the MDN docs [here](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/number#browser_compatibility) need to be updated to show that FireFox isn't supported. I have submitted a request to have this changed.

(This request seems to have been https://github.com/mdn/browser-compat-data/issues/18050 which was closed no-change, essentially for reasons described above in comment 3.)

(In reply to chrissigrilus from comment #35)
> I can personally barely see a use case for the current behavior

The current permissive behavior isn't really a "use-case"; it's more that **the space-of-use-cases is sparsely distributed around lots of invalid input**.  If we were to add validity checking to attempt to prevent invalid input from being typed, then it's likely our validity-checking will be incomplete, or will prevent valid input from some locale, or both.

Put another way: we're in the situation we are right now because proper user-typing-restrictions here are unspecified and would be quite complex to design and implement robustly, especially in light of variation between locales in number formatting.

See comment 4 and https://learn.microsoft.com/en-us/globalization/locale/number-formatting for simple examples of the complexity here, for folks unfamiliar with internationalized number formatting differences, plus https://unicode.org/reports/tr35/tr35-numbers.html#23-number-symbols

> other browsers feel more intuitive in that regard.

From some brief testing on my end to check the state-of-things in other browsers, I found:
(1) WebKit/Safari continues to allow users to type arbitrary text into input type=number fields (similar to Firefox).  e.g. I can just type "banana" into an `<input type="number">` field there. Are you seeing something different?

(2) Chromium has some character-blocking restrictions (e.g. I can't type "banana"), but they seem fairly incomplete and also possibly over-reaching (though maybe the overreach is just locale-specific strictness).
* RE incompleteness: Chrome allow the letter `e`, as well as `-+` or `+-`.  They let me type `++`, `+-`, `1+2-7`, `++e`, but not `e++` and not `1+2-7+5`. I suspect this is all a way of allowing expressions like `-5e+10`, but of course it allows a variety of bogus input to be typed, as noted above.  They also have some input-blocking rules around the period character, `.` -- e.g. `.3` is allowed, and so is `.++` and `.e`, but `e.` is forbidden.
* RE possible-overreach: Chrome on my machine seems to forbid the comma character `,` entirely in number fields, despite that being the proper decimal separator for German users.  (Maybe German-localized Chrome allows that and forbids the period character instead? I'm not sure.)
 
> If not I think that my team will have to provide some monkeypatch if there is none already. In case this behavior is up for discussion maybe we can help with that as well.

Can you elaborate on what you're having to handle, and what part of it is Firefox-specific (and isn't also-needed-for-WebKit)?  (Do you also need to exclude e.g. bogus non-numeric values like `-+.e` that users can type in Chromium)?

Also: note that the `required` flag *might* help you here.[1]  That triggers client-side validation to be sure that the browser has actually been able to parse a number from what you provided, according to your locale.  (Though obviously if you don't want to strictly require a value to be entered into your number field, then `required` won't be the tool that you want to reach for.)

[1] e.g. if I load `data:text/html,<form><input type="number" required><input type="submit">` and type in "abc" and press submit, I get a prompt telling me that I need to enter a number into that field.

(In reply to thecodemonk from comment #34)
> If this isn't going to be fixed, then the MDN docs [here](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/number#browser_compatibility) need to be updated to show that FireFox isn't supported. I have submitted a request to have this changed.

(This request seems to have been https://github.com/mdn/browser-compat-data/issues/18050 which was closed no-change, essentially for reasons described above in comment 3.)

(In reply to chrissigrilus from comment #35)
> I can personally barely see a use case for the current behavior

The current permissive behavior isn't really a "use-case"; it's more that **the space-of-use-cases is sparsely distributed around lots of invalid input**.  If we were to add validity checking to attempt to prevent invalid input from being typed, then it's likely our validity-checking will be incomplete, or will prevent valid input from some locale, or both.

Put another way: we're in the situation we are right now because proper user-typing-restrictions here are unspecified and would be quite complex to design and implement robustly, especially in light of variation between locales in number formatting.

See comment 4 and https://learn.microsoft.com/en-us/globalization/locale/number-formatting for simple examples of the complexity here, for folks unfamiliar with internationalized number formatting differences, plus https://unicode.org/reports/tr35/tr35-numbers.html#23-number-symbols

> other browsers feel more intuitive in that regard.

From some brief testing on my end to check the state-of-things in other browsers, I found:
(1) WebKit/Safari continues to allow users to type arbitrary text into input type=number fields (similar to Firefox).  e.g. I can just type "banana" into an `<input type="number">` field there. Are you seeing something different?

(2) Chromium has some character-blocking restrictions (e.g. I can't type "banana"), but they seem fairly incomplete and also possibly over-reaching (though maybe the overreach is just locale-specific strictness).
* RE incompleteness: Chrome allow the letter `e`, as well as `-+` or `+-`.  They let me type `++`, `+-`, `1+2-7`, `++e`, but not `e++` and not `1+2-7+5`. I suspect this is all a way of allowing expressions like `-5e+10`, but of course it allows a variety of bogus input to be typed, as noted above.  They also have some input-blocking rules around the period character, `.` -- e.g. `.3` is allowed, and so is `.++` and `.e`, but `e.` is forbidden.
* RE possible-overreach: Chrome on my machine seems to forbid the comma character `,` entirely in number fields, despite that being the proper decimal separator for German users.  (Maybe German-localized Chrome allows that and forbids the period character instead? I'm not sure.)
 
> If not I think that my team will have to provide some monkeypatch if there is none already. In case this behavior is up for discussion maybe we can help with that as well.

Can you elaborate on what you're having to handle, and what part of it is Firefox-specific (and isn't also-needed-for-WebKit)?  (Do you also need to exclude e.g. bogus non-numeric values like `e`, `.`, `-`, or `-+.e` that users can type in Chromium)?

Also: note that the `required` flag *might* help you here.[1]  That triggers client-side validation to be sure that the browser has actually been able to parse a number from what you provided, according to your locale.  (Though obviously if you don't want to strictly require a value to be entered into your number field, then `required` won't be the tool that you want to reach for.)

[1] e.g. if I load `data:text/html,<form><input type="number" required><input type="submit">` and type in "abc" and press submit, I get a prompt telling me that I need to enter a number into that field.