JürgenB: Input und Dezimalzahlen

Hallo,

ich lese Dezimalzahlen aus einem input-Element. Bisher habe ich das über ein Textinput gemacht. Nun wollte ich das „richtig“ machen und habe auf <input type="number" ...>umgestellt. Die Werte lese ich über value ein. valueAsNumber habe ich auch ausprobiert. Im Safari lassen sich die Zahlen einlesen, egal ob ich einen Dezimalpunkt oder ein Dezimalkomma verwende. Im Firefox unter MacOS liefert value aber bei nicht validen Eingaben einen leeren String, valueAsNumber liefert NaN. (Ich vermute, der FF macht es richtig.)

Nun möchte ich aber sowohl das Dezimalkomma als auch den Dezimalpunkt zulassen. Ich korrigiere das mit replace(/,/g,"."). Gibt es da eine Möglichkeit, die Zahlenvalidierung dahingehend zu erweitern, oder muss ich auf type=number verzichten?

Gruß
Jürgen

akzeptierte Antworten

  1. Hallo JürgenB,

    Die Spezifikation schreibt den Dezimalpunkt vor.

    Bis demnächst
    Matthias

    --
    Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
    1. Die Spezifikation schreibt den Dezimalpunkt vor.

      Da geht es nur um Interna, die Spec legt Browser-Herstellern an einer anderen Stelle nahe dem Nutzer Zahlen in seinem bevorzugten lokalen Zahlenformat anzuzeigen:

      This specification does not define what user interface user agents are to use; user agent vendors are encouraged to consider what would best serve their users' needs. For example, a user agent in Persian or Arabic markets might support Persian and Arabic numeric input (converting it to the format required for submission as described above). Similarly, a user agent designed for Romans might display the value in Roman numerals rather than in decimal; or (more realistically) a user agent designed for the French market might display the value with apostrophes between thousands and commas before the decimals, and allow the user to enter a value in that manner, internally converting it to the submission format described above.

      https://www.w3.org/TR/html51/sec-forms.html#number-state-typenumber

  2. Nun möchte ich aber sowohl das Dezimalkomma als auch den Dezimalpunkt zulassen.

    Das würde ich lassen, damit arbeitest du entgegen dem Standardverhalten der Browser und damit entgegen der Erwartungen des Nutzers. Ich gebe aber zu, dass die Formular-Lokalisierung der Browser viele Wünsche offen lässt. Du könntest den Eingabetypen zurück auf text setzen und die gültigen Zahlen mit einem regulären Ausdruck und dem pattern-Attribut validieren. Aber dann geht die semantische Information verloren, dass eine Zahl erwartet wird. Eine Folge ist, dass Smartphones keine spezifischen virtuellen Tastaturen einblenden. Damit schränkst du die Bedienbarkeit und Zugänglichkeit nur weiter ein.

    Im Firefox kannst du das lang-Attribut auf dem input-Element setzen, dann verwendet FF eine Zahlendarstellung, die für die angegebene Sprache hinterlegt ist. Chrome ignoriert das Attribut und benutzt scheinbar immer das Zahlenformat, das für die im Browser eingestellte Defaultsprache hinterlegt ist. Edge und Safari habe ich nicht ausprobiert.

    https://jsfiddle.net/djzxq5ym/

    1. Im Firefox kannst du das lang-Attribut auf dem input-Element setzen,

      oder gleich für das Dokument ...

      dann verwendet FF eine Zahlendarstellung, die für die angegebene Sprache hinterlegt ist.

      Ja. Und nur das.

      Chrome ignoriert das Attribut und benutzt scheinbar immer das Zahlenformat, das für die im Browser eingestellte Defaultsprache hinterlegt ist.

      Mein Chromium (Version 51.0.2704.79 Ubuntu 14.04 (64-bit)) nimmt mit

      <html lang="de_DE">
      <input id="num0" name="num0" type="number" step="0.01">
      

      sowohl das Komma als auch den Punkt als Dezimaltrenner dankbar an und verarbeitet beide in allen geprüften Situationen (GET, POST, JS) als Dezimaltrenner, aus 3,2 wird also 3.2.

      1. Hallo,

        Mein Chromium (Version 51.0.2704.79 Ubuntu 14.04 (64-bit)) nimmt [...] sowohl das Komma als auch den Punkt als Dezimaltrenner dankbar an und verarbeitet beide in allen geprüften Situationen (GET, POST, JS) als Dezimaltrenner, aus 3,2 wird also 3.2.

        und was macht er, wenn jemand die Unart praktiziert, einen Punkt als 1000er-Trennzeichen zu verwenden? Solange in einer Zahl beide Zeichen vorkommen, kann man ja noch ganz gut raten, aber wenn nicht, ist die richtige Entscheidung wohl Glückssache.

        So long,
         Martin

        --
        Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
        - Douglas Adams, The Hitchhiker's Guide To The Galaxy
        1. Mein Chromium (Version 51.0.2704.79 Ubuntu 14.04 (64-bit)) nimmt [...] sowohl das Komma als auch den Punkt als Dezimaltrenner dankbar an und verarbeitet beide in allen geprüften Situationen (GET, POST, JS) als Dezimaltrenner, aus 3,2 wird also 3.2.

          und was macht er, wenn jemand die Unart praktiziert, einen Punkt als 1000er-Trennzeichen zu verwenden?

          Schnelltest mit '2.000,34': Nimmt er zunächst an, in JS Ausgabe eines leeren Inhalts, beim Senden meckert er.

        2. Hallo Martin,

          und was macht er, wenn jemand die Unart praktiziert, einen Punkt als 1000er-Trennzeichen zu verwenden? Solange in einer Zahl beide Zeichen vorkommen, kann man ja noch ganz gut raten, aber wenn nicht, ist die richtige Entscheidung wohl Glückssache.

          da liefert type=number ein NaN oder ein "". Hier müsste dann ein noch aufwendigerer Korrekturtest die Eingabe korrigieren, aber nach meinem jetzigen eben nur über type=text.

          Gruß
          Jürgen

        3. Tausenderpunkte benutzt man eher bei der Ausgabe zwecks Lesbarkeit, beim Eingeben dürfte man die seltener erleben, oder macht ihr sowas???

          Rolf

          1. Hallo,

            Tausenderpunkte benutzt man eher bei der Ausgabe zwecks Lesbarkeit

            das hat man uns schon in der Schule abgewöhnt bzw. dafür gesorgt, dass wir uns das gar nicht erst angewöhnen. Stattdessen gruppiert man die Ziffern mit Abständen[1] in Dreiergruppen. Unsere Mathe- und Physiklehrer am Gymnasium waren immer sehr ungehalten, wenn jemand Punkte zum Gruppieren benutzte.

            Der Punkt anstelle eines Kommas als Dezimaltrennzeichen war dagegen damals in der Schule "geduldet", später in der FH sogar gern gesehen.

            beim Eingeben dürfte man die seltener erleben, oder macht ihr sowas???

            Also ich nicht, aber ich kann mir gut vorstellen, dass manche Leute das tun.

            So long,
             Martin

            --
            Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
            - Douglas Adams, The Hitchhiker's Guide To The Galaxy

            1. Abstand heißt bei Handschrift "ein kleiner Zwischenraum", bei Festbreitenschriften ein geschütztes Leerzeichen, bei Proportionalschriften vorzugsweise ein Leerzeichen halber Breite. ↩︎

            1. Hallo Martin,

              das „schlimmste“, was ich bisher gesehen habe, ist ein Funktionsgenerator, ein amerikanisches Gerät aus den '90ern. Das nimmt als Dezimalzeichen den Punkt und als Tausendertrenner das Komma, vor und hinter dem „.“. Wie oft die Studenten da an ihrer selbstgeschriebenen Messwerterfassungsoftware verzweifeln, weil die gemessene Frequenz um den Faktor tausend daneben liegt :). Das Nachfolgegerät ist in diesem Punkt konfigurierbar.

              Gruß
              Jürgen

              1. Hi,

                das „schlimmste“, was ich bisher gesehen habe, ist ein Funktionsgenerator, ein amerikanisches Gerät aus den '90ern. Das nimmt als Dezimalzeichen den Punkt und als Tausendertrenner das Komma, vor und hinter dem „.“.

                also ganz normal. ;-)

                Wie oft die Studenten da an ihrer selbstgeschriebenen Messwerterfassungsoftware verzweifeln, weil die gemessene Frequenz um den Faktor tausend daneben liegt :). Das Nachfolgegerät ist in diesem Punkt konfigurierbar.

                Da kenne ich noch eine schönere Anekdote (die aber nichts mit Dezimaltrennzeichen zu tun hat). Mein Onkel, Dozent an der FH Dortmund, hat mal einen Laborversuch in Messtechnik betreut, bei dem es unter anderem darum ging, die UBE/IC-Kennlinie eines Transistors aufzunehmen. Das Ergebnis eines Teams kam ihm seltsam vor, weil die Kennlinie bei den Kadetten einen Sprung aufwies und danach konstant verlief. Also hat er sich mit den Studis unterhalten und den Versuchsaufbau nochmal vorführen lassen.

                Ergebnis: Das Multimeter, das zur Messung des Kollektorstroms verwendet wurde, zeigte irgendwann nur noch "1" an (Overload). Also haben die Jungs 1A notiert. Vielleicht hätte man auch einfach nur den nächsthöheren Messbereich einstellen sollen ...

                So long,
                 Martin

                --
                Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
                - Douglas Adams, The Hitchhiker's Guide To The Galaxy
                1. Hallo Der Martin,

                  Ergebnis: Das Multimeter, das zur Messung des Kollektorstroms verwendet wurde, zeigte irgendwann nur noch "1" an (Overload). Also haben die Jungs 1A notiert. Vielleicht hätte man auch einfach nur den nächsthöheren Messbereich einstellen sollen ...

                  Mit einem analogen Messgerät wäre das möglicherweise nicht passiert.

                  Bis demnächst
                  Matthias

                  --
                  Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
                  1. Mit einem analogen Messgerät wäre das möglicherweise nicht passiert.

                    Dann hätten die statt "1A" eben "1R" notiert. Für "ein Rauch".

                    So endet das eben in Städten die einen direkten Zugverkehr nach Holland haben ...

                  2. n'Abend,

                    Ergebnis: Das Multimeter, das zur Messung des Kollektorstroms verwendet wurde, zeigte irgendwann nur noch "1" an (Overload). Also haben die Jungs 1A notiert. Vielleicht hätte man auch einfach nur den nächsthöheren Messbereich einstellen sollen ...

                    Mit einem analogen Messgerät wäre das möglicherweise nicht passiert.

                    aber vielleicht eine andere Panne.
                    Worauf ich hinaus will: Was auch immer man für technische Hilfsmittel verwendet, man sollte doch so viel Hintergrundwissen haben, dass man einschätzen kann, ob das Ergebnis plausibel ist - entweder anhand der Größenordnung der Ergebnisse, oder anhand der resultierenden Kurvenform, so wie hier.

                    Was die Studentengruppe hier gemacht hat, zeigt nur, dass sie strikt den Versuchsanweisungen gefolgt ist, ohne die leiseste Ahnung zu haben, was dahintersteckt.

                    So long,
                     Martin

                    --
                    Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
                    - Douglas Adams, The Hitchhiker's Guide To The Galaxy
                    1. Hallo Der Martin,

                      Worauf ich hinaus will: Was auch immer man für technische Hilfsmittel verwendet, man sollte doch so viel Hintergrundwissen haben, dass man einschätzen kann, ob das Ergebnis plausibel ist - entweder anhand der Größenordnung der Ergebnisse, oder anhand der resultierenden Kurvenform, so wie hier.

                      Ja, das ist auch genau das, was ich im Mathematikunterricht für äußerst wichtig halte: Die Kompetenz, ein Ergebnis auf Plausibilität einschätzen zu können.

                      Bis demnächst
                      Matthias

                      --
                      Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
                      1. Hallo Matthias,

                        Ja, das ist auch genau das, was ich im Mathematikunterricht für äußerst wichtig halte: Die Kompetenz, ein Ergebnis auf Plausibilität einschätzen zu können.

                        nur das meine Studierenden ihr Programm und nicht die Anzeige des Geräts mit Dezimalpunkt und Tausenderkomma hinterfragt haben.

                        Gruß
                        Jürgen

            2. @@Der Martin

              Stattdessen gruppiert man die Ziffern mit Abständen¹ in Dreiergruppen.
              ¹ Abstand heißt bei Handschrift "ein kleiner Zwischenraum", bei Festbreitenschriften ein geschütztes Leerzeichen,

              Erzähl das mal den Tippsen beim Tagesspiegel!

              bei Proportionalschriften vorzugsweise ein Leerzeichen halber Breite.

              Welches natürlich auch ein nicht umbrechendes sein sollte.

              Erzähl das mal Hixie, dass er die Entity dafür in HTML5 vergessen hat!

              LLAP 🖖

              --
              “There’s no such thing as an ‘average’ user, but there is such a thing as an average developer.” —Vitaly Friedman in Accessibility Matters: Meet Our New Book, “Inclusive Design Patterns”
              Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
          2. Tach!

            Tausenderpunkte benutzt man eher bei der Ausgabe zwecks Lesbarkeit, beim Eingeben dürfte man die seltener erleben, oder macht ihr sowas???

            Beim Eingeben per Hand vermutlich nicht, aber beim Eingeben per Copy und Paste wäre das nicht ungewöhnlich.

            (Bei IBAN-Würmern beispielsweise ist es ja auch nicht unüblich, dass die mit Leerzeichen zwischendrin ausgegeben wurden. Und wenn man dann per Hand die Leerzeichen rausfummeln muss, und außerdem noch, die fehlenden Ziffern nachtragen muss, weil das Eingabefeld zu kurz für den formatierten Wert war, bekommt der Programmierer kein Sternchen für sein System. Schließlich ist das lediglich ein einzelner Funktionsaufruf, die Leerzeichen für die interne Weiterverarbeitung zu entfernen.)

            dedlfix.

            1. IBAN-Würmern

              • Kreditkartenummern
              • ...

              Es gibt noch mehr solcher Beispiele. Alle haben gemeinsam, dass, wenn man einen Regex nutzt und also Leerzeichen erlaubt und also type=text setzt, gleich der Raoul kommt und wegen der Bildschirmtastatur entsetzt ist, welche dann einen Fingertipp mehr erfordert.

              1. Hallo Tester,

                IBAN-Würmern

                • Kreditkartenummern
                • ...

                Es gibt noch mehr solcher Beispiele.

                • Postleitzahlen
                • Telefonnummern

                Alle haben gemeinsam, dass, wenn man einen Regex nutzt und also Leerzeichen erlaubt und also type=text setzt, gleich der Raoul kommt und wegen der Bildschirmtastatur entsetzt ist, welche dann einen Fingertipp mehr erfordert.

                Allen gemeinsam ist, dass es keine Zahlen sind, also type=text korrekt ist.

                Kein Grund, abwertend zu werden.

                Bis demnächst
                Matthias

                --
                Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
              2. Es gibt noch mehr solcher Beispiele. Alle haben gemeinsam, dass, wenn man einen Regex nutzt und also Leerzeichen erlaubt und also type=text setzt, gleich der Raoul kommt und wegen der Bildschirmtastatur entsetzt ist, welche dann einen Fingertipp mehr erfordert.

                Es wäre mir lieb, du würdest bei der Sache bleiben und meine Person aus dem Spiel lassen. Was du hier versuchst nennt sich ein argumentum ad personam und gehört zu jenen Kommunikationspraktiken, die von dieser Community streng verurteilt werden. Ich werte es einfach mal Ausrutscher und werde es dir nicht nachtragen.

                Viele Dank & liebe Grüße, Raoul

          3. Tausenderpunkte benutzt man eher bei der Ausgabe zwecks Lesbarkeit, beim Eingeben dürfte man die seltener erleben, oder macht ihr sowas???

            Naja, wenn ich einen vorgegebenen Wert von Papier eintippe, stellt sich das Problem.

            Bei einer online-Überweisung etwa die IBAN. Wird eigentlich immer mit Leerstellen dargestellt, da reicht aber die Feldlänge nicht.

            Ich würde wohl auch den type "text" nehmen und nach dem Absenden - sowieso - eine Eingangsprüfung machen.

            Wenn es etwa darum geht, eine Reise zu buchen, wäre die Personenzahl 5.738,25 doch recht merkwürdig. Da könnte man noch mal nachfragen ;-)

            Linuchs

            1. @@Linuchs

              Bei einer online-Überweisung etwa die IBAN. Wird eigentlich immer mit Leerstellen dargestellt, da reicht aber die Feldlänge nicht.

              Dann ist das Formular fehlerhaft designt/implementiert.

              LLAP 🖖

              --
              “There’s no such thing as an ‘average’ user, but there is such a thing as an average developer.” —Vitaly Friedman in Accessibility Matters: Meet Our New Book, “Inclusive Design Patterns”
              Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
            2. Hallo

              Tausenderpunkte benutzt man eher bei der Ausgabe zwecks Lesbarkeit, beim Eingeben dürfte man die seltener erleben, oder macht ihr sowas???

              Naja, wenn ich einen vorgegebenen Wert von Papier eintippe, stellt sich das Problem.

              Tippst du da tatsächlich Leerzeichen mit ein?

              Um beim IBAN-Beispiel zu bleiben: Ich begrüße es ausdrücklich, wenn eine IBAN gruppiert (typischerweise in Vierergruppen) angezeigt wird. Das erhöht die Lesbarkeit auf und um ein Mehrfaches. Das Ablesen wird mir durch die Gruppierung vereinfacht, aber deshalb gebe ich die IBAN doch nicht mit den Leerstellen ein. Das wäre ja zusätzliche Arbeit.

              Bei einer online-Überweisung etwa die IBAN. Wird eigentlich immer mit Leerstellen dargestellt, da reicht aber die Feldlänge nicht.

              Das ist halt keine Zahl sondern Text. Das besprochene Problem der Zahlenformate tritt hier also nicht auf.

              Ich würde wohl auch den type "text" nehmen und nach dem Absenden - sowieso - eine Eingangsprüfung machen.

              Richtiges Formularfeldformat, richtige Vorgehensweise bei der Verarbeitung.

              Wenn es etwa darum geht, eine Reise zu buchen, wäre die Personenzahl 5.738,25 doch recht merkwürdig.

              Das ist eine Zahl, also sowohl die gezeigte Zahl als auch die zu erwartende Eingabe, wobei diese ohne Nachkommastellen daherkommen sollte. Da kann man, abgesehen von deinem einen Scherz mit der untypisch hohen Anzahl von Reisenden zur Vermeidung von Fehleingaben (Fließkommazahl) schon im Browser entsprechend reagieren.

              Da könnte man noch mal nachfragen ;-)

              Da verweigert man der Einfachheit halber die Weiterverarbeitung. Abgesehen von Organ- und Leichentransporten kann man im legalen Bereich Transporte – im wahrsten Sinne des Wortes – teilweiser Personen [1] wohl eher ausschließen.

              Tschö, Auge

              --
              Wo wir Mängel selbst aufdecken, kann sich kein Gegner einnisten.
              Wolfgang Schneidewind *prust*

              1. Nein, eine Person mit amputierten Körperteilen ist keine teilweise Person. ↩︎

              1. @@Auge

                Ich begrüße es ausdrücklich, wenn eine IBAN gruppiert (typischerweise in Vierergruppen) angezeigt wird. Das erhöht die Lesbarkeit auf und um ein Mehrfaches. Das Ablesen wird mir durch die Gruppierung vereinfacht, aber deshalb gebe ich die IBAN doch nicht mit den Leerstellen ein.

                Ich tue das, um auch meine Eingabe kontrollieren zu können.

                LLAP 🖖

                --
                “There’s no such thing as an ‘average’ user, but there is such a thing as an average developer.” —Vitaly Friedman in Accessibility Matters: Meet Our New Book, “Inclusive Design Patterns”
                Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
                1. Tach!

                  Das Ablesen wird mir durch die Gruppierung vereinfacht, aber deshalb gebe ich die IBAN doch nicht mit den Leerstellen ein.

                  Ich tue das, um auch meine Eingabe kontrollieren zu können.

                  Brauchst du im Prinzip nicht, die IBAN hat doch zwei eingebaute Prüfziffern. Die sollte das System überprüfen können.

                  dedlfix.

                  1. @@dedlfix

                    Brauchst du im Prinzip nicht, die IBAN hat doch zwei eingebaute Prüfziffern. Die sollte das System überprüfen können.

                    Klar, aber erst am Ende. Wenn’s dann nicht stimmt, muss ich die ganze IBAN noch mal eingeben. Ich hab gern bei der Eingabe schon die Übersichtlichkeit.

                    LLAP 🖖

                    --
                    “There’s no such thing as an ‘average’ user, but there is such a thing as an average developer.” —Vitaly Friedman in Accessibility Matters: Meet Our New Book, “Inclusive Design Patterns”
                    Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
              2. Hallo Auge,

                Um beim IBAN-Beispiel zu bleiben: Ich begrüße es ausdrücklich, wenn eine IBAN gruppiert (typischerweise in Vierergruppen) angezeigt wird. Das erhöht die Lesbarkeit auf und um ein Mehrfaches. Das Ablesen wird mir durch die Gruppierung vereinfacht

                Vor allem bei den durchaus nicht unüblichen Häufungen von Nullen, weil die ursprüngliche Kontonummer deutlich weniger Stellen als 10 aufweist.

                Bis demnächst
                Matthias

                --
                Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
                1. @@Matthias Apsel

                  Um beim IBAN-Beispiel zu bleiben: Ich begrüße es ausdrücklich, wenn eine IBAN gruppiert (typischerweise in Vierergruppen) angezeigt wird. Das erhöht die Lesbarkeit auf und um ein Mehrfaches. Das Ablesen wird mir durch die Gruppierung vereinfacht

                  Vor allem bei den durchaus nicht unüblichen Häufungen von Nullen, weil die ursprüngliche Kontonummer deutlich weniger Stellen als 10 aufweist.

                  Oder die BLZ eine Sequenz von Nullen enthält. (Bps. Berliner Sparkasse: 10050000 – hier absichtlich ohne Leerzeichen)

                  LLAP 🖖

                  --
                  “There’s no such thing as an ‘average’ user, but there is such a thing as an average developer.” —Vitaly Friedman in Accessibility Matters: Meet Our New Book, “Inclusive Design Patterns”
                  Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
                  1. Tach!

                    Vor allem bei den durchaus nicht unüblichen Häufungen von Nullen, weil die ursprüngliche Kontonummer deutlich weniger Stellen als 10 aufweist.

                    Oder die BLZ eine Sequenz von Nullen enthält. (Bps. Berliner Sparkasse: 10050000 – hier absichtlich ohne Leerzeichen)

                    So viele Nullen ... leider nicht vor dem Komma, sondern nur in der IBAN.

                    dedlfix.

                  2. Hallo

                    Vor allem bei den durchaus nicht unüblichen Häufungen von Nullen, weil die ursprüngliche Kontonummer deutlich weniger Stellen als 10 aufweist.

                    Oder die BLZ eine Sequenz von Nullen enthält. (Bps. Berliner Sparkasse: 10050000 – hier absichtlich ohne Leerzeichen)

                    Zehnmillionenfünfzigtausend. So weit, so einfach. Wenn sich daran aber eine mit Nullen aufgefüllte Kontonummer anschließt, geht der Nullen Zählung los. :-)

                    Bei mir aber dennoch nur beim lesen. Zumindest, wenn ich mich auf die Tastatur verlassen kann.

                    Tschö, Auge

                    --
                    Wo wir Mängel selbst aufdecken, kann sich kein Gegner einnisten.
                    Wolfgang Schneidewind *prust*
                    1. Hallo,

                      Bps. Berliner Sparkasse: 10050000

                      Zehnmillionenfünfzigtausend.

                      Wie jetzt, wir hatten uns doch darauf geeinigt, dass es eben keine Zahl ist.
                      Also: Hundert-Fünfhundert-WC ;)

                      Gruß
                      Kalk

                      1. Hallo

                        Bps. Berliner Sparkasse: 10050000

                        Zehnmillionenfünfzigtausend.

                        Wie jetzt, wir hatten uns doch darauf geeinigt, dass es eben keine Zahl ist.
                        Also: Hundert-Fünfhundert-WC ;)

                        Und ich dachte, es handele sich um ein Wort. Ein Zahlwort zwar, aber doch ein Wort. :-)

                        Tschö, Auge

                        --
                        Wo wir Mängel selbst aufdecken, kann sich kein Gegner einnisten.
                        Wolfgang Schneidewind *prust*
                        1. Hallo,

                          Und ich dachte, es handele sich um ein Wort. Ein Zahlwort zwar, aber doch ein Wort. :-)

                          Isses doch?! Mit Bindestrichen zu einem durchgekoppelten Wort verbunden.

                          Gruß
                          Kalk

      2. @@Tester

        Im Firefox kannst du das lang-Attribut auf dem input-Element setzen,

        oder gleich für das Dokument ...

        Ja. Und nicht bloß „kannst“, sondern „solltest“. Aus Gründen.

        <html lang="de_DE">

        Das allerdings widerspricht dem Standard. BCP 47/RFC 5646 §2.1 schreibt - als Trennzeichen zwischen den Subtags vor. Also de-DE.

        Allerdings wäre das überspezifiziert; Sprachkennzeichnungen sollten so kurz wie möglich sein. Es gibt kaum einen sinnvollen Grund, zwischen de-DE und in anderen Regionen geschriebenem Deutsch zu unterscheiden. Außer vielleicht de-CH, wo kein ß verwendet wird.

        Die Angabe sollte <html lang="de"> lauten.

        LLAP 🖖

        --
        “There’s no such thing as an ‘average’ user, but there is such a thing as an average developer.” —Vitaly Friedman in Accessibility Matters: Meet Our New Book, “Inclusive Design Patterns”
        Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
    2. Hallo,

      Nun möchte ich aber sowohl das Dezimalkomma als auch den Dezimalpunkt zulassen.

      Das würde ich lassen, damit arbeitest du entgegen dem Standardverhalten der Browser und damit entgegen der Erwartungen des Nutzers.

      ich will ja beides zulassen. Der user kann eingeben, was er will. Das Standardverhalten der Browser wird auf jeden Fall unterstützt.

      Ich gebe aber zu, dass die Formular-Lokalisierung der Browser viele Wünsche offen lässt. Du könntest den Eingabetypen zurück auf text setzen und die gültigen Zahlen mit einem regulären Ausdruck und dem pattern-Attribut validieren.

      Das mache ich ja schon, nur nicht mit rattern, sondern per Javascript in der Einleseroutine.

      Aber dann geht die semantische Information verloren, dass eine Zahl erwartet wird. Eine Folge ist, dass Smartphones keine spezifischen virtuellen Tastaturen einblenden. Damit schränkst du die Bedienbarkeit und Zugänglichkeit nur weiter ein.

      Aus genau diesem Grund habe ich eine Routine, die ich seit fast 10 Jahren verwende, in Zweifel gezogen und auf type=number umgestellt.

      Im Firefox kannst du das lang-Attribut auf dem input-Element setzen, dann verwendet FF eine Zahlendarstellung, die für die angegebene Sprache hinterlegt ist. Chrome ignoriert das Attribut und benutzt scheinbar immer das Zahlenformat, das für die im Browser eingestellte Defaultsprache hinterlegt ist. Edge und Safari habe ich nicht ausprobiert.

      aber das hilft mir nicht weiter. Es soll ja beides gehen.

      Im Prinzip ist ja type=number das Mittel der Wahl, wenn nicht falsche Eingaben als NaN oder Leerstring ausgelesen würden.

      Gruß
      Jürgen

      1. Hi,

        Das mache ich ja schon, nur nicht mit rattern, sondern per Javascript in der Einleseroutine.

        hihi, rattern ist gut. ;-)

        So long,
         Martin

        --
        Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
        - Douglas Adams, The Hitchhiker's Guide To The Galaxy
        1. Hallo Martin

          Das mache ich ja schon, nur nicht mit rattern, sondern per Javascript in der Einleseroutine.

          hihi, rattern ist gut. ;-)

          früher gab es Bücher über lustige Rechtschreibfehler, heute könnte man die automatische Rechtschreibkorrektur als Thema nahmen :)

          Ich meinte natürlich pattern.

          Gruß
          Jürgen

          1. Hi,

            Das mache ich ja schon, nur nicht mit rattern, sondern per Javascript in der Einleseroutine.

            hihi, rattern ist gut. ;-)

            früher gab es Bücher über lustige Rechtschreibfehler, heute könnte man die automatische Rechtschreibkorrektur als Thema nahmen :)

            ja, ich weiß. Ich hab vor Jahren mal ein Benutzerhandbuch, das ich zum Korrekturlesen bekommen hatte, aus Spaß der Rechtschreibprüfung von Word 97 zum Fraß vorgeworfen. Ich habe nur noch zwei Begriffe im Gedächtnis, die im Text häufig vorkamen und bei denen ich den Korrekturvorschlag von Word besonders originell fand:

            • "D-Sub-Steckverbinder" wurde zu "D-Zug-Steckverbinder"
            • "schraubbar" wurde zu "Schrubber" korrigiert

            Ich meinte natürlich pattern.

            Schon klar. :-)

            Ciao,
             Martin

            --
            Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
            - Douglas Adams, The Hitchhiker's Guide To The Galaxy
        2. Hi,

          Das mache ich ja schon, nur nicht mit rattern, sondern per Javascript in der Einleseroutine.

          hihi, rattern ist gut. ;-)

          Das sind Pattern aus Rattan ;-)

          cu,
          Andreas a/k/a MudGuard

      2. Hallo,

        Im Firefox kannst du das lang-Attribut auf dem input-Element setzen, dann verwendet FF eine Zahlendarstellung, die für die angegebene Sprache hinterlegt ist. Chrome ignoriert das Attribut und benutzt scheinbar immer das Zahlenformat, das für die im Browser eingestellte Defaultsprache hinterlegt ist. Edge und Safari habe ich nicht ausprobiert.

        aber das hilft mir nicht weiter. Es soll ja beides gehen.

        ich habe bei den Inputs jetzt mal lang="en" gesetzt, das Dokument hat lang="de". Jetzt werden Zahlen mit Dezimalpunkt und -komma akzeptiert. Siehe Test FktPlot. Getestet unter MacOs mit Safari und FF, unter Windows mit Edge, FF und Chrome.

        Gruß
        Jürgen

  3. Hallo,

    euch allen schon mal vielen Dank für die Antworten und Tipps.

    Leider habe ich noch ein Problem entdeckt. Ohne step kennt type=number nur ganze Zahlen. Wenn ich jetzt als step z.B. 0.01 wähle, ist 0.011 keine gültige Zahlt mehr. Gut, ich könnte jetzt als step 1e-15 der noch kleiner wählen, aber dann werden die Incrementschritte unsinnig klein.

    Ich habe immer mehr das Gefühl, für beliebige Zahlen, egal ob mit „.“ oder „,“ ist type=number nicht geeignet. Oder ich habe hoffentlich noch etwas grundlegendes übersehen.

    Gruß
    Jürgen

    1. Leider habe ich noch ein Problem entdeckt. Ohne step kennt type=number nur ganze Zahlen. Wenn ich jetzt als step z.B. 0.01 wähle, ist 0.011 keine gültige Zahlt mehr. Gut, ich könnte jetzt als step 1e-15 der noch kleiner wählen, aber dann werden die Incrementschritte unsinnig klein.

      Dann könnte step="any" Dein Freund sein. Übrigens gibt es auch min und max.

      1. Hallo,

        Leider habe ich noch ein Problem entdeckt. Ohne step kennt type=number nur ganze Zahlen. Wenn ich jetzt als step z.B. 0.01 wähle, ist 0.011 keine gültige Zahlt mehr. Gut, ich könnte jetzt als step 1e-15 der noch kleiner wählen, aber dann werden die Incrementschritte unsinnig klein.

        Dann könnte step="any" Dein Freund sein.

        das kannte ich noch nicht, danke. Jetzt wird zwar in Einerschritten auf ganze Zahlen in- und decrementiert, aber es ist jede Zahl erlaubt.

        Übrigens gibt es auch min und max.

        Die kenne ich schon, kann Sie aber nicht verwenden, da beliebige Zahlen erlaubt sind. Nur die eine muss kleiner als die andere sein, aber das regle ich schon per Javascript.

        Gruß
        Jürgen