fehlerhafte Behandlung von <button> in IE7

[BLG]

Und wenn Hinz und Kunz ihre Skins falsch bauen, indem sie einem Inputfeld oder eben einem Button einen falschen Namen geben funktioniert deine Seite nunmal nicht!

In dem Fall wie du Buttons behandelst müssten sie sogar außer dem Namen sogar noch das Value-Attribut bzw. deinen 'Fix' beachten! Oder sollen die Werte von Skin zu Skin variieren?

[Marcusson]

*seufz* was ist so schwer daran zu verstehen?

Gar nichts müssen Sie beachten. Wer das Value-Attribut von Buttons nie beachtet hat, muss es auch zukünftig nicht tun. Wer sich auf die IE-Semantik verlässt, braucht den Fix nicht zu installieren, sollte aber wissen, dass seine Seiten im Firefox nicht funktionieren werden. Wer seine Seiten W3C-konform schreibt und zum Beispiel im Firefox testet, der bekommt sie mit dem Fix unter IE zum laufen. Andere Browser als der IE sind nicht betroffen - weder von dem Bug, noch von dem Fix.

Und nochmal zum allgemeinen Verständnis:

Der W3C-Standard legt die Semantik fest. Mindestens Firefox, Opera, wahrscheinlich aber auch alle anderen Browser setzen die Vorgaben des W3C korrekt um. Nur der IE tut dies nicht und behandelt das Button-Element fälschlicherweise wie ein Input-Element, was eindeutig ein Bug des IE ist.

Also: nochmal von vorn. Bitte den W3C-Standard lesen und verstehen, was da gemeint ist.

http://www.w3.org/TR/html401/interact/forms.html#h-17.5

<!ATTLIST BUTTON
...
name CDATA #IMPLIED
value CDATA #IMPLIED -- sent to server when submitted
...
>

[...] A form may contain more than one submit button.

Nach W3C-Standard sollten sich folgende Alternativen bei der Übergabe der Werte identisch verhalten:

<select name="id">
<option value="1">foo1</option>
<option value="2">foo2</option>
<option value="3">foo3</option>
</select>
<input type="submit">

<button type="submit" name="id" value="1">foo1</button>
<button type="submit" name="id" value="2">foo2</button>
<button type="submit" name="id" value="3">foo3</button>

Der große Vorteil ist, dass man mit dem Button-Element deutlich mehr gestalterische Freiheiten hat. Man könnte es dort platzieren, wo sie der Logik nach hingehören und wäre nicht darauf angewiesen zwingend eine Select-Box oder (stilistisch schlechte) JavaScript Workarounds zu verwenden. Vor allem Formulare mit komplexen Substrukturen gewinnen dadurch an Transparenz. Außerdem darf das Button-Element anders als Input auch weitere Tags, wie zum Beispiel Grafiken enthalten. Das erlaubt optisch deutlich ansprechendere Menüs. Davon profitiert nicht zuletzt die Useability. Und zu guter Letzt: in den gängigen Programmiersprachen wie Delphi, Java, C# etc. ist es schon lange üblich Formulare mit mehreren Schaltflächen zu haben, die unterschiedliche Aktionen auslösen. Solche Oberflächen sind also in einer Desktopumgebung keineswegs die Ausnahme, sondern eher der Standard.

Also: niemand baut irgendwelche "falschen Formulare". Die Formulare sind korrekt nach W3C. Der Fehler liegt nicht in den Formularen, sondern im IE.
Ich wollte eine Lösung, die dafür sorgt, dass sich der IE so verhält, wie das W3C es vorgesehen hat und wie alle anderen Browser dies bereits tun. Das ist ein ganz normaler Vorgang der technischen Abstraktion: dass heißt, ich sorge dafür, dass sich Steuerelemente browserunabhängig so verhalten wie erwartet und sich der technisch unbedarfte Anwender, der seine Formulare nach W3C-Standard baut, keine Gedanken darüber machen muss, welchen Browser der Endnutzer verwendet.

Das ist IMHO ein guter Designansatz.

Natürlich kann man sich streiten, ob man lieber Select-Elemente, oder Input-Elemente anstatt Buttons verwendet. Aber das war von Anfang an niemals Inhalt dieses Threads.

[TBT]

Und warum baust du dann so eine Javscript Krücke, wenn es möglich ist, die verschiedenen Buttons korrekt auszuwerten?
Was hindert dich daran den Buttons verschiedene Namen zu geben? Dann ist es egal, ob innerHtml oder value vom Browser geschickt wird.
Das ist das, was du die ganze Zeit nicht verstehst!

[Marcusson]

Das habe ich für meine eigenen Templates längst getan. Diese Änderungen betreffen aber natürlich nur Neuinstallationen und auch nur meine eigenen Skins.

Die JavaScript-Lösung ist für die bestehenden Installationen, modifizierte Ableger und fremde Skins gedacht, bei denen ich keinen direkten Einfluss auf den Quellcode habe.