NetAktiv
Senior HTML'ler
Hallo,
nachdem ich vor ein paar Wochen begann, mich ein wenig mit den neuen type-Definitionen bei <input> Feldern unter HTML 5 auseinander zu setzen, da war die Euphorie anfangs doch recht groß. Ich dachte, da ist etwas Tolles ausgedacht und umgesetzt worden und die meisten dieser üblichen Javascript Validierungsfunktionen kann man nun endlich in die Tonne hauen und muss sie nicht weiter pflegen. Nun kamen die ersten praktischen Erfahrungen, und die waren alles andere als befriedigend. Daher will ich die hier einfach mal wiedergeben.
Probleme type=<alle>: Meldungen bei Fehlern bei der Eingabe erzeugt der Browser und die können ja insbesondere bei der Nutzung des pattern-Attributes nicht sonderlich benutzerfreundlich sein. So Sprüche wie Ihre Eingabe muss dem geforderten Format entsprechen helfen aber selten. Leider kann man diese Meldungen aber nicht durch ein neues Attribut als Entwickler selbst bestimmen. Will man das, dann bleibt wieder nur die eigene Validierung mit JavaScript.
Probleme type=<diverse>: Die Implementierung unterscheidet sich derzeit zwischen den Browsern drastisch, wobei Chrome meines Erachtens etwas vor Firefox und meilenweit for IE und Edge liegt. Wir gehen also zurück in der Zeit und müssen eventuell Browser spezifischen Erweiterungscode schreiben. Besonders deutlich sind die Unterschiede bei type=color, wo Chrome sogar einen Picker anbietet.
Probleme type=url: Der erste Test zeigte, dass (zumindest im Chrome) eine url mit http:// beginnen muss. Sichere Verbindungen https:// sind nicht zugelassen. Also noch das Pattern-Attribut anpassen und beide Protokolle zulassen. Test auf meinem Tablett und wieder klappt es nicht, weil das standardmäßig den ersten Buchstaben groß macht, also Http:// wird nicht angenommen. Wieder rumsuchen ergab Lösungen über JavaScript oder das Feld mittels CSS und transform:lowercase zu formatieren. CSS hat wieder Nachteile, denn wenn ich meine URL etwa so eingeben will aXa, dann wird alles klein. Damit kann man meines Erachtens zwar gerade noch leben, aber mit CSS war nicht nur die Eingabe, sondern auch Hinweis-Text aus dem Attribut placeholder ohne Großbuchstaben, und das gefiel mir dann nicht mehr. Als mich dann noch eine Bekannte informierte, dass mein Fomular ihre Internetadresse www.domain.de nicht akzeptiere, die sie immer im Browser eingebe, war es endgültig aus mit der JavaScript freien Zeit. Beim onchange-Event wandle ich eventuelles HTTP in Kleinbuchstaben um und wenn es fehlt, ergänze ich http://.
Probleme type=<number>: Bei Chrome wird hier eine Liste zum Scrollen zur entsprechenden Zahl angeboten, die man nicht abstellen kann. Bei mir ist der Captcha Code eine 6-stellige Zahl zwischen 100.000 und 999.999, also sicher vom Typ number. Aber das Scrollrad (oder wie man das Ding auch immer nennt) bei type=number ist hier völlig ungeeignet, also doch wieder type=text und pattern nehmen.
Eventuell hat je jemand Beziehungen zu w3c oder den Browser-Entwicklern und gibt diese Anregungen bzw. Probleme weiter.
Aus meiner Sicht gilt bisher die folgende Zusammenfassung:
Guter und richtiger Ansatz , aber massive Lücken oder Fehler in der Umsetzung.
nachdem ich vor ein paar Wochen begann, mich ein wenig mit den neuen type-Definitionen bei <input> Feldern unter HTML 5 auseinander zu setzen, da war die Euphorie anfangs doch recht groß. Ich dachte, da ist etwas Tolles ausgedacht und umgesetzt worden und die meisten dieser üblichen Javascript Validierungsfunktionen kann man nun endlich in die Tonne hauen und muss sie nicht weiter pflegen. Nun kamen die ersten praktischen Erfahrungen, und die waren alles andere als befriedigend. Daher will ich die hier einfach mal wiedergeben.
Probleme type=<alle>: Meldungen bei Fehlern bei der Eingabe erzeugt der Browser und die können ja insbesondere bei der Nutzung des pattern-Attributes nicht sonderlich benutzerfreundlich sein. So Sprüche wie Ihre Eingabe muss dem geforderten Format entsprechen helfen aber selten. Leider kann man diese Meldungen aber nicht durch ein neues Attribut als Entwickler selbst bestimmen. Will man das, dann bleibt wieder nur die eigene Validierung mit JavaScript.
Probleme type=<diverse>: Die Implementierung unterscheidet sich derzeit zwischen den Browsern drastisch, wobei Chrome meines Erachtens etwas vor Firefox und meilenweit for IE und Edge liegt. Wir gehen also zurück in der Zeit und müssen eventuell Browser spezifischen Erweiterungscode schreiben. Besonders deutlich sind die Unterschiede bei type=color, wo Chrome sogar einen Picker anbietet.
Probleme type=url: Der erste Test zeigte, dass (zumindest im Chrome) eine url mit http:// beginnen muss. Sichere Verbindungen https:// sind nicht zugelassen. Also noch das Pattern-Attribut anpassen und beide Protokolle zulassen. Test auf meinem Tablett und wieder klappt es nicht, weil das standardmäßig den ersten Buchstaben groß macht, also Http:// wird nicht angenommen. Wieder rumsuchen ergab Lösungen über JavaScript oder das Feld mittels CSS und transform:lowercase zu formatieren. CSS hat wieder Nachteile, denn wenn ich meine URL etwa so eingeben will aXa, dann wird alles klein. Damit kann man meines Erachtens zwar gerade noch leben, aber mit CSS war nicht nur die Eingabe, sondern auch Hinweis-Text aus dem Attribut placeholder ohne Großbuchstaben, und das gefiel mir dann nicht mehr. Als mich dann noch eine Bekannte informierte, dass mein Fomular ihre Internetadresse www.domain.de nicht akzeptiere, die sie immer im Browser eingebe, war es endgültig aus mit der JavaScript freien Zeit. Beim onchange-Event wandle ich eventuelles HTTP in Kleinbuchstaben um und wenn es fehlt, ergänze ich http://.
Probleme type=<number>: Bei Chrome wird hier eine Liste zum Scrollen zur entsprechenden Zahl angeboten, die man nicht abstellen kann. Bei mir ist der Captcha Code eine 6-stellige Zahl zwischen 100.000 und 999.999, also sicher vom Typ number. Aber das Scrollrad (oder wie man das Ding auch immer nennt) bei type=number ist hier völlig ungeeignet, also doch wieder type=text und pattern nehmen.
Eventuell hat je jemand Beziehungen zu w3c oder den Browser-Entwicklern und gibt diese Anregungen bzw. Probleme weiter.
Aus meiner Sicht gilt bisher die folgende Zusammenfassung:
Guter und richtiger Ansatz , aber massive Lücken oder Fehler in der Umsetzung.