input oder button für submit-Elemente?

[Matthias Apsel]

Om nah hoo pez nyeetz, alle!

Es wurde schon gelegtlich darüber diskutiert (2014, 2104, 2013, …). Ich habe mir erlaubt, einen Blog-Artikel darüber zu verfassen.

http://blog.selfhtml.org/2015/02/09/input-oder-button-fuer-submit-elemente/

Matthias

[1UnitedPower]

Hakuna matata!

Ich habe mir erlaubt, einen Blog-Artikel darüber zu verfassen.

Prägnant auf den Punkt gebracht.

Deine Argumentation für die <input>-Buttons, wenn mehrere Submit-Buttons im Spiel sind, finde ich interessant. Dazu möchte ich gern meine abweichende Meinung erläutern, denn aus meiner Sicht reduzierst du das Semantik-Argument zu sehr auf die Tagnamen der Elemente: <input> stehe für Benutzereingaben, <button> stehe für Aktionen.

Der generische Begriff "Benutzereingabe" wird im Standard als Submittable Elements formalisiert. Das sind Elemente, die beim Abschicken eines Formulars Schlüssel/Werte-Paare zu den Formulardaten beitragen. In dieser Kategorie tummeln sich neben dem <input>-Element auch die Artverwandten <textarea>, <select> und eben auch der <button>. Die Kategorie verleiht den beinhalteten Elementen also eine Semantik, die über die reinen Tagnamen hinausgeht.

Dein Argument zielt eigentlich weniger auf die Semantik der Elemente, sondern mehr auf deren Expressivität ab. So betrachtet kann ich deinen Punkt auch sehr gut nachvollziehen.

Der <button> hat gegenüber dem <input type="submit"> allerdings den klaren Vorteil, dass seine Beschriftung, von dessen Wert abweichen kann.

<button name="action" value="0">reparieren</button>
<button name="action" value="1">deinstallieren</button>

Das verarbeitende Skript, das das Formular entgegen nimmt, muss dann keine Entscheidungen auf Basis (möglicherweise sprachabhängiger) Beschriftungen treffen.

[hotti]

hi,

Der <button> hat gegenüber dem <input type="submit"> allerdings den klaren Vorteil, dass seine Beschriftung, von dessen Wert abweichen kann.

<button name="action" value="0">reparieren</button>
<button name="action" value="1">deinstallieren</button>

Das verarbeitende Skript, das das Formular entgegen nimmt, muss dann keine Entscheidungen auf Basis (möglicherweise sprachabhängiger) Beschriftungen treffen.

Das muss es auch nicht, wenn bei einem herkömmlichen <input type="submit">
 <input type="submit" name="parametername" value="foo">
 <input type="submit" name="anderername" value="foo">

die Parameter-Kontrollstruktur nicht den value sondern name (Parametername) auswertet. Dass <butten> ein Submit auslöst, war mir allerdings auch neu.

Schöne Grüße.

[henman]

servus hotti,

Das muss es auch nicht, wenn bei einem herkömmlichen <input type="submit">
<input type="submit" name="parametername" value="foo">
<input type="submit" name="anderername" value="foo">

die Parameter-Kontrollstruktur nicht den value sondern name (Parametername) auswertet. Dass <butten> ein Submit auslöst, war mir allerdings auch neu.

Interessanter Ansatz, trotzdem finde ich Buttons flexibler. Die Auswertung kann außerdem leichter realisiert werden.

Variante mit Namen:

  
if($_POST('speichern')){  
    // tue was  
}  
if($_POST['abbrechen']){  
    // tue was anderes  
}  
if(!$_POST['speichern'] && !$_POST['abbrechen']){  
    // tue sonstewas  
}  

Variante mit Werten:

  
switch($_POST['action']){  
    case 'speichern':  
        // tue was  
    break;  
    case 'abbrechen':  
        // tue was anderes  
    break;  
    default:  
        // tue sonstewas  
}  

henman

[henman]

servus henman,

