- Layout für Formulare - Webstandard-Blog - Webdesign und Webentwicklung

Layout für Formulare

Einen interessanten Ansatz für den Umgang mit Formularen, bietet ein bereist einige Wochen alter Artikel auf A List Apart, von Nick Rigby. Seine Idee der Umsetzung einer Formularpräsentation findet bei mir Erwähnung auf Grund einer neuen Möglichkeit des Formularaufbaus. Weit verbreitet und häufigste Variante, ist der Einsatz von Breaks ( br ) und Absätzen / Paragraphen ( p ), um damit bspw. nach Eingabefeldern oder Auswahlmenues eine neue Zeile zu "erzwingen". Grosser Beliebtheit erfreuen sich auch >Divkonstrukte in Formularen. Alles in allem praktikable Lösungen, aber bei grossen umfangreichen Registrierungsformularen nicht wirklich übersichtlich. Von den zahlreichen Ansätzen zurück zum Lösungsansatz von Nick. Seine Lösung sieht eine Liste vor ( siehe Grafik ), in der jeder Listenpunkt eine Kombination aus Label und Formular-Element ( bspw. Eingabefelder / Auswahlmenü und Label - siehe Formular anlegen ). Wer alle Elemente untereinander darstellen möchte, weil beispielsweise nicht genügend Breite für das Formular vorhanden ist, braucht nur pro Listenpunkt nur eines dieser Elemente ( erster li=label 1, zweiter li=Eingabefeld 1, dritter li=label 2, vierter li=Eingabefeld 2 usw.). Es werden keine Breaks , Absätze oder zusätzliche Div-Elemente benötigt, was zudem für etwas mehr Übersicht innerhalb des Quellcodes sorgt und einer damit verbundenen einfacheren Pflege des Formulars führt.

Code-Beispiel <fieldset class="listFormExample"> <legend>ListForm</legend> <ol class="listForm"> <li> <label for="name">Name <em>*</em></label> <input id="name" value="Hans Mustermann"/> </li> <li> <label for="addresse">Addresse <em>*</em></label> <input id="addresse" value="Musterstrasse 12" /> </li> <li> <label for="land">Land</label> <select id="land"> <option value="Deutschland">Deutschland</option> <option value="Italien">Italien</option> <option value="Portugal">Portugal</option> <option value="Frankreich">Frankreich</option> </select> </li> <li> <label for="birthday">Geburtstag</label> <select id="day"> <option value="1">1</option> <option value="2">2</option> </select> <select id="month"> <option value="Jan">Jan</option> <option value="Feb">Feb</option> </select> <select id="year"> <option value="1974">1974</option> <option value="1975">1975</option> </select> </li> <li> <label for="mail">E-Mail <em>*</em></label> <input id="mail" value="HansMustermann@mail.com"/> </li> </ol> </fieldset>

Eine weitere Überlegung spielt bei solchen Lösungsideen natürlich immer die Semantik. Passen Formular und Liste eigentlich zueinander? Meines Erachtens nach ja, denn Formulare sind nichts anderes als eine Auflistung, Aneinanderreihung oder Abfrage ( bspw. Name, Ort, Postleitzahl, Alter, Geschlecht ) von zusammenhängenden oder zusammenhanglosen Daten. Des öfteren kommt es vor, dass Formulare in unterschiedliche Rubriken unterteilt sind ( bspw. Angaben zu persönlichen Daten, Interessen, ein Abschnitt für die Bankverbindung oder Angaben zur Kontaktierung des Interessenten bspw. per SMS, Handy, Fax, Tel ).

Übersichtsgrafik eines Formulars

Aufbau eines Formulars

Mittels der einzelnen Listen oder Fieldsets, werden diese Formularbereiche im Quellcode nicht nur gut sichtbar, sondern bieten Screendreadernutzern eine weitere Möglichkeit, die einzelnen Bereiche eventuell bei umfangreicheren Formularen zu überspringen in denen bpws. keine relevanten Daten ( ohne Sternchen ) abgefragt werden. Bei einem umfangreichen (Registrierungs)Formular, müsste man alle Formularelemente per Tab anspringen, um dann am Ende die Daten versenden oder speichern zu können. Eine mögliche Aufteilung der Listen wäre somit folgende: persönliche Daten ( Pflichtangaben ), persönliche Interessen ( keine Pflichtangaben ), Zusatzinformationen ( keine Pflichtangaben ) und Bankverbindung ( Pflichtangaben ). Hiermit könnte dem User die Möglichkeit gegeben werden, zwei vielleicht recht zeitaufwendige Formularbereiche zu überspringen, um somit schneller ans gewünschte Ziel zu gelangen.

