bei uns (Version 2.4.11) war es so, dass bei Eingabe von Zielbetrag, gegebenem Betrag usw. nicht automatisch das numerische Keyboard auf den Smartphones angezeigt wurde, sondern das normale mit Buchstaben usw. Weiss nicht, ob das ein Bug oder das Feature evtl. noch nicht vorhanden ist. Eine Eingabe von Buchstaben macht in diesen Feldern ja wenig Sinn(?).
Ich konnte es in der paydesk.html (mit iPhone und mobilem Chrome/Firefox getestet) mit folgenden Attributen bei den <input>-Elementen lösen:
das Problem mit dem Typ "Numeric" ist, dass es je nach Browser keine Kommas erlaubt, sondern nur den Punkt als Dezimalzeichen für numerische Einghaben. Daher bin ich von numeric wieder zurück auf text gegangen.
Danke für die Info Dann ist's natürlich ungeeignet für den generellen Einsatz. Bei uns in der Schweiz wird eben der Punkt als Dezimaltrennzeichen verwendet, drum macht's bei uns nichts, wenn die Tastatur kein Komma hat.
ich habe mir auch den Wechselgeldrechner angeschaut, es wäre cool, wenn bei den Zahlenfeldern direkt die Tastatur für Zahlen eingeblendet werden würde
weiter ob schreibst Du vom Problem mit dem Typ "Numeric" - hilft hier evtl. Typ "decimal" weiter?
oder wie verhält es sich mit dem bereits verwendeten Typ "number" z.B. beim Feld Anzahl (bei der Bestellaufnahme, wenn ein Artikel bei "Neue Order" angeklickt wird und die Menge bei Anzahl geändert werden kann) (<input id="act-numberfield" type="number" value="" data-mini="true">) funktioniert es mit type="number" sehr gut, die Tastatur bietet sowohl das Komma, als auch den Punkt sowie weitere Sonderzeichen zur Eingabe an.
für den Wechselgeldrechner wäre dies aus meiner Sicht bei folgenden Feldern hilfreich,
wo das Attribut "type" von "text" auf "number" geändert werden müsste
paydesk.html
Wechselgeldrechner "Angabe inkl. Trinkg."
Feld Bezahlt:
Zeile 142 ...<input type="text" id="haspaid"...
<input id="haspaid" type="text" value="" data-mini="true" placeholder="3,00 Euro">
Zielbetrag:
Zeile 145 ...<input type="text" id="tipfield"...
<input id="tipfield" type="text" value="" data-mini="true" placeholder="0,00 Euro">
im Zuge dessen hab ich mir weitere Zahlenfelder angeschaut, bei denen aus meiner Sicht dieses Optimierungspotenzial besteht:
waiter.html
Neue Order - Artikel auswählen - Aktion auswählen - Feld Neuer Preis:
Zeile 40 ...<input type="text" id="act-changepricefield"...
<input id="act-changepricefield" type="text" value="" data-mini="true" placeholder="Neuer Preis: ">
Feld Anzahl bei +/-Button
Zeile 334 ...<input id="enternumberfield" type="text"...
<input id="enternumberfield" class="whiteinput" type="text" autofocus="">
Feld Storno-Code - da der Storno-Code vermutlich meist eine Zahl ist
Zeile 173 ...<input id=cancelcodefield type="password"...
<input id"cancelcodefield" type="password" placeholder="Storno-Code">
Die meisten Eingabefelder beziehen sich auf Werte, die ein Dezimaltrennzeichen enthalten können (Geldbeträge mit Cent). In Deutschland verwenden wir das Komma, aber die Browser lassen für den Input-Typ "number" nur den Punkt zu. Auf einer On-Screen-Tastatur ist das vielleicht noch ok, aber gibt der Benutzer direkt ein Komma ein, so wird die Eingabe nicht akzeptiert.
Für diese und ähnliche Fälle habe ich eine eigene einblendbare Tastatur erstellt, die ich an verschiedenen Stellen einbaue, aber diese muss je nach Eingabefeld angepasst werden und entsprechend auch gemanaged werden (open-close-eventhandling-KommaInSchweizAndersAlsDeutschland) usw. Ich würde die Tastatur ja gerne überall einbauen, weil ich den Bedarf durchaus sehe, aber im Moment haben andere Punkte noch höhere Prio.
Dann ist's natürlich ungeeignet für den generellen Einsatz. Bei uns in der Schweiz wird eben der Punkt als Dezimaltrennzeichen verwendet, drum macht's bei uns nichts, wenn die Tastatur kein Komma hat. 