The truth about Input Types | number, text

Everyone agrees: Use suitable Input Types – immediately. The browser falls “softly” back to a standard input field, should it not be able to understand the used Input Type. In principle there is not much to say against this direction. Often the use is also justified with much better semantics. Then it gets trickier.

Semantics of Input Types

Let’s take a look at <input type=”number”> and have a look at the specification:

“The type=number state is not appropriate for input that happens to only consist of numbers but isn’t strictly speaking a number.” Source

Thus, the specification provides this input type only for numbers that represent a type of set. For example, this could be the number of an item in a shopping cart. Framed with two buttons, such an input field would form an excellent semantic “quantity selector”.

On the other hand, there are inputs that cannot be sensibly increased or decreased. Examples are credit card numbers, postal codes, customer numbers, SKUs, etc. Here the semantics would not be better, but the input would be easier for the user.

The WHATWG community has the following opinion:

“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)”. Source

You have to know that some browsers provide small buttons to increase and decrease the number when type=”number” is selected. And in this respect I also agree with the quote.

Semantics over Usability?

I do not find it optimal to use <input type=”text” pattern=”[0-9]*”> as an alternative. If keyboards of mobile devices would react to the pattern in the pattern attribute, this would be the optimal way. The pattern is used to identify which inputs are possible and accordingly a customized keypad is provided. Too much “if and would” – that’s not how it works.

If the input field really only allows numbers, then the user should also be provided with the appropriate keyboard. Since this only works with type=”number”, usability beats semantics at this point. And the concerns of the WHATWG can also be eliminated by hiding the spin buttons via CSS for such cases.

HTML

SCSS

CSS

.no-spinner {
  -moz-appearance: textfield;

  &::-webkit-inner-spin-button {
    display: none;
  }
}

Unfortunately, a small drop of bitterness remains. By using the mouse scroll wheel in the focused number input field, the value can still be changed (by mistake).