Anwendungsbeispiel des obigen Formulars

ListForm

Name *
Addresse *
PLZ/Stadt
Land
Geburtstag
Kommentar Testkommentar von Herrn Hans Mustermann

Ausschnitt des CSS Codes

Um die hier verwendeten Styledefinitionen der einzelnen Formelemente besser nachvollziehen zu können, hier noch einen kleinen Auszug wichtiger Styles für dieses Formular.

Code-Beispiel ... fieldset.listFormExample { border: 1px solid #AB4001; background-color: #FFF; margin: 5px 5px 15px 34px; padding: 0 0 10px 0; font:93% "Verdana",Arial; color: #666; width: 397px; } fieldset.listFormExample label { float:left; margin:0; padding:0; width: 203px; } fieldset.listFormExample input, fieldset.listFormExample textarea, fieldset.listFormExample select { font: 100% "Verdana",Arial; height: 17px; float:left; width: 167px; margin: 0; padding: 0; border: 1px solid #AB4001; background-color: #FFF; } fieldset.listFormExample input#plz { width: 40px; margin: 0 4px 0 0; } fieldset.listFormExample input#stadt { width: 121px; } fieldset.listFormExample select#land { border: 1px solid #AB4001; width: 169px; } fieldset.listFormExample select#day, fieldset.listFormExample select#month, fieldset.listFormExample select#year { border: 1px solid #AB4001; margin: 0 3px 0 0; width: 48px; } fieldset.listFormExample select#year { width: 69px; } ...

Das gut an diesem Ansatz ist, dass man eine weitere Lösungsmöglichkeit anbieten zu kann, um Formulare gut und übersichtlich zu aufzubauen und strukturieren. Um so einfacher letztendlich die Handhabung beim Umgang mit Formularen ist, um so geringer ist die Hemmschwelle diese auszufüllen und demzufolge um so grösser die Wahrscheinlichkeit, dass ein Kontakt oder gar eine Bestellung oder Kauf online zustande kommt. Da für viele User das Ausfüllen und Navigieren innerhalb von Formularen oft zur zeitintensiven und nervenkostenden Angelegenheit wird, bietet die Idee von Nick Rigby eine gute Alternative um dies zu erleichtern. Mir persönlich gefällt die Erweiterung des Ansatzes mittels Javascript zwar nicht so gut, da man es auch ohne sehr gut bewerkstelligen kann, auch wenn das untenstehende Kommentarformular ( noch ) mittels Breaks und Absätzen realisiert wird.

Mich würde gern interessieren, welche der folgenden Varianten ihr bei Euren Formularen favorisiert bzw. zum Einsatz bringt?

Breaks oder Absätze,
dynamische Laufweite ( Orientierung an Fieldset etc. )
Divkonstrukte
weitere Lösungsansätze ( wenn ja, welche )

SilentWarrior
24 Jul 2006, 13:11

Ich persönlich finde die Idee mit dem JavaScript nicht nur nicht so gut, sondern absolut katastrophal. Damit landen wir wieder in der Steinzeit des Web, in der JavaScript für den Besuch/die Benutzung einer Seite/eines Formulars vorausgesetzt wird, denn der Besucher ohne JS hat einen ganz gravierenden Nachteil, auch wenn es nur ein visueller ist.

Ich persönlich zeichne Formulare am liebsten mit Definitionslisten aus (Label in dt, Input in dd), da das m. E. am meisten Sinn macht.
Nikolas Djuga
24 Jul 2006, 13:12

Ich benutze zum Formularformatieren öfters mal Definitionslisten.
Ich hoffe, die Software übernimmt das folgende Beispiel. Für das CSS einfach in den Quelltext schauen.

Name
E-Mail
Webstandard-Team
24 Jul 2006, 13:29

@SilentWarrior: Bin ganz deiner Meinung, deshalb habe ich bei meinem Bsp. von diesem JavaScriptzusatz abgesehen. Solche wichtige Bereiche wie Registrierungsformulare sollten nicht von so etwas abhängig sein.

@Nikolas: Danke für den Link ( kannte ich noch nicht )
Mario
24 Jul 2006, 15:13

Interessant wäre es ja gewesen, wenn in dem "Beispiel eines Formularquellcode" auch der Teil von der "Übersichtsgrafik" für PLZ/Ort und Geburtsdatum mit drin gewesen wäre. Genau das lässt sich nämlich nicht so einfach auf diesen Weg realisieren und eine genauere Erklärung inkl. Stylesheet wäre wünscheswert.
Webstandard-Team
24 Jul 2006, 15:19

@Mario: Dem kann ich gerne nachkommen, so schwer ist das nicht du brauchst für die kleineren Auswahlmenüs nur eine andere klasse definieren als für die Länderauswahl und dann passt es. Ein Ausschnitt des CSS Bereiches wird hinzugefügt, um dies auch für alle verständlicher zu machen. Danke für den Tipp ;O)
Mario
24 Jul 2006, 15:42

