Ich bevorzuge die von Beat vorgeschlagene Variante ohne unnötigen Bloat-Code.
Ja, das ist in Ordnung, vor allem semantisch korrekt. Die für mich in der Beziehung relevante Frage ist aber vor allem der Zeitaufwand für die Erstellung des Formulars. In neunzig Prozent der Fälle hab' ich auf einer Webseite folgende Formularstruktur:
Label1 : Eingabefeld1
Label2 : Eingabefeld2
Label3 : Eingabefeld3
Label4 : Eingabefeld4
Label5 : Eingabefeld5submit reset verschwind
Das sind die Formulare, die ich hasse.
Sie brauchen dann für alles Erklärenwerte sSonderfunktionalität und Userinteraktion.
Vielleicht ist Beat mit seiner Konstruktion ja so gelenk, daß er damit schneller ist als ich mit meiner Tabelle, ich bezweifle das, vor allem, was hätt' ich davon, er macht's mir ja nicht;) - und mir bezahlt keiner die Herumfuzzlerei.
In ehome-Factory habe ich zweierlei Ansätze:
Frontend:
Jedes Formular braucht eine eigene spezifische pflege und damit auch Individuelle Überlegungen zum Code.
Dort bevorzuge ich Fieldset-Gruppierungen.
Ich will das Lael über dem Inputfeld, weil der Labeltext öfters länger ist.
Im Backend.
Ich habe eine <dl> mit Klasse, die später vom Javascript bearbeitet wird, um Abschnitte des Formulars, das meist repetitive Listen sind, abzuarbeiten.
Dort brauche ich eine grosse Homogenität, habe dann aber im <dd> Part immer noch alle Freiheiten.
Eine tabellarische Struktur kommt bei mir also schon mal sehr selten vor.
Das Gefrickel findet genau 1 mal statt. Nämlich bei der CSS-Definiton der Klassen.
mfg Beat
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische