Native HTML-Formularvalidierung: required, pattern, type und die Constraint Validation API

Worum es geht

HTML prüft Formularfelder vor dem Absenden eines Formulars, ganz ohne Skript. required, minlength und maxlength, min, max und step, pattern sowie die Eingabetypen email, url, number und date deklarieren jeweils eine Bedingung. Verletzt ein Feld eine davon, verweigert der Browser das Absenden und zeigt am ersten ungültigen Feld seine eigene Meldung. Der MDN-Leitfaden beschreibt die CSS-Seite: Ein ungültiges Feld erfüllt :invalid, und sobald der Nutzer damit interagiert hat, zusätzlich :user-invalid. Die Constraint Validation API (checkValidity(), reportValidity(), setCustomValidity(), das validity-Objekt) macht denselben Zustand für Skripte zugänglich; novalidate am Formular schaltet die Sprechblasen des Browsers ab, die API bleibt aber funktionsfähig.

Warum es wichtig ist

Native Validierung funktioniert, bevor überhaupt JavaScript eingetroffen, ausgeführt oder fehlgeschlagen ist; ihre Meldungen erscheinen in der Sprache des Browsers ohne eigenen Übersetzungsaufwand; und die Bedingungen existieren nur einmal, im Markup, wo Skripte, Tests und Crawler sie lesen können. Eine Sicherheitsmassnahme ist sie nicht: Der MDN-Leitfaden stellt ausdrücklich klar, dass der Server jede Übermittlung unabhängig davon validieren muss.

So wird es angewendet

• Zuerst den type wählen: email, url und number bringen eigene Bedingungen und eine eigene Tastatur mit. Für Freitext, der nur eine numerische Tastatur braucht, inputmode verwenden.
• required, minlength, min/max und pattern für Formatregeln ergänzen. Das Pattern wird als regulärer JavaScript-Ausdruck kompiliert und muss auf den gesamten Wert passen. Das erwartete Format sowohl sichtbar als Text als auch in einem title-Attribut beschreiben; die zitierte Seite merkt an, dass Browser den Titel in der Validierungsmeldung verwenden können.
• :user-invalid statt :invalid stylen, damit leere Pflichtfelder nicht schon rot markiert sind, bevor der Nutzer sie berührt hat.
• setCustomValidity() für feldübergreifende Regeln wie eine Passwortbestätigung verwenden und mit einem leeren String zurücksetzen, sonst bleibt das Feld ungültig.
• Wird unter novalidate eine eigene Fehlerliste gerendert, trotzdem reportValidity() aufrufen, damit Tastatur- und Screenreader-Nutzer zum ersten Fehler geführt werden.
• Den Serverpfad testen, indem mit novalidate oder mit curl abgesendet wird; die Prüfungen des Browsers sind eine Höflichkeit, kein Vertrag.

Stolpersteine

Native Fehler-Sprechblasen lassen sich nicht stylen, verschwinden bei Fokuswechsel und zeigen jeweils nur einen Fehler. Ein pattern an type="email" kombiniert sich mit der eingebauten Prüfung, sodass beide bestehen müssen. Deaktivierte Felder werden nie validiert. Ein mit display: none verstecktes Pflichtfeld blockiert das Absenden weiterhin, doch der Browser hat keine Stelle, um die Meldung anzuzeigen, was verbreitet als «Formular tut nichts»-Fehler gemeldet wird. Datums- und Zahlenfelder rendern gebietsschema-abhängige Widgets, die sich kaum umstylen lassen.