Alle sind sich einig: Nutze passende Input Types – Sofort. Der Browser fällt ja „weich“ auf ein Standard-Eingabefeld zurück, sollte er einmal nicht in der Lage sein, den genutzten Input Type zu verstehen. Prinzipiell ist gegen diese Marschrichtung nicht viel zu sagen. Oft wird der Einsatz auch mit einer viel besseren Semantik begründet. Dann wird’s schon kniffliger. Hilfe nötig?
Semantik von Input Types
Nehmen wir uns mal <input type=“number“> zur Brust und werfen einen Blick in die Spezifikation:
„The type=number state is not appropriate for input that happens to only consist of numbers but isn’t strictly speaking a number.“ Quelle
Die Spezifikation sieht diesen Input-Type also nur für Zahlen vor, die eine Art von Mengen darstellen. Dies könnte z. B. die Anzahl eines Artikels in einem Warenkorb sein. Umrahmt mit zwei Buttons würde solch ein Eingabefeld einen hervorragend semantischen „Quantity-Selector“ bilden.
Auf der anderen Seite gibt es Eingaben, die nicht sinnvoll erhöht und erniedrigt werden können. Die Beispiele sind Kreditkartennummern, Postleitzahlen, Kundennummern, SKUs, etc. Hier wäre die Semantik nicht besser, aber die Eingabe für den Nutzer einfacher.
Die WHATWG Community ist dazu folgender Meinung:
„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).“ Quelle
Hierzu muss man wissen, dass einige Browser bei type=“number“ kleine Buttons zum Erhöhen und Erniedrigen der Zahl bereitstellen. Und insofern stimme ich dem Zitat auch zu.
Semantik über Usability?
Nicht optimal finde ich, als Alternative <input type=“text“ pattern=“[0-9]*“> zu verwenden. Wenn Tastaturen mobiler Endgeräte auf das Muster im pattern-Attribut reagieren würden, wäre dies der Optimalweg. Durch das Muster wird erkannt, welche Eingaben möglich sind und dementsprechend wird ein angepasstes Tastenfeld zur Verfügung gestellt. Zu viel „wenn und würde“ – so funktioniert das nicht.
Lässt das Eingabefeld tatsächlich nur Zahlen zu, dann sollte der Nutzer auch die passende Tastatur dazu erhalten. Da das nur mit type=“number“ funktioniert, schlägt an dieser Stelle Usability die Semantik. Und die Bedenken der WHATWG können auch beseitigt werden, in dem für solche Fälle die Spin-Buttons per CSS ausgeblendet werden.
HTML
<input type=“number“ class=“no-spinner“>
SCSS
.no-spinner {
-moz-appearance: textfield;
&::-webkit-inner-spin-button {
display: none;
}
}Ein kleiner Wehrmutstropfen bleibt leider erhalten. Per Maus-Scrollrad im fokussierten Number-Eingabefeld lässt sich der Wert weiterhin (aus Versehen) verändern. Gerne können wir das auch umsetzen!
Kommentare