Formular zurücksetzen: Anfangswerte, leere Felder oder letzte gespeicherte Fassung?
Ein Knopf „Zurücksetzen“ ist ohne weitere Erklärung mehrdeutig. Soll er alle Felder leeren, die beim Öffnen angezeigten Werte wiederherstellen oder eine bereits gespeicherte Änderung rückgängig machen? Legen Sie die gewünschte Wirkung fest, bevor ein solcher Knopf in Ihre Web-App kommt.
Die native HTML-Funktion zum Zurücksetzen eines Formulars ist kein allgemeiner Rückgängig-Befehl für Geschäftsprozesse. Sie arbeitet mit dem Zustand der Formularelemente im Dokument, nicht mit einer automatisch neu geladenen maßgeblichen Fassung aus Ihrer Datenbank.
Anfangswerte sind nicht zwangsläufig leere Werte
In einem fiktiven Kundenportal öffnet jemand eine bestehende Anfrage. Kontaktart und Beschreibung sind bereits ausgefüllt. Nach mehreren Änderungen entscheidet die Person, diese Eingaben nicht zu übernehmen.
Der WHATWG-Standard zum Zurücksetzen von Formularen ruft die jeweiligen Rücksetzalgorithmen der zugehörigen rücksetzbaren Elemente auf. Die Beschreibung für input-Elemente setzt den Wert auf das value-Inhaltsattribut zurück, soweit vorhanden, andernfalls auf eine leere Zeichenfolge. Danach können die jeweiligen Bereinigungsregeln des Eingabetyps wirken.
Die praktische Konsequenz: Ein vorausgefülltes Formular wird nicht allein deshalb leer, weil der Knopf „Zurücksetzen“ heißt. Andere Elemente und eigene Komponenten müssen ebenfalls nach ihren tatsächlich implementierten Regeln geprüft werden. Eine einzige Textzeile ist keine ausreichende Vorführung.
Wählen Sie deshalb eine eindeutige Bezeichnung für die vereinbarte Wirkung, etwa „Änderungen seit dem Öffnen verwerfen“. Verwenden Sie diese Formulierung aber nur, wenn die Implementierung genau diesen Bezugspunkt erhält.
Die letzte gespeicherte Fassung kann inzwischen eine andere sein
Während das Formular geöffnet ist, könnte ein Kollege den gemeinsamen Datensatz ändern. Die Anfangswerte in der geöffneten Seite sind dann nicht zwingend die neuesten gespeicherten Werte.
Meine Empfehlung: Unterscheiden Sie das lokale Verwerfen von Eingaben vom erneuten Laden des aktuellen Datensatzes. Wenn Sie beide Funktionen benötigen, erklären Sie den Unterschied. Ein erneutes Laden muss außerdem dem vereinbarten Umgang mit gleichzeitigen Änderungen folgen; es darf nicht unbemerkt fremde Arbeit überschreiben.
Ebenso wenig kann ein lokaler Reset eine bereits ausgelöste Zahlung, Nachricht oder bestätigte Speicherung zurücknehmen. Dafür braucht die Anwendung einen eigenen fachlichen Korrektur- oder Stornierungsablauf. Beschriften Sie den Knopf nicht so, als könnte er solche externen Wirkungen widerrufen.
Dateien und Auswahlzustände mitdenken
Die input-Referenz beschreibt beim Zurücksetzen auch die Wiederherstellung des Ausgangszustands für Auswahlmarkierungen und das Leeren der Liste ausgewählter Dateien. Das kann für eine Person überraschend sein, die ein Dokument schon ausgewählt, aber noch nicht gesendet hat.
Klären Sie, welche Eingaben gemeinsam verworfen werden. Dazu gehören gegebenenfalls dynamisch hinzugefügte Zeilen, Vorschauen, lokale Berechnungsergebnisse und eigene Auswahlkomponenten. Die native Funktion beantwortet nicht automatisch, wie Ihre individuell gebaute Oberfläche sämtliche zusätzlichen Zustände behandelt.
Ein bereits hochgeladenes Dokument ist wiederum eine andere Sache als eine lokale Dateiauswahl. Entscheiden Sie ausdrücklich, ob eine separate hochgeladene Entwurfsdatei bestehen bleibt oder über einen eigenen autorisierten Ablauf entfernt wird. Ein geleertes Auswahlfeld belegt keine Löschung auf dem Server.
Anzeigen müssen nach dem Reset wieder zum Formular passen
Der WHATWG-Abschnitt erläutert, dass die durch Rücksetzalgorithmen verursachten Änderungen nicht als Benutzereingaben gelten und beispielsweise keine input-Ereignisse auslösen.
Wenn Ihre App einen Zeichenzähler, eine Vorschau oder eine Zusammenfassung nur anhand solcher Eingabeereignisse aktualisiert, muss die Entwicklung die Rücksetzung gesondert berücksichtigen. Andernfalls kann ein Feld bereits seinen Anfangswert zeigen, während daneben noch eine alte Zusammenfassung steht.
Das ist ein konkreter Abnahmepunkt, keine Behauptung, jede bestehende App habe diesen Fehler. Prüfen Sie die fertige Umsetzung statt aus dem Vorhandensein eines Ereignishandlers auf ein korrektes Ergebnis zu schließen.
Erst entscheiden, ob der Knopf überhaupt nötig ist
Für ein kurzes Kundenformular kann eine großflächige Verwerfungsfunktion mehr Risiko als Nutzen bringen. Meine Empfehlung: Nehmen Sie sie nur auf, wenn die tatsächliche Aufgabe davon profitiert. Halten Sie sie von der Hauptaktion unterscheidbar und erklären Sie folgenreiche Verluste vor deren Auslösung.
Vereinbaren Sie in den Abnahmekriterien ein vorausgefülltes und ein neues Formular. Ändern Sie Text, Auswahl, Dateiauswahl und eine eigene Komponente. Prüfen Sie danach sämtliche Werte, Zähler und Zusammenfassungen sowie den unveränderten gespeicherten Datensatz, falls nur lokale Änderungen verworfen werden sollen.
Testen Sie anschließend eine bereits gespeicherte Änderung: Der Reset darf nicht als Rücknahme ausgegeben werden, wenn er das nicht leistet. Nutzen Sie erfundene Datensätze und führen Sie keine echten Nachrichten oder Zahlungen aus.
Bringen Sie zum Gespräch über Ihr Formular einen Satz mit: „Diese Aktion stellt genau diesen Zustand wieder her.“ Wenn der Bezugspunkt klar ist, lassen sich Bezeichnung, Umsetzung und Abnahme daran ausrichten.
Quellen und Grenzen
Die am 26. Oktober 2026 gelesenen WHATWG-Abschnitte belegen den Formularreset, ausbleibende input-Ereignisse und den Rücksetzalgorithmus für input einschließlich Auswahlzuständen und Dateien. Konfliktbehandlung, Beschriftung, Serverdateien und Abnahme sind Projektanforderungen. Ein praktischer Formular- oder Löschtest wird hier nicht behauptet.