Repository navigation
html.elements.input.type_number - Under browser compatibility it says supported by firefox. This is incorrect. #18050
Description
What type of issue is this?
Incorrect support data (ex. Chrome says "86" but support was added in "40")
What information was incorrect, unhelpful, or incomplete?
Under browser compatibility it says it is compatible with FireFox. Using version 106.0.1 (64-bit), this doesn't work. Up down arrows appear, but you can type in any alpha character which also breaks the up and down arrows. This should be changed to incompatible.
What browsers does this problem apply to, if applicable?
Firefox
What did you expect to see?
Since this feature doesn't work in firefox, I expected that section to show No, instead of Yes.
Did you test this? If so, how?
Yes, I went to the page and used the Try It section while using the latest version of FireFox (106.0.1 (64-bit)).
Can you link to any release notes, bugs, pull requests, or MDN pages related to this?
Go to this page and try it.
Do you have anything more you want to share?
No response
MDN URL
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/number
MDN metadata
MDN page report details
- Query:
html.elements.input.type_number - Report started: 2022-10-20T15:12:26.888Z
Activity
teoli2003 commentedon Oct 20, 2022
Looks ok to me. Have you tried to run a constraint validation?
Without running constraint validation, it won't do anything.
thecodemonk commentedon Oct 20, 2022
Chrome and Edge do not even allow non-numeric values to be entered. There is a bug write up on Bugzilla for firefox that this has been broken for the last 5 years. I don't think it's appropriate to say this is "working" and should need extra validation for it to work as it would be expected to work.
This also really doesn't have anything to do with constraints either. It's supposed to be a numeric input, but it's allowing non-numeric characters to be input and setting the value to "".
mgol commentedon Oct 20, 2022
The spec doesn’t mandate what the user interface looks like; please read the following carefully:
https://html.spec.whatwg.org/multipage/input.html#number-state-(type=number)
In particular:
Also:
Firefox does support the API. Whatever you think about the choices made in the Firefox UI, it doesn’t change the fact the browser does support the API.
thecodemonk commentedon Oct 20, 2022
I did read it carefully, especially the part that you highlighted first... What would better suit a user's need? This is not suited well here, thus should be noted appropriately. Since this doesn't help anyone by allowing all input, thus confusing a user as to why something went wrong, then the lack of support should be noted appropriately, which it is not here.
Supporting an API and implementing that API are vastly different things.
The bugzilla report also made the same argument that it is supported, yet has come up dozens of more times as people continue to write up that it is, in fact, a bug. If it walks and quacks like a duck, it's probably a duck.
mgol commentedon Oct 20, 2022
This part says "user agent vendors are encouraged", not "required" so this is not a hard requirement.
Also, even Chrome & Safari do allow some non-numeric data to be entered - namely, you can enter the letter
e. Many people don't know the scientific notation so they would be surprised about that as well.I do agree the current behavior around
<input type=number>is generally confusing; a lot of the issues are caused by how the API is designed and that e.g. there's no concept of retrieving the user-provided value if it's invalid - you just know it's invalid. It's also true that browser differences here may surprise people so it'd be good to add a note to the compat table about this difference in implementation; it might be attached to the Firefox entry (although, the site maintainers should make the decision here). That would be informative and would resolve the confusion many developers might have.I do not agree, though, that Firefox should be marked as red as the API is supported.
teoli2003 commentedon Oct 21, 2022
Closing per comments.