Die Wahrheit über Input Types mit number und text

The truth about Input Types | number, text

21. January 2020

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

<input type=”number” class=”no-spinner”>

 

 

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).

SIE KÖNNEN SICH BEI UNS BEDANKEN!

Sofern Ihnen der Artikel geholfen hat, können Sie sich mit wenig Aufwand revanchieren!

 

Bitte hinterlassen Sie uns eine positive Bewertung.

 

Falls Sie Fehler entdecken oder ein Artikel unvollständig ist, freuen wir uns über einen Kommentar.

Bewertung erstellen

Comments

Tell us what you think! Reply now

Your email address will not be published. Required fields are marked *