Super! Bin schon gespannt, da ich meine Formulare ähnlich aufbaue und aus eigener Erfahrung weiß, dass dies nicht ganz so einfach ist. IE und FF verhalten sich da beide auch teilweise seltsam und einen wirklich praktikabelen Weg habe ich bisher noch nicht gefunden.
Harald
25 Jul 2006, 15:12

So geht es. Allerdings treten die ersten Haken mit den CSS-Floats auf, wenn Radio- oder Checkbox-Elemente verwendet werden. Eine ähnliche Lösung, allerdings mit p anstelle von Listen, setze ich seit etwa 2 1/2 Jahren im WebsoziCMS für alle Formulare (Livepage und Adminbereich) ein. Mehr dazu in der system.css der Seite http://www.websozis.de Klappt einwandfrei im IE, Firefox, Opera, Konqueror ... Es muss allerdigns label mit display:block versehen werden, damit es im IE klappt.

Javascript für die Validierung der Eingaben halte ich auf jeden Fall für sinnvoll. Das erspart Traffic, Script- und Ladezeiten. Das sich die Eingabevalidierung vorrangig auf Serverscripts stützt, halte ich für selbstverständlich. Wer sich auch Javascript verlässt, sollte die Finger von Formularen im Internet lassen. Natürlich darf durch JS auch nicht die Funktion der Seite eingeschränkt werden.
Webstandard-Team
25 Jul 2006, 15:44

Warum sollen bei Radio- oder Checkbox-Elementen haken bzw. Probleme auftreten? Alles nur eine Sache korrekter Styledefinitionen, ich sehe da ehrlich gesagt kein wirkliches Problem! Bezüglich des JavaScripts, war mein Kommentar ausschliesslich auf das Layout bezogen, nicht auf Eingabevalidierung etc.
Boris
26 Jul 2006, 20:30

Im Blog verwende ich die einfache Konstruktion mit Absätzen (p) und Zeilenumbrüchen (br), um zweizeilige Label-Input-Kombinationen zu erzielen.

Alternativ würde sich, wie schon von Vor-Kommentatoren erwähnt, der Einsatz von Definitionslisten anbieten, da sie als ausdrückliche Mehrzweck-Elemente (gemäß W3C) keine semantischen Fragen aufwerfen sollten.

Bei sehr umfangreichen und komplexen Formularen könnte ich mir aber durchaus auch eine Tabellenkonstruktion als semantisch angemessen vorstellen.
Jona
26 Jul 2006, 23:56

Bisjetzt habe ich auch meistens den Absatztag benutzt, allerdings ohne breaks. Die Liste macht aber in der Tat semantisch mehr Sinn und ist auch irgendwo raffinierter.
Eckhard Rotte
29 Jul 2006, 11:34

Ich finde, das so etwas am besten mit einer Tabelle zu erledigen ist. Semantisch ist es auch damit völlig korrekt dargestellt. und man erspart sich das Gefrickel mit floats, margins und diversen Browserbugs. Label mit floats werden, soweit ich mich entsinne in älteren Mozillas (Netscape 7) nicht dargestellt.
Ein weiterer Vorteil: die Spaltenausrichtung bleibt erhalten, auch wenn sich die Inhalte ändern - z. B. bei einer mehrsprachigen Site. Damit kann man auch den - wie ich finde - viel zu großen (Sicherheits)Abstand zwischen Label und Eingabefeld reduzieren, ohne eine kollabieren des Konstrukts zu riskieren.
Philipp Daun
31 Jul 2006, 20:07

Ich würde ganz spontan die hier vorgestellte Listen-Variante bevorzugen, da man damit...

a) die Gestaltung besser kontrollieren kann (lis kann man mit CSS formatieren, brs nicht)

b) die Gliederung der Elemente auch ohne CSS noch einen Sinn ergibt -- schließlich ist ja jedes Eingabefeld ein Unterelement des Formulars.
masone
03 Aug 2006, 10:46

Soso... nun gebe ich auch noch meinen Senf dazu.

Aus meiner Sicht wird hier etwas übertrieben.
Denn...

