
HTML input type=number is only intended for amounts - SimeVidas
https://webplatform.news/issues/2020-03-06
======
eesmith
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.

~~~
SimeVidas
type=number should probably be renamed to type=quantity. Then, something like
type=numeric could be introduced for numeric strings.

~~~
eesmith
How would that help? It's not supposed to be just a quantity.

The HTML spec says "number" is supposed to be for floating-point numbers -
[https://html.spec.whatwg.org/multipage/input.html#number-
sta...](https://html.spec.whatwg.org/multipage/input.html#number-
state-\(type=number\)) . 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).

~~~
SimeVidas
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?

~~~
eesmith
It's an interface to a Javascript Number type, except it doesn't handle -0.0,
Inf, -Inf, and NaN values.

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](https://en.wikipedia.org/wiki/COBOL#PICTURE_clause)
.