if($_POST('speichern')){

Syntaktische Fehler sind volle Absicht. :P

henman

[hotti]

servus henman,

if($_POST('speichern')){

Syntaktische Fehler sind volle Absicht. :P

Du machst einen systematischen Fehler: if, if, if… und damit wirds schwierig, alle Fälle zu erfassen. Ein Switch ist da schon besser, aber warum nicht gleich ein

  
if(){}  
elsif(){}  
elsif(){}  
else{}  

denn damit hast Du im else-Zweig nur noch das, was Du vorher ausgeschlossen hast, nämlich:
else{ "Unbekannter Parameter" }

Schöne Grüße.

[henman]

servus hotti,

Du machst einen systematischen Fehler: if, if, if… und damit wirds schwierig, alle Fälle zu erfassen. Ein Switch ist da schon besser, aber warum nicht gleich ein

Wie will ich denn bei mehreren möglichen Namen einen Switch benutzen?

if(){}
elsif(){}
elsif(){}
else{}

  
Mit Verlaub, aber ich finde elseifs ganz furchtbar unleserlich.  
  
henman

-- 
"Sir, we are surrounded!" - "Excellent, we can attack in any direction!"

[hotti]

servus hotti,

Du machst einen systematischen Fehler: if, if, if… und damit wirds schwierig, alle Fälle zu erfassen. Ein Switch ist da schon besser, aber warum nicht gleich ein

Wie will ich denn bei mehreren möglichen Namen einen Switch benutzen?

Logisch, dass das mit einem Switch gar nicht geht: Ein Switch filtert über die Werte. Was machst Du, wenn es zu einem Parameter mehrere Werte gibt?

Schöne Grüße.

[henman]

servus hotti,

Was machst Du, wenn es zu einem Parameter mehrere Werte gibt?

Ich benutze einen Switch.

henman

[hotti]

servus hotti,

Was machst Du, wenn es zu einem Parameter mehrere Werte gibt?

Ich benutze einen Switch.

Ok. Jetzt bringen wir mal Licht in das Dunkel. Mit einem Switch filterst Du die Werte, das sind i.d.R. Benutzereingaben. Eine Kontrollstruktur hingegen übernimmt die Kontrolle über die Parameter (Schlüssel), die der Entwickler festlegt. Ein Parameter-Kontrollstruktur dient in erster Linie nicht der Kontrolle der Benutzereingaben sondern dazu, die verschiedenen Zustände einer Anwendung auf Parameter abzubilden.

Zum Beispiel kennt ein Forum 2 Zustände:

1. Übersicht zeigen, keine Parameter
2. einen Thread zeigen, Parametername show, Wert ist die mesg-ID
   Es gibt einen Zustand-Übergang: Das Senden einer Nachricht, entweder als Erföffnung für einen neuen Thread oder als Antwort auf eine bereits vorhandende Nachricht. Ein einziger Parameter genügt, diesen Übergang auszulösen, wohlgemerkt: Der Parameter, nicht dessen Wert.

Nach dem Zustandsübergang ergibt sich wieder einer der beiden Zustände (1) oder (2), je nachdem, wie der Programmierer das vorgesehen hat, wird nach dem Senden entweder die Übersicht gezeigt oder der betreffende Thread.

Das ist das Grundgerüst: Die Abbildung der Zustände einer Anwendung über Parameter bzw. deren Namen. Hierzu ist eine Kontrollstruktur das Mittel zum Zweck, ein Switch ist dafür völlig ungeeignet.

Nun kommen die Werte ins Spiel, die müssen natürlich auch kontrolliert werden. Bspw. ob eine eingegebene mesg-ID valide ist (ein Benutzer kann den URL manipulieren), oder ob der Benutzer alle Pflichtfelder ausgefüllt hat. Wir müssen im Fall einer fehlerhaften Eingabe nicht das ganze Zustands-Modell über den Haufen werfen, es genügt die Ausgabe einer Fehlermeldung in einem der beiden Zustände (1) oder (2). Das sind sozusagen die stabilen Zustände: Tritt beim Zustandsübergang (Senden einer Nachricht) ein Fehler auf, fällt die Anwendung zurück in einen der beiden Zustände, d.h., sie ist und bleibt stabil.

Letzeres kannst Du nur mit einer Kontrollstruktur (if, elsif, else) sicherstellen. Natürlich kannst Du einen Switch über die Benutzereingaben legen, das bietet sich an, wenn die Eingaben vorbelegte Werte haben, z.B. Radiobuttons, Selectfelder oder Checkboxen.

Und nochwas: Einem Benutzer darf es nicht möglich sein, das Zustandsmodell zu ändern bzw. einen instabilen Zustand der Anwendung zu erzeugen. Auch dann nicht, wenn er zusätzliche oder unbekannte Parameter ins Spiel bringt. Derartige Manipulationsversuche landen unweigerlich im else-Zweig.

Schöne Grüße.

[Gunnar Bittersmann]

@@hotti:

nuqneH

Dass <butten> ein Submit auslöst, war mir allerdings auch neu.

Vorsicht Falle!

Qapla'

[tinita]

Der <button> hat gegenüber dem <input type="submit"> allerdings den klaren Vorteil, dass seine Beschriftung, von dessen Wert abweichen kann.

<button name="action" value="0">reparieren</button>
<button name="action" value="1">deinstallieren</button>

Das verarbeitende Skript, das das Formular entgegen nimmt, muss dann keine Entscheidungen auf Basis (möglicherweise sprachabhängiger) Beschriftungen treffen.

ich hab mich schon immer gewundert, dass das manche machen. warum nicht einfach den *namen* des elements benutzen für die unterscheidung?

[Auge]

Hallo

<button name="action" value="0">reparieren</button>
<button name="action" value="1">deinstallieren</button>

Das verarbeitende Skript, das das Formular entgegen nimmt, muss dann keine Entscheidungen auf Basis (möglicherweise sprachabhängiger) Beschriftungen treffen.

ich hab mich schon immer gewundert, dass das manche machen. warum nicht einfach den *namen* des elements benutzen für die unterscheidung?

Kann man, muss man aber nicht. Ob ich nach verschiedenen Namen oder nach verschiedenen Werten unter einem Namen unterscheide, ist auf der verarbeitenden Seite erstmal nur eine Frage der Formulierung der Bedingung. Mir persönlich ist die Zusammenfassung verschiedener Submit-Buttons unter einem Formularfeldnamen mit verschiedenen Werten lieber.

Wenn die Beschriftungen, also die Werte für die Submit Input-Felder, aus einer Sprachdatei kommen und diese auch bei der Formulierung der Bedingungen benutzt werden, braucht man keine Abstraktion der Werte zu Zahlen, wie sie oben gezeigt wird. Einfacher zu handhaben ist sie aber allemal.

Tschö, Auge

[hotti]

Hallo

<button name="action" value="0">reparieren</button>
<button name="action" value="1">deinstallieren</button>

Das verarbeitende Skript, das das Formular entgegen nimmt, muss dann keine Entscheidungen auf Basis (möglicherweise sprachabhängiger) Beschriftungen treffen.

ich hab mich schon immer gewundert, dass das manche machen. warum nicht einfach den *namen* des elements benutzen für die unterscheidung?

Kann man, muss man aber nicht. Ob ich nach verschiedenen Namen oder nach verschiedenen Werten unter einem Namen unterscheide, ist auf der verarbeitenden Seite erstmal nur eine Frage der Formulierung der Bedingung.

Es ist eine Frage der Bindung. Es ist einfacher, das Zustandsmodell sowie Zustandsübergänge an Parameter zu binden, als an Werte.

Wenn die Beschriftungen, also die Werte für die Submit Input-Felder, aus einer Sprachdatei kommen und diese auch bei der Formulierung der Bedingungen benutzt werden, braucht man keine Abstraktion der Werte zu Zahlen, wie sie oben gezeigt wird. Einfacher zu handhaben ist sie aber allemal.

Die Abstraktion erfolgt bereits bei der Bindung und die ist idealerweise von Sprachdateien unabhängig. Wenn die Bindung über von Sprache unabhängige Parameter(namen) erfolgt, ist das praktisch der Idealfall.

Schöne Grüße.

[1UnitedPower]

Hakuna matata!

Der <button> hat gegenüber dem <input type="submit"> allerdings den klaren Vorteil, dass seine Beschriftung, von dessen Wert abweichen kann.

<button name="action" value="0">reparieren</button>
<button name="action" value="1">deinstallieren</button>

Das verarbeitende Skript, das das Formular entgegen nimmt, muss dann keine Entscheidungen auf Basis (möglicherweise sprachabhängiger) Beschriftungen treffen.

ich hab mich schon immer gewundert, dass das manche machen. warum nicht einfach den *namen* des elements benutzen für die unterscheidung?

Das value-Feld auszuwerten hat einige praktische Vorteile gegenüber der Prüfung auf vorhandene Schlüssel:

Von mehreren Submit-Buttons kann immer nur einer betätigt werden. Die Auswahl, die man trifft, ist also vergleichbar mit der Auswahl aus einer Gruppe Radiobuttons (sowie in Matthias' Beispiel) oder aus einer Selectbox. Bei diesen Eingabefeldern wird die getroffene Auswahl notwendiger Weise als Wert eines Schlüssel/Werte-Paares kodiert und nicht als diskrete Schlüssel. Wenn man den Fall „mehrere Submitbuttons“ analog zu „Auswahl aus einer Gruppe Radiobuttons“ und „Auswahl aus einer Select-Box“ behandelt, ergibt sich der Vorteil, dass die Fälle auch serverseitig gleich behandelt werden können. Ferner kann auf diese Weise der wechselseitige Ausschluss der Optionen schon bei der Übermittlung der Daten sichergestellt werden. Wenn man mehrere Submit-Buttons mit unterschiedlichen Namen auszeichnet ist das nicht möglich. Der Server müsste immer auch den Fall prüfen, was ist wenn zwei Optionen gesetzt sind, die eigentich nicht beide gleichzeitig aktiv sein sollten. henman ist hier wunderbar in die Falle getappt. Was würde denn nun passieren, wenn $_POST['speichern'] und $_POST['abbrechen'] gesetzt wären? Dieser Fall sollte eigentlich nie eintreten.

Eine Auswertung des Wertes zu einem immer gleichen Schlüssel kann zudem in vielen Fällen generisch gestaltet sein. Sollte irgendwann ein dritter Submit-Button (oder eine dritte Radiobox) hinzukommen, muss kein serverseitiger Code geschrieben werden, der die Formulardaten auf einen neuen Schlüssel überprüft, evtl. muss sogar gar kein neuer Code geschrieben werden.

[tinita]

Das value-Feld auszuwerten hat einige praktische Vorteile gegenüber der Prüfung auf vorhandene Schlüssel:

Von mehreren Submit-Buttons kann immer nur einer betätigt werden.

Soweit klar.

Die Auswahl, die man trifft, ist also vergleichbar mit der Auswahl aus einer Gruppe Radiobuttons (sowie in Matthias' Beispiel) oder aus einer Selectbox. Bei diesen Eingabefeldern wird die getroffene Auswahl notwendiger Weise als Wert eines Schlüssel/Werte-Paares kodiert und nicht als diskrete Schlüssel. Wenn man den Fall „mehrere Submitbuttons“ analog zu „Auswahl aus einer Gruppe Radiobuttons“ und „Auswahl aus einer Select-Box“ behandelt, ergibt sich der Vorteil, dass die Fälle auch serverseitig gleich behandelt werden können. Ferner kann auf diese Weise der wechselseitige Ausschluss der Optionen schon bei der Übermittlung der Daten sichergestellt werden. Wenn man mehrere Submit-Buttons mit unterschiedlichen Namen auszeichnet ist das nicht möglich. Der Server müsste immer auch den Fall prüfen, was ist wenn zwei Optionen gesetzt sind, die eigentich nicht beide gleichzeitig aktiv sein sollten.

Hier hast du mich verloren.
Wenn der User einen Button anklickt, sollte nur einer am Server ankommen, ok.
Wird der Request beispielsweise von einem Skript abgeschickt oder manipuliert man sonst irgendwie die Parameter, kann man mehrere Submit-Buttons simulieren.
Das ist aber bei beiden Varianten möglich.
also action=Abbrechen&action=Speichen ist genauso möglich wie submit.cancel=1&submit.save=1

In jedem Fall muss geprüft werden. Bzw. der Server nimmt einfach einen von beiden.
Die zugehörigen Parameter müssen ja in jedem Fall geprüft werden.

Ich sehe da also keinerlei Unterschied.

Eine Auswertung des Wertes zu einem immer gleichen Schlüssel kann zudem in vielen Fällen generisch gestaltet sein. Sollte irgendwann ein dritter Submit-Button (oder eine dritte Radiobox) hinzukommen, muss kein serverseitiger Code geschrieben werden, der die Formulardaten auf einen neuen Schlüssel überprüft, evtl. muss sogar gar kein neuer Code geschrieben werden.

Verstehe ich auch nicht. Wenn ein neuer Submitbutton hinzukommt, ist der entweder nur zur
Deko oder er hat eine bestimmte Funktion.
In beiden Varianten kann ich ihn auswerten und muss dafür Code anpassen oder eben nicht.

Im übrigen: die Auswertung kann, wenn man ein hübsches Framework hat, z.B. so gestaltet werden:
Alle submit-Buttons haben das Prefix "submit.".
Der Framework-Code sammelt die Buttons beim Einlesen der Parameter.
Der eigentliche Code ruft nun nur noch auf:
if ($req->submit('save')) { ... }
Nix mehr mit
if ($req->param('action') eq 'Speichern') { ... }

[1UnitedPower]

Hakuna matata!

Ferner kann auf diese Weise der wechselseitige Ausschluss der Optionen schon bei der Übermittlung der Daten sichergestellt werden. Wenn man mehrere Submit-Buttons mit unterschiedlichen Namen auszeichnet ist das nicht möglich. Der Server müsste immer auch den Fall prüfen, was ist wenn zwei Optionen gesetzt sind, die eigentich nicht beide gleichzeitig aktiv sein sollten.

Hier hast du mich verloren.
Wenn der User einen Button anklickt, sollte nur einer am Server ankommen, ok.
Wird der Request beispielsweise von einem Skript abgeschickt oder manipuliert man sonst irgendwie die Parameter, kann man mehrere Submit-Buttons simulieren.
Das ist aber bei beiden Varianten möglich.
also action=Abbrechen&action=Speichen ist genauso möglich wie submit.cancel=1&submit.save=1

In jedem Fall muss geprüft werden. Bzw. der Server nimmt einfach einen von beiden.
Die zugehörigen Parameter müssen ja in jedem Fall geprüft werden.

Damit hast du natürlich recht. Defakto muss der PHP-Programmierer sich im ersten Fall aber nicht selbst darum kümmern, weil nur ein Wert im $_GET bzw. $_POST-Array landet. In anderen Serverumgebungen sieht das eventuell anders aus.

Eine Auswertung des Wertes zu einem immer gleichen Schlüssel kann zudem in vielen Fällen generisch gestaltet sein. Sollte irgendwann ein dritter Submit-Button (oder eine dritte Radiobox) hinzukommen, muss kein serverseitiger Code geschrieben werden, der die Formulardaten auf einen neuen Schlüssel überprüft, evtl. muss sogar gar kein neuer Code geschrieben werden.

Verstehe ich auch nicht. Wenn ein neuer Submitbutton hinzukommt, ist der entweder nur zur
Deko oder er hat eine bestimmte Funktion.
In beiden Varianten kann ich ihn auswerten und muss dafür Code anpassen oder eben nicht.

Man kann sich das einem Bestellformular gut vorstellen: Beim Checkout-Vorgang kann der Kunde wählen, mit welcher Bezahlmethode er den Kauf abschließen möchte, es gibt entsprechende Buttons für "Überweisung" und "Lastschrift". Die könnten so aussehen:

<button name="payment_method" value="assignment">Überweisung</button>  
<button name="payment_method" value="debit">Lastschrift</button>

Irgendwo im Backend-Code, wird es eine Routine geben, die den Wert des Buttons ausliest und für die Buchhaltung in eine Datenbank einträgt.

$checkout->bindValue(':payment_method', $_POST['payment_method']);

Eine Alternative wäre:

<button name="assignment">Überweisung</button>  
<button name="debit">Lastschrift</button>

Im Backend-Code, wird es irgendwo eine Fallunterscheidung geben:

if ( isset( $_POST['assignment'] ) ) {  
   $checkout->bindValue(':payment_method', 'assignment');  
} elseif ( isset( $_POST['debit'] ) {  
   $checkout->bindValue(':payment_method', 'debit');  
}  
  
$checkout->bindValue(':payment_method', 1);

Wenn irgendwann Paypal als neue Zahlungsart eingeführt wird, dann würde es im ersten Fall reichen, nur den neuen Button für Paypal einzufügen, der Backend-Code könnte unangetastet bleiben.

<button name="payment_method" value="paypal">Paypal</button>
Im zweiten Fall, müsste der Button hinzugefügt werden und der Servercode müsste angepasst werden:

<button name="paypal">Paypal</button>

if ( isset( $_POST['assignment'] ) ) {  
   $checkout->bindValue(':payment_method', 'assignment');  
} elseif ( isset( $_POST['debit'] ) {  
   $checkout->bindValue(':payment_method', 'debit');  
} elseif ( isset( $_POST['paypal'] ) {  
   $checkout->bindValue(':payment_method', 'paypal');  
}

Ich weiß, ich weiß das hab der Kuh schon sehr schön auf die Haut geschneidert und mit ein wenig biegen und brechen so herbeikonstruiert. Ein besseres Beispiel viel mir leider gerade nicht ein. Wenn du das Argument nicht gelten lassen willst, kann ich das auch verstehen. Das Totschalgargument pro value-Attribut auf den Submitbuttons ist für mich ohnehin, dass die Handhabung von Buttons somit analog zu Radiobuttons und Selectboxen erfolgt. Wenn man sich später entscheiden sollte, doch lieber Radiobuttons anstatt mehrerer Submitbuttons zu verwenden, ist das mit weniger Aufwand verbunden.

Im übrigen: die Auswertung kann, wenn man ein hübsches Framework hat, z.B. so gestaltet werden:
Alle submit-Buttons haben das Prefix "submit.".
Der Framework-Code sammelt die Buttons beim Einlesen der Parameter.

Das ginge selbstvertändlich auch, damit hättest du das Problem mit den Bezahlmethoden, das ich gerade versucht habe zu erklären, auch gelöst.

Mal umgekehrt gefragt, wo liegt denn der Vorteil darin, das value-Attribut zu vermeiden und nur auf das name-Attribut zu reagieren? Vorallem wenn man dann im Nachhinein versucht wieder Schlüssel/Werte-Paare nachzubstalen, sowie bei deiner Idee mit den gemeinsamen Prefixen?

[hotti]

Moin,

Mal umgekehrt gefragt, wo liegt denn der Vorteil darin, das value-Attribut zu vermeiden und nur auf das name-Attribut zu reagieren? Vorallem wenn man dann im Nachhinein versucht wieder Schlüssel/Werte-Paare nachzubstalen, sowie bei deiner Idee mit den gemeinsamen Prefixen?

• Die Programmlogik wird über Parameter(name) strukturiert
• Dazu legt der Programmierer Schlüsselparameter fest
• Die Menge der Schlüsselparameter ist viel kleiner als die Menge möglicher Werte für Parameter, welche den Benutzereingaben vorbehalten sind
• Parameter sind eindeutig, auch dann, wenn es zu einem Parameter mehrere Werte gibt (siehe einschlägige RFC)
• Zustände einer Anwendung sind eindeutig und über Schlüsselparameter einfacher zu kontrollieren, als über eine große Menge möglicher Werte
• Die Anwendung kennt nur stabile Zustände und vom Programmierer genau definierte Zustandsübergänge (State Transition)
• Die Zustände der Anwendung werden damit von Benutzereingaben unabhängig, Benutzereingaben führen höchstens zur Verzweigungen innerhalb der vom Programmierer definierten Zustände
• Parameter zum Definieren der Zustände sind sauber von Parametern getrennt, welche Benutzereingaben dienen
• Die Programmstruktur wird übersichtlicher

Darüber lohnt es sich mal nachzudenken.

MfG

[hotti]

Der <button> hat gegenüber dem <input type="submit"> allerdings den klaren Vorteil, dass seine Beschriftung, von dessen Wert abweichen kann.

<button name="action" value="0">reparieren</button>
<button name="action" value="1">deinstallieren</button>

Das verarbeitende Skript, das das Formular entgegen nimmt, muss dann keine Entscheidungen auf Basis (möglicherweise sprachabhängiger) Beschriftungen treffen.

ich hab mich schon immer gewundert, dass das manche machen. warum nicht einfach den *namen* des elements benutzen für die unterscheidung?

Zumal die Parameter-Bindung Einiges vereinfacht, z.B. werden mit

  
if( $cgi->delete('senden') ){  
   @user_input = $cgi->param(); # hier nur noch Benutzereingaben  
}  

gleich drei Dinge mit einmal erledigt:

1. ein Zustandsübergang wird eingeleitet
2. der Wert des Parameters 'senden', egal ob das ein Einzelwert oder eine Liste ist, muss nicht weiter geprüft werden
3. die übriggebliebene Parameterliste (Schlüssel-Werte-Paare) wird bereinigt, es liegen nur noch die Benutzereingaben vor

Literatur: EA, Optimierung

Was die Optimierung betrifft: Eine fehlerhafte Benutzereingabe sollte keinen weiteren Zustand erzeugen (das wäre ein Bruch mit der Parameterbindung).

Schöne Grüße.

[Gunnar Bittersmann]

@@Matthias Apsel:

nuqneH

http://blog.selfhtml.org/2015/02/09/input-oder-button-fuer-submit-elemente/

„Grenzwertig ist die Verwendung von button–Elementen, wenn es mehrere Submit-Buttons gibt, weil der Benutzer an dieser Stelle eine Entscheidung trifft … Deshalb würde ich an dieser Stelle durchaus auch input–Elemente verwenden …“

Deine Einschätzung ist grenzwertig. ;-)

Es sind ja dennoch Aktionen (Formular absenden), wenn auch zwei verschiedene. Auch schon aus den von 1UP genannten pragmatischen Gründen würde ich die Empfehlung für input nicht geben.

IE 6 ist so bedeutungslos, dass er keinen ganzen Absatz „Fazit“ verdient. Das könnte auf einen Nebensatz (hier nicht im grammatikalischen Sinne ;-)) verkürzt werden.

Qapla'

[Matthias Apsel]

Om nah hoo pez nyeetz, alle!

Ich antworte mir an dieser Stelle mal selbst und bedanke mich für das teils sehr ausführliche und fachlich fundierte Feedback. Diese Diskussion lässt sich sicher in den Artikel einpflegen. Ich suche noch

* ein Beitragsbild
* die Stelle der Spec, die die Formularübertragung spezifiziert

Matthias

[1UnitedPower]

Hakuna matata!

* die Stelle der Spec, die die Formularübertragung spezifiziert

Über den Einfluss der Attribute: action, enctype, method, novalidate, und target:

http://www.w3.org/TR/html51/forms.html#form-submission
https://html.spec.whatwg.org/multipage/forms.html#form-submission

Über allgemeinen Kram und Formular-Kodierung findet man etwas weiter unten etwas:

http://www.w3.org/TR/html51/forms.html#form-submission-0
https://html.spec.whatwg.org/multipage/forms.html#form-submission-2

[Matthias Apsel]

Om nah hoo pez nyeetz, Matthias Apsel!

Diese Diskussion lässt sich sicher in den Artikel einpflegen.

done

Matthias