Es wird viel unnötiger Overhead generiert. Das ganze ist auch nur mit label und input zu lösen. Ein Break wäre semantisch absolut korrekt (und liesse sich übrigens auch stylen).

Ein Formular ist ein Formular und keine Liste. Damit sind wir wieder am Punkt Semantic Markup, der meiner Meinung nach hier verletzt wird.
(Ich kann ja auch jedes Wort eines Textes in eine Liste stecken, weil ein Text ja eigentlich eine Liste [Aneinanderreihung] von Wörtern).

Wie sich ein Screen Reader hier verhält wäre auch noch eine Interessante Frage.

Schlussendlich ist und bleibt es ein leidiges Theman. Ich denke es muss jeder selber wissen ob er Tabellen oder breaks oder etwas anderes bevorzugt :)
Webstandard-Team
03 Aug 2006, 12:25

Die Abfrage von aufgelisteten Eigenschaften eines Formulars und deren Angaben, sind für mich eine Liste abzufragender Daten. Ein jedes Wort innerhalb eines Textes, ergibt immer noch einen Satz ( und mehrere Sätze einen Absatz ) und keine Liste.

Eine Tabelle und Divs zur Konstruktion eines Formulares zu nutzen ist sicherlich noch weniger "semantisch", da finde ich ein definiertes Fieldset, die Liste und die Formularelemente wesentlich besser. Denn bekanntlicherweise besitzt man ohne Tabelle die Möglichkeit das Layout des Formulares zu ändern, ohne bspw. die html, php oder jsp Datei ändern zu müssen. Dafür sind immer noch die CSS Dateien verantwortlich.

Desweiteren hat auch niemand behauptet, dass es nicht ausschliesslich mit Label und Input gelöste werden könnte. Ein umfangreiches Formular mit Checkbox- und Radiobuttonombinationen dürfte hiermit allerdings etwas schwieriger zu realisieren sein, denn Margin und Paddingangaben erzeugen nicht bei allen Browsern eine identische Darstellung im Zusammenhang mit floats etc. Und genau dieser Overhead, der dann entstehen würde um alles zu optimieren, wird bei dieser Variante vermieden.

Dieses hier definierte Listenformular, ist nicht die ultimative Lösung, sondern bietet den Usern einfach nur eine weitere Variante zum Aufbau von Formularen an. Nicht mehr und nicht weniger.
Poldi 18 Aug 2006, 09:33

Hallo,

ich habe bisher immer eine Tabelle verwendet und finde das semantisch auch in Ordnung, da Formulare meist aus zwei Spalten bestehen, die man mit den Überschriften "Beschreibung" und "Formularfeld" versehen könnte!

Interessant finde ich, dass das untenstehende (recht einfache) Formular noch mit "
"s realisiert wird statt, wie oben vorgeschlagen, mit einer Liste.

Gruß,
Poldi
Poldi 18 Aug 2006, 09:44

Gemeint war natürlich:

<br ⁄>
Poldi 29 Aug 2006, 12:30

Hallo,
labels kann man ja auch mit Tabellen nutzen!
Wenn das einzige Argument gegen Tabellen die Reihenfolge der Daten ist - das entnehme ich zumindest dem Link - müsste man nur Sorge dafür tragen, dass die Reihenfolge gewahrt ist.
Dies sollte man grundsätzlich tun!
Gruß,
Poldi

P.S.: im übrigen ist auch die von Dir genannte Seite nicht konsequent. An einer Stelle heißt es, dass aus Rücksicht auf ältere Browser das label-Tag nicht um das input-Tag angeordnet werden solle. Und in ihrem Kontaktformular, das als Beispiel angeführt wird, machen sie's dann doch!
char 20 Jan 2007, 16:04

Was mich ein bisschen an der Liste stoert, ist, dass man die Hoehe der li-Elemente explizit angeben muss, damit der Abstand nach unten zum nachsten Eingabefeld stimmt.
Besser waere, wenn sich der li-Block automatisch so vergroessern wuerde, dass das Eingabefeld auch noch davon umschlossen wird. Das ist aber nur moeglich, wenn man nach dem Eingabefeld noch innerhalb des li ein weiteres (leeres) z.B. div-Element mit style="clear:both;" einfuegt. Leider ist das semantisch gesehen Muell.

Hat da jemand eine andere Idee?
Ralph
02 Jan 2009, 08:53

Auch wenn ich von einem aktuelleren Beitrag aus dem Jahr 2oo8 (Grundlagen der Gestaltung von Formularen auf diesen Beitrag aufmerksam gemacht wurde, finde ich diese Art immer wieder hilfreich. Danke.

Ralph