nicht angemeldet
Ansatz für flexible, mehrspaltige Formulare
Beschreibung eines Ansatzes für ein Webformular, das mehrspaltig aufgebaut ist und sich in seiner Breite vollständig dem umgebenden Inhaltsbereich anpasst.
(Der Artikel ist parallel auch auf Englisch im Blog des Autors veröffentlicht worden: »Approach to flexible multi-column forms«)
»Flüssige« Webformulare?
Wenn es darum geht, ein Webformular in ein flüssiges Layout einzubauen, haben wir gerne ein paar Gründe zur Hand, warum Webformulare pixelbasiert sein sollten. Deshalb, weil uns natürlich vollkommen klar ist, dass Formularelemente zum Browser/System gehören und nur selten dem Webautor gehorchen (bzw nur begrenzt in dessen Zuständigkeit fallen). Das ist eine recht fundamentale Sichtweise. Tatsächlich ist das Styling von Webformularen harte Arbeit, sogar wenn sie pixelbasiert sind, und es kann in einen echten Höllenjob ausarten, wenn die Anforderungen heißen: mach' sie flexibel.
An dieser Stelle fragen wir uns: weshalb sollte ein Webformular denn eigentlich skalierbar sein? Warum viel Zeit und Aufwand investieren, nur um ein Formular zu entwickeln, dessen Eingabefelder flexible Breiten haben? Macht das Sinn?
Ja, es kann dann sinnvoll sein, wenn das Formular mehrspaltig aufgebaut ist und ein breiteres (weil mitwachsendes) Formular seinen Eingabefeldern ermöglichte, Inhalte aufzunehmen, die ansonsten in einem schmalen und pixelbasierten Formular abgeschnitten würden. Einspaltige Eingabefelder sind hoffentlich jederzeit lang genug für ihre Inhalte, aber ein mehrspaltiges Formular könnte durchaus von flexiblen Breiten profitieren.
Noch ein letzter Gedanke: warum wollen wir überhaupt ein mehrspaltiges Formular anstelle eines Einspaltigen verwenden?
Das hat mit dem Buzzword »Erwartungskonformität« zu tun und zielt ab auf den Wunsch nach Eingabefeldern, die in ihren Ausmaßen den Inhalten entsprechen, die sie aufnehmen sollen. So erfordert beispielsweise die Angabe des Nachnamens des Benutzers ein längeres Eingabefeld als das Feld für die paar Zeichen seiner Hausnummer. Aus dieser Sichtweise heraus mag eine Abweichung zwischen Feldlänge und der Menge an Inhalt (sofern sich dieser einschätzen lässt) den Benutzer verwirren. Und weil mehrspaltige Formulare Eingabefelder mit unterschiedlichen Längen ermöglichen — unser Nachfolgendes tut dies jedenfalls und verwendet die Längen 25%, 50%, 75% und 100% — können solche Formulare hoffentlich den Erwartungen des Benutzers entsprechen.
Ansatz für ein flexibles, mehrspaltiges Formular
Aufbau
Wir benötigen folgende Dinge:
- Einen Container/Wrapper, der negative margins nach links und rechts benutzt, um dadurch breiter zu werden als das Formular selbst. Absicht ist, die margins der inneren Elemente auszugleichen und sie dadurch auf eine Linie mit dem Formular zu bringen:
<form class="dm_form& " ..> <div class="form_wrapper"> .. </div> </form>
- Umschließende Labels, um zusätzliche div-Container zu vermeiden:
<label ..> (text) (input) </label> - Einen Haufen von spans, die für Titel und ähnliche Dinge verwendet und dabei als Blockelemente missbraucht werden:
<label ..> <span class="wrapper"> <span class="title">First name *</span> <input class="field" id="firstname" type="text" /> </span> </label>
Code und Beispiel
Ein Funktionsbeispiel des Formulars. Nähere Informationen befinden sich direkt im Quelltext.
Stand: 12. Juli 2008
Browserkompatibilität
Das Formular scheint tadellos in den gängigen Browsern wie Firefox, Opera (ein kleines bisschen unsauber) und Safari zu funktionieren. Die Internet Explorer benötigen ein bisschen Hilfe per Javascript, um die Breite der Eingabefelder um ein paar Pixel zu reduzieren, funktionieren danach aber ebenfalls tadellos.
Lizenz
Der Ansatz für flexible, mehrspaltige Formulare steht unter einer Mach-was-du-willst-Lizenz und kann damit für alles verwendet werden, was man will.
Diskussion
Wir sind uns bewusst, dass das Formular keinen Preis für semantisches Markup gewinnen wird und sprechen deshalb auch von einem »Ansatz«. Allerdings ist es sicherlich nicht bösartig, sondern wir halten es für einen durchaus charmanten Weg, zu einem flexiblen Formular zu kommen, das valide ist, sauber strukturiert ist und in den gängigen Browsern funktioniert.
Feedback ist unbedingt willkommen!
Updates
- 20. November 2007
Es gibt Positionierungsprobleme in Apples neuem Safari 3. Werde mich später drum kümmern, falls nicht sowieso eine ganz neue Version mit einem anderen Ansatz folgt.. - 22. November 2007
Das Formular ist nun auch Safari 3-tauglich, siehe Info. - 12. Juli 2008
Box-sizing im Opera 9 angepasst.
Weitere Formulare und Artikel zum Thema
- The Subtraction Good Form 0.1 (Khoi Vinh)
- The Subtraction Good Form 0.2 (Thomas Maas)
- A form with style (Stu Nicholls)
- CSS-Only, Table-less Forms (Jeff Howden)
- Web Application Form Design (Luke Wroblewski)
- Accessible HTML/XHTML Forms: Beginner Level (WaSP)
- Accessible HTML/XHTML Forms: Intermediate Level (WaSP)
- Accessible HTML/XHTML Forms: Advanced Level (WaSP)
- CSS-Based Forms: Modern Solutions (Smashing Magazine)
- Designtaktiken im Formularkrieg (Gerrit van Aaken)
- Form Layout (Michael Schuerig)
-
Könnte dieser Ansatz sich als nützlich erweisen wenn man seine Webseite auch für Handybildschirme optimieren möchte? (Vorausgesetzt natürlich der Handybrowser versteht einigermaßen CSS und/oder JavaScript)
Oder werden die Input Felder einfach "zusammengequetscht"?
-
Matthias, ja, die Input-Felder würden dann einfach zusammengequetscht. Das kann man auch in dem Beispielformular sehen, wenn man das Browserfenster stark zusammenschiebt. Insofern ist der Ansatz aus konzeptioneller Sicht - nicht aus technischer Sicht, wie du schon sagtest - nicht gerade mobiltauglich. Vier Spalten in 240-320px sind vermutlich kaum sinnvoll, aber ab 480px könnte es dann durchaus nett werden.
Wenn also von Anfang an die Absicht besteht, das Ding für Mobiles zu benutzen, würde ich es als Zweispalter verwenden (entsprechend umstricken), nicht als Vierspalter.
-
Eigenwerbung widerstrebt mir ein wenig, aber da mir mein eigener Layoutansatz mit Floats und prozentualen Breiten deutlich besser gefällt, kann ich's nicht lassen:
http://schuerig.de/michael/blog/index.php/2007/02/22/form-layout/
-
Eine Kombination aus dem Konzept von Dirk und Michael wäre interessant. Denn Konzeptionell werden ja von beiden unterschiedliche Strategien gefahren. Ich denke ab einer maximalen Stauchung (Dirks Ansatz) würde ein Float (Michaels Ansatz) gut tun, da es sonst zu gequetscht wirkt. Ich bin mir aber nicht sicher ob sich so etwas realisieren lässt...
-
@Alexander: Wenn du keine Einwände gegen etwas JavaScript hast, dann habe ich ein geeignetes Hilfsmittel im Angebot
http://schuerig.de/michael/blog/index.php/2007/02/22/size-dependent-layout/
Die Idee dabei ist, per Skript das class-Attribut des body-Elements je nach Fenster und Schriftgröße automatisch passend zu setzen. Die größenabhängigen CSS-Regeln müssen dann jeweils mit body.small oder body.large qualifiziert werden.
-
Michael, ich empfinde es nicht als Eigenwerbung, wenn du einen Link zum gleichen Thema angibst. Im Gegenteil, danke für den Hinweis.
Zu deinem Layoutansatz: Umbrüche aufgrund von floats finde ich innerhalb von Formularen nicht immer sinnvoll. Das typische Kommentar- oder Kontaktformular ist davon sicherlich nicht betroffen, aber bei umfangreicheren Formularen kann es vorteilhaft sein, dass die Positionierung der Eingabefelder und damit die unmittelbare Beziehung erhalten bleiben. Im Gegensatz zu den anderen Contentbereichen einer Seite übrigens, die sich oftmals als eigenständige Elemente verhalten und damit freundlich(er) umgebrochen werden können.
-
Alexander, man könnte Mindestbreiten für das Formular oder den umschließenden Container verwenden, falls nötig. Die inneren Elemente verhalten sich ja abhängig vom zur Verfügung stehenden Raum, insofern müsste man nur an einer Stelle eine Mindestbreite vorgeben, um ungewollte Quetschungen zu verhindern.
-
Moin! Das konsistente Styling von Formularen über Browsergrenzen hinweg ist wohl eins der schwierigsten Themen überhaupt. Insofern bin ich immer über neue Gedankenansätze glücklich.
Was ich an diesem Beispiel aber schlicht nicht verstehe ist, warum zuerst gesagt wird, man wolle auf überflüssige DIV-Container verzichten, um dann im nächsten Schritt alles mit SPAN-Elementen zuzupflastern (die dann auch noch erst auf display:block gebracht werden müssen...).
In einem Intranet-Projekt welches nur unter Firefox laufen musste, habe ich kürzlich sehr gute Erfolge mit den Eigenschaften display:table, table-row und table-cell sowie einer entsprechenden Formularstruktur erreichen können. Das Ergebnis war superskalierbar und vertrug (fast) jede beliebige Anzahl von Elementen in einer Reihe, die sich dann automatisch den verfügbaren Platz geteilt haben.
Leider unterstützt der IE die entsprechenden CSS-Eigenschaften nicht, so daß dieser "Ansatz" tatsächlich nur in klar definierten Umgebungen einsetzbar ist :-(
-
Florian, die spans werden benötigt, um Inhalte ansprechen zu können. Etwa die Titel oder Fehlermeldungen. Außerdem werden umschließende spans innerhalb der labels verwendet, um möglichst unabhängig von paddings und bordern der Eingabefelder zu bleiben (den IEs muss noch ein bisschen mit JS nachgeholfen werden). Dieser Punkt ist übrigens noch nicht richtig rausgekommen im aktuellen Text, habe ich bemerkt: border und paddings, also im Grunde alle wesentlichen Styles, die für Eingabefelder benötigt werden, können beliebig gesetzt werden, ohne an der Grundstruktur des Formulars ansetzen zu müssen -- wie gesagt, bis auf den IE und das bisschen Javascript.
Zurück zu den spans: sie werden deshalb verwendet und als Blockelemente missbraucht, weil die umschließenden labels nur Inlineelemente vertragen. Und umschließende labels waren als Ausgangsbasis gewollt; sie sollten die eigentliche Struktur bilden, ohne dass dafür weitere divs herangezogen werden sollten.
Dein Gedanke mit Tabellenelementen war übrigens gut und sinnvoll, nur bleibt dabei - wie du bereits sagst - der IE auf der Strecke, deshalb musste bei unserem Formular ein anderer Ansatz her.
-
Hallo Florian,
hast du einmal ein Beispiel für deinen Ansatz, mit dem du "sehr gute Erfolge erreichen konntest"? Würde mich interessieren, wie genau diese "Technik" funktioniert.
Danke! :-)
Felix -
Der einzig bisher wirklich funktionierende min-width oder max-widht Ansatz, den ich kenne stammt von der Yaml Fraktion.
Gerade dies ist aber wichtig, wenn sich ein flexibles Layout an IE6 User wendet.