Formulare mit nativen HTML-Constraints erzeugen pro Absendung weniger serverseitige Validierungsablehnungen als Formulare, die nur per eigenem JavaScript validiert werden

Hypothese

Serverseitige Validierung ist zwingend; die clientseitige Validierung existiert, damit die meisten Absendungen sie nie auslösen. Es gibt zwei Wege, die Client-Seite bereitzustellen: native Constraint-Attribute an den Feldern (required, type, pattern, min, max, maxlength), die der Browser vor einer interaktiven Absendung prüft, oder eigenes Skript, das Werte inspiziert und das submit-Ereignis blockiert. MDNs Leitfaden zur Constraint Validation beschreibt den nativen Mechanismus und seine Randfälle: Ein novalidate-Attribut am Formular schaltet die interaktive Validierung ab, und ein Aufruf der submit()-Methode des Formulars sendet die Formulardaten an den Server, auch wenn sie die Constraints nicht erfüllen. Ein verbreitetes Muster ist eigene Validierung für Styling und Meldungen, wobei die nativen Attribute dabei unter den Tisch fallen. Die Hypothese lautet, dass Formulare, deren native Attribute die Serverregeln spiegeln, pro Absendung weniger serverseitige Ablehnungen erzeugen als Formulare, die nur per Skript geprüft werden, und dass der Unterschied vor allem aus Sitzungen stammt, in denen das Skript nicht lief: Es lud nicht, warf einen Fehler, bevor es seine Handler anhängte, oder erfasste Autofill- und Einfügepfade nicht.

Vorhersage

In einem A/B-Vergleich desselben Formulars mit und ohne native Constraint-Attribute, wobei beide Varianten dasselbe eigene Skript und dieselben Serverregeln behalten, zeigt die Variante mit nativen Attributen eine niedrigere Rate serverseitiger Validierungsablehnungen pro Absendung. Der Unterschied konzentriert sich auf Sitzungen mit einem Skriptfehler oder ohne die Bereitschaftsmarkierung des Skripts und liegt nahe null, wo das Skript lief; die schrumpfenden Ablehnungskategorien sind jene, die native Attribute ausdrücken können (fehlende Pflichtfelder, fehlerhafte E-Mail-Adressen, Zahlen ausserhalb des Bereichs), nicht feldübergreifende Regeln. Sind die Ablehnungsraten gleich, oder konzentriert sich der Unterschied nicht auf Sitzungen mit Skriptfehlern, ist die Hypothese falsch.

Vorgeschlagener Test

1. Ein öffentliches Formular mit einigen tausend Absendungen im Monat wählen, dessen Server strukturierte Validierungsfehler pro Feld zurückgibt.
2. Variante A mit nativen Attributen bauen, die den Serverregeln Feld für Feld entsprechen, und Variante B mit entfernten Attributen; Skript, Layout und Meldungen identisch halten. Besucher per stabilem Hash zuweisen.
3. Ein verstecktes Feld ergänzen, das das Skript setzt, sobald seine Handler angehängt sind, damit der Server erkennen kann, ob das Skript lief; Skriptfehler zusammen mit der Variante protokollieren.
4. Vier Wochen lang pro Absendung erfassen: Variante, Skript-lief-Markierung, Ablehnung (ja oder nein) und die abgelehnten Felder mit ihren Regelkategorien.
5. Ablehnungsraten pro Variante insgesamt und nach Markierung aufgeteilt vergleichen und mit Anzahl und Intervallen statt einer einzelnen Zahl berichten; die abweichenden Regelkategorien auflisten.

Status

Es wird kein Ergebnis behauptet. Ist das Skript zuverlässig und scheitert es beim Publikum selten am Laufen, kann der Unterschied in vier Wochen zu klein sein, um ihn zu messen; dieses Ergebnis würde selbst zeigen, wie viel die native Ebene für dieses Publikum beiträgt.