HTML/CSS: Formulargestaltung

[Matthias Apsel]

Om nah hoo pez nyeetz, alle!

Wie gestaltet man am besten ein Formular, gemeint sind hauptsächlich label-input-Paare, das sich möglichst flexibel verhalten soll? Dabei soll „Beschriftung: __________“ immer schön am Doppelpunkt ausgerichtet untereinander stehen. Wie eben in diesem Antwortformular.

#1# eine Tabelle verwenden? Ist zumindest semantisch nicht verkehrt und liefert ohne viel CSS ansprechende Ergebnisse.

#2# display: table-*? Dann kann ich auch gleich eine Tabelle nehmen. Das ist ehrlicher.

#3# <label>… <input></label> mit display: block fürs input? Da müssen die Doppelpunkte in das Markup oder aufwändig positioniert werden

#4# <label>…</label><input><br>? Hier muss ich feste (Mindest-)Breiten für das label vorgeben.

#5# <dt><label>…</label></dt><dd><input></dd>? Nicht wirklich, oder?

#6# flexbox?

#7# ganz anders?

Wie sind eure Erfahrungen? Was ist best practise draußen im harten Leben des Webentwicklers?

Matthias

[MrMurphy]

Hallo,

du wirfst leider einiges durcheinander.

Die label- und input-Paare gehören direkt in ein form-Element. Gestaltet wird das ganze dann per CSS. Zur Gestaltung ist natürlich Flexbox am aktuellsten.

Eine Tabelle ist semantisch schlicht falsch.

"display: table" hat mit der Semantik nix zu tun und kann von Nostalgikern natürlich für die Gestaltung anstatt Flexbox benutzt werden.

Gleiches gilt für "display: block".

br-Element in diesem Zusammenhang? Mir grausts.

Das dl-Element würde noch am besten passen, ist aber nicht erforderlich.

Ein Problem bleiben natürlich die Alte-Browser-Jammerer, obwohl das in der Praxis unerheblich ist. Neue Elemente, die einfacher als Flexbox zu verstehen sind, von "alten" Browsern aber genau so wenig verstanden werden, nutzen die seltsamerweise trotzdem.

Gruss

MrMurphy

[Matthias Apsel]

Om nah hoo pez nyeetz, MrMurphy!

du wirfst leider einiges durcheinander.

Das ist mir durchaus bewusst ;-)

Die Hauptfrage ist:

Was ist best practise draußen im harten Leben des Webentwicklers?

Matthias

[Mitleser]

Die label- und input-Paare gehören direkt in ein form-Element.

Unsinn, das Verpacken in p, ul, ol, dl usw. ist möglich und meist sinnvoll weil ein Formular nicht nur aus LABEL und INPUT besteht

Eine Tabelle ist semantisch schlicht falsch.

Unsinn, ein Formular ist tabellarisch

"display: table" hat mit der Semantik nix zu tun und kann von Nostalgikern natürlich für die Gestaltung anstatt Flexbox benutzt werden.

Nostalgikern? Pragmatikern meinst du. Die großen Seiten die wir bauen funkionieren ab IE 8 oder 9. Da ist Flexbox außen vor

Das dl-Element würde noch am besten passen, ist aber nicht erforderlich.

Die Struktur bei einer Zuordnungsliste ist nicht viel anders als die bei TABLE, nur daß DL unflexibler ist als eine Tabelle

Ein Problem bleiben natürlich die Alte-Browser-Jammerer, obwohl das in der Praxis unerheblich ist.

Kommt darauf an, s.o.

Neue Elemente, die einfacher als Flexbox zu verstehen sind, von "alten" Browsern aber genau so wenig verstanden werden, nutzen die seltsamerweise trotzdem.

Ja, weil viele neue CSS Features wie transition oder box-shadow nett sind aber ihr Fehlen in alten Browsern kein Problem darstellt

[Matthias Apsel]

Om nah hoo pez nyeetz, Mitleser!

Nostalgikern? Pragmatikern meinst du. Die großen Seiten die wir bauen funkionieren ab IE 8 oder 9. Da ist Flexbox außen vor

Und wie baut ihr in diesen Seiten die label-input-Paare? Oder bedient ihr euch auch nur aus der bootstrap-Grabbelkiste?

Matthias

[Mitleser]

Und wie baut ihr in diesen Seiten die label-input-Paare? Oder bedient ihr euch auch nur aus der bootstrap-Grabbelkiste?

Ja, wir verwenden auf einigen Sites Bootstrap. Dort verwendet man das normale Grid System (http://getbootstrap.com/css/#forms-horizontal). Darüber wird den Labels float und eine feste (Prozent-)Größe gegeben.

Wenn das nicht geht (du sagtest daß keine feste Größe gewünscht ist) und man automatisches Layout will, ist eine Tabelle angebracht. Nur die zeigt das gewünschte Verhalten soweit ich weiß.

Ob man das nun mit TABLE oder display: table/row/cell lösen will ist Abwägungssache. Ich würde TABLE verwenden.

Mitleser

[Felix Riesterer]

Lieber Matthias Apsel,

Dabei soll „Beschriftung: __________“ immer schön am Doppelpunkt ausgerichtet untereinander stehen.

die Beschriftung kommt in ein <label>. Dieses mit CSS:

label {
    display: inline-block;
    text-align: right;
    width: 5em; /* kommt auf Deine Beschriftungen an */
}

Die Semantik eines Formulars ist mir selbst eigentlich nicht so wichtig. Ich könnte mir die "Zeilen" als Listenpunkte oder auch als Textabsätze vorstellen. Schön auch, wenn das Ganze in <fieldset> gekapselt ist.

Liebe Grüße,

Felix Riesterer.

[Matthias Apsel]

Om nah hoo pez nyeetz, Felix Riesterer!

Lieber Matthias Apsel,

label {

>     display: inline-block;
>     text-align: right;
>     width: 5em; /* kommt auf Deine Beschriftungen an */
> }

Die feste Breite würde ich gern vermeiden, wenn es möglich ist.

Schön auch, wenn das Ganze in <fieldset> gekapselt ist.

Ja, natürlich. Es geht vordergründig um die Beispiele in der zu überarbeitenden Wikiseite input

Matthias

[dedlfix]

Tach!

Wie gestaltet man am besten ein Formular, gemeint sind hauptsächlich label-input-Paare, das sich möglichst flexibel verhalten soll? Dabei soll „Beschriftung: __________“ immer schön am Doppelpunkt ausgerichtet untereinander stehen. Wie eben in diesem Antwortformular. #7# ganz anders? Wie sind eure Erfahrungen? Was ist best practise draußen im harten Leben des Webentwicklers?

Man kann sich eine Komplett-Lösung an Land ziehen, die nicht nur solche sondern alle möglichen Aspekte der Seitengestaltung schon berücksichtigt hat und obendrein noch responsiv-tauglich ist. Der Platzhirsch ist da wohl Bootstrap. Die generelle Vorgehensweise ist aber auch bei anderen zu finden. Meist wird ein 12er Grid verwendet. Die Beschriftung bekommt 2 oder 3 Spalten, das Eingabefeld die restlichen 10 oder 9. Je nach Größe der Beschriftung können andere Verhältnisse sinnvoll sein. Für schmale Viewports gibt man zusätzlich andere Grid-Klassen, so dass Label und Eingabefeld untereinander zu stehen kommen. (Siehe dort: Bootstrap/CSS Abschnitte Grid und Forms)

dedlfix.

[Gunnar Bittersmann]

@@dedlfix:

Meist wird ein 12er Grid verwendet. Die Beschriftung bekommt 2 oder 3 Spalten, das Eingabefeld die restlichen 10 oder 9. Je nach Größe der Beschriftung können andere Verhältnisse sinnvoll sein.

Ja, goldener Schnitt bspw.

12er Grid ist eine dumme Ausrede von Webentwicklern, Designern zu sagen „Geht nicht“.

Für schmale Viewports gibt man zusätzlich andere Grid-Klassen

Präsentationsbezogenes Markup. Nein. Danke.

LLAP

[dedlfix]

Tach!

Für schmale Viewports gibt man zusätzlich andere Grid-Klassen Präsentationsbezogenes Markup. Nein. Danke.

Das dachte ich mir, dass von Puristen ablehnende Antworten kommen. Schade nur, dass nicht einmal ein Link geschweige denn eine Begründung der plakativen Ablehnung zur Energie des Verstehens beigetragen hat. Jedenfalls kannst du mit einem CSS-Präprozessor deinen eigenen Code deine Höchstansprüchen genügend anders gestelten. Im Allgemeinen ist das auch keine schlechte Idee. Ich las da mal einen Leidensbericht, da hatte jemand ein Projekt von Bootstrap 1 auf 2 umstellen wollen und wenn ich mich recht erinnere auch noch das Design. Mit dem typischen präsentationsbezogenen Markup gab es arge Probeme. Suchen und Ersetzen war nicht die Lösung. Es musste händisch jedes Element und jede Klasse angeschaut werden um zu entscheiden, was neu hinkommen soll. Die Lösung war dann, glaube ich mich zu erinnern, ein Präprozessor, um das HTML sauber zu halten. Bootstrap unterstützt das ja auch, indem es LESS-Dateien anbietet.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix:

Die Lösung war dann, glaube ich mich zu erinnern, ein Präprozessor, um das HTML sauber zu halten.

CSS preprocessors for the best of both worlds (Video gibt’s leider immer noch nicht.)

Bootstrap unterstützt das ja auch, indem es LESS-Dateien anbietet.

Bootstrap unterstützt mittlerweile auch Sass.

Dennoch: Bootstrap mag geeignet sein, eben mal fix einen Prototypen zu erstellen (für mich nicht einmal das), für eine Produktivseite eher gar nicht.

LLAP

[Matthias Apsel]

Om nah hoo pez nyeetz, Gunnar Bittersmann!

Dennoch: Bootstrap mag geeignet sein, eben mal fix einen Prototypen zu erstellen (für mich nicht einmal das), für eine Produktivseite eher gar nicht.

Wie würdest du denn ein Formular mit diesen Vorgaben umsetzen?

Matthias

[Schuer]

Dennoch: Bootstrap mag geeignet sein, eben mal fix einen Prototypen zu erstellen (für mich nicht einmal das), für eine Produktivseite eher gar nicht.

Mensch Gunnar, mach doch mal mehr Graustufen in deine Postings. Nur schwarz-weiß ist inzwischen abgegriffen, damit kriegst du heute keine Diskussion mehr spannend.

Viele Grüße _Dirk

[Tabellenkalk]

Hallo,

Mensch Gunnar, mach doch mal mehr Graustufen in deine Postings.

du meinst grau und blau?

Gruß Kalk

[Schuer]

du meinst grau und blau?

Nein, aber passend zum Tagesgeschehen:

»It is not as simple as that. It’s not a black and white issue. There are so many shades of gray.« »Nope.« »Pardon?« »There’s no grays, only white that’s got grubby. I’m surprised you don’t know that.«

— Pratchett

[Gunnar Bittersmann]

@@Schuer:

Mensch Gunnar, mach doch mal mehr Graustufen in deine Postings.

Zwischen Framework verwenden und Framework nicht verwenden liegt gegen das Framework arbeiten. Und das ist sicher die schlechteste Variante.

LLAP

[Schuer]

Zwischen Framework verwenden und Framework nicht verwenden liegt gegen das Framework arbeiten. Und das ist sicher die schlechteste Variante.

Aber was hat das mit Bootstrap zu tun?

Natürlich sollte man sowas wie Bootstrap nur dann einsetzen, wenn es sinnvoll für die Entwicklung der Website/Webapp erscheint und dessen Anforderungen unterstützt. Und um die Chance darauf zu erhöhen, sinnvoll zu sein, gehört oftmals dazu, Bootstrap nicht einfach fertig generiert ins Projekt zu schmeißen, sondern es stattdessen in den hoffentlich vorhandenen Frontend-Workflow zu integrieren. Sprich: Mit Sourcen (LESS oder Sass) zu arbeiten, Mixins oder Funktionen zu nutzen, Variablen anzupassen, das Grid aufs Projekt anzupassen, keine unbenutzen Komponenten einzubinden, etc.

Wenn die Umgebung geeignet ist und Bootstrap sinnvoll integriert wird, kann der Benefit ungemein groß sein. Man erhält ein umfangreiches Framework, das eine Vielzahl vorgefertigter Module enthält, modular und anpassbar ist, auf Best Practices moderner Webentwicklung basiert, umfangreich dokumentiert ist, intensiv getestet wurde, sich in aktiver Entwicklung befindet und weltweit unter Entwickler_innen bekannt ist, so dass es keine Hürde darstellt, falls ein vorhandenes Frontend-Entwicklungsteam erweitert werden soll.

Aber natürlich kann Bootstrap auch völlig ungeeignet für ein Projekt oder die Arbeitsweise bestimmter Entwickler_innen sein. Das weiß man dann hoffentlich vorher oder merkt es schnell genug.

— Diese Pauschalmeinungen zur Webentwicklung, wie sie hier oft angebracht werden, finde ich ziemlich lame und wenig hilfreich.

[1UnitedPower]

Hakuna matata!

Wie sind eure Erfahrungen? Was ist best practise draußen im harten Leben des Webentwicklers?

Das ist eine spannende Frage. Ich werf einfach mal ein paar lose Gedanken in die Runde:

1. Wo Benutzereingaben fällig werden, da werden Fehler gemacht und da sollte es entsprechende Fehlermeldungen geben. Die Meldung sollte direkt am Formularfeld platziert werden und nicht freistehend am Anfang oder Ende. Auch das sollte man von Beginn an beim Entwurf des Formulars berücksichtigen. Dabei sollte man auch gleich an den Fall denken, dass ein Eingabefeld unterschiedliche Fehler prodzieren könnte, die entweder simultan oder isoliert auftreten können.

2. Formulare Ausfüllen ist eine zeitraubende, nervige Tätigkeit, wir sollten es unseren Nutzern so leicht wie möglich machen. Es gibt Eingabefelder, die tauchen in jedem zweiten Formular wieder auf, zum Beispiel für Vor- und Nachnamen. Für diese Fälle gibt es das autofill-Attribut. Es gibt beim W3C eine schöne Liste über häufig gebrauchte Formularfelder.

3. <label for="name">Name</label><input id="name"> oder <label>Name<input></label>? Das ist mehr als nur Geschmackssache. Die erste Variante hat den Vorteil, dass man <label> und <input> auch getrennt platzieren kann, zum Beispiel in verschiedenen Tabellenzellen oder jeweils in einem <dt>- resp. <dd>-Element. Die Variante wird aber äußerst ungebräuchlich, wenn dynamisch neue Formularfelder hinzukommen können. Wir stellen uns einen Internetshop vor und der Nutzer soll in der Lage sein beliebig viele Adressen zu hinterlegen. Dafür gibt es einen Button im Formular, der bei Betätigung die entsprechenden Felder für Straße, Postleitzahl etc. ergänzt. Die Funktion, die das realsiert, wird recht komplex, weil sie für jedes Feld eine eindeutige ID erzeugen muss. Hier bietet es sich an, das <input>-Element im <label>-Element zu verschachteln, auf diese Weise ist die Zugehörigkeit impliziert modelliert und die Funktion für das Erzeugen der Formularfelder kann entsprechend simpel gehalten werden.

4. Formularfelder erfordern manchmal weiterführende Erklärungen, zum Beispiel sollte eine Checkbox für "AGB akzeptieren" auch auf die AGB verlinken. Die Checkbox befindet sich typischerweie am Ende eines Formulars, da wäre es sehr ärgerlich für den Benutzer, wenn durch einen Klick auf den Link, alle Eingaben verloren gingen, die er bis dahin gemacht hat. Solche Links sollte deshalb mit target="_blank" ausgezeichnet werden.