One guideline is that if leading zeros are important, it's not a number.
The values 0001 and 01 may be different, for example.
This holds in reverse. 1.000 indicates a higher precision than 1.0 so should not be stored as a "normal" computer number like an IEEE 754 float or double.
That spec section ends with the note matching the guideline from the submitted link:
> The type=number state is not appropriate for input that happens to only consist of numbers but isn't strictly speaking a number. For example, it would be inappropriate for credit card numbers or US postal codes. A simple way of determining whether to use type=number is to consider whether it would make sense for the input control to have a spinbox interface (e.g. with "up" and "down" arrows). Getting a credit card number wrong by 1 in the last digit isn't a minor mistake, it's as wrong as getting every digit incorrect. So it would not make sense for the user to select a credit card number using "up" and "down" buttons. When a spinbox interface is not appropriate, type=text is probably the right choice (possibly with a pattern attribute).
The word “number” is ambiguous. A social security number “isn't strictly speaking a number,” but everyone still calls it a number. In other words, “number” can mean different things in different contexts. That’s what caused the <input type=number> issue in the first place.
I think it would be better if the HTML standard did not use terms that are ambiguous. I take back type=quantity; that’s not accurate either. Maybe type=float?
5 comments
[ 0.34 ms ] story [ 22.6 ms ] threadThe values 0001 and 01 may be different, for example.
This holds in reverse. 1.000 indicates a higher precision than 1.0 so should not be stored as a "normal" computer number like an IEEE 754 float or double.
The HTML spec says "number" is supposed to be for floating-point numbers - https://html.spec.whatwg.org/multipage/input.html#number-sta... . That can include quantity, but also other things. Like negative numbers.
That spec section ends with the note matching the guideline from the submitted link:
> The type=number state is not appropriate for input that happens to only consist of numbers but isn't strictly speaking a number. For example, it would be inappropriate for credit card numbers or US postal codes. A simple way of determining whether to use type=number is to consider whether it would make sense for the input control to have a spinbox interface (e.g. with "up" and "down" arrows). Getting a credit card number wrong by 1 in the last digit isn't a minor mistake, it's as wrong as getting every digit incorrect. So it would not make sense for the user to select a credit card number using "up" and "down" buttons. When a spinbox interface is not appropriate, type=text is probably the right choice (possibly with a pattern attribute).
I think it would be better if the HTML standard did not use terms that are ambiguous. I take back type=quantity; that’s not accurate either. Maybe type=float?
I think that's why it's called "number."
Semi-tongue-in-cheek, perhaps what's missing is a "PIC" or "PICTURE" element, from COBOL - https://en.wikipedia.org/wiki/COBOL#PICTURE_clause .