Formulare gestalten mit Formalize

Hier erfahren Sie......wie Sie Formulare ansprechend gestalten ...wie Sie in viele Browser Ihren Code interpretieren...wie Sie Formalize zur Gestaltung einsetzen

Wer schon einmal ein Formular mit CSS gestyled hat, der weiß, wie kniflig das sein kann. In seinem äußerst lesenswerten Blogbeitrag "Formal Weirdness", zu Deutsch etwa "Förmliche Schrägheiten",   setzt sich CSS-Guru Eric Meyer ausführlich mit den Problemen auseinander, die entstehen, wenn  HTML-Formulare und CSS aufeinandertreffen. Das Kernproblem: Wo die  CSS-Spezifikation aufhört, beginnt der Wildwuchs. Gemäß CSS-Spezififikation sollen Browser alle Input-Elemente wie ersetzte Elemente behandeln. So wird zum Beispiel ein

bei der Anzeige durch die Abbildung einer Checkbox ersetzt, vergleichbar mit dem Ersetzen von

durch die entsprechende Grafik. Weil CSS-seitig nicht spezifiziert ist, wie das Innere einer Checkbox auszusehen hat, sind Browser bei ihrer Darstellung völlig frei. Sie greifen auf im  Betriebssystem hinterlegte oder im Programm verankerte Symbole zurück. Klickt man die  Checkbox an, wird das eine Symbol durch ein anderes ausgetauscht. Das Problem dabei ist, dass  der Webdesigner keinen Einfluss auf das Innere eines ersetzten Elementes hat. Das ist vielleicht korrekt so, aber im Fall von Formularelementen alles andere als wünschenswert, wie folgendes  Beispiel zeigt:

Eigentlich müsste sich verticalalign:baseline so auswirken, dass die Unterkante des Eingabefeldes mit  der Unterkante des umgebenden Textes auf eine Höhe gebracht wird. In der Praxis wird man aber den im Eingabefeld enthaltenen Text mit dem umgebenden Text auf der selben Grundlinie  platzieren wollen - und so arbeiten auch die meisten Browser.

In den seltensten Fällen lässt sich die Spezifikation derart eindeutig umdeuten. Wie etwa soll ein  Browser Padding bei einer Checkbox umsetzen? Laut Spezifikation muss er es rund um das ersetzte Element platzieren, doch aus Sicht des Designers könnte auch der Abstand des  Häkchens zum Rand der Checkbox eine wünschenswerte Option sein. Auf welche Bestandteile  einer Checkbox sollen sich die Parameter height und width auswirken?

In seinem erwähnten Blogbeitrag führt Meyer zahlreiche weitere Beispiele für derlei  Ungenauigkeiten auf. Er zieht daraus zwei Schlüsse. Erstens bedarf es einer Erweiterung der  CSS-Spezifikation um zahlreiche Pseudoklassen und Eigenschaften, um Formularelemente  präzise designen zu können. Zweitens sollten CSS-Resets wie Meyers weit verbreiteter "Meyer  Reset" die Formularelemente unberührt lassen, um unerwünschte Nebenwirkungen zu vermeiden.

Formular-Styling mit Formalize

Es gibt eine ganze Reihe von CSS-Frameworks, mit denen Sie Formulare trotz aller  Schwierigkeiten recht zügig auf ein browserübergreifend wiedererkennbares Layout trimmen  können. Wohl das bekannteste ist Formalize von 960.gs-Entwickler Nathan Smith. Smith hat  damit ein Formulardesign geschaffen, das zu vielen gängigen Webdesigns passt, ohne langweilig oder übermäßig auffällig zu wirken. Alle Elemente wirken leicht eingelassen, alle Knöpfe haben  dasselbe Aussehen, inklusive dem Button-Tag. Soweit der Browser dies unterstützt, erhält das im  Fokus befindliche Formularelement einen leichten box-shadow. Über Javascript hilft Smith  Browsern auf die Sprünge, die das HTML5-Attribut placeholder noch nicht unterstützen. Sie  können die im HTML codierten Platzhalter bei aktiviertem Javascript dann trotzdem korrekt  anzeigen. Formalize enthält verschiedene Fassungen des Javascripts, die gängige Libraries wie jQuery, MooTools, Dojo, YUI und ExtJS berücksichtigen.

Formalize im Detail

Smith weist ausdrücklich darauf hin, dass Formalize ein Framework ist, das projektspezifisch  angepasst werden will, anders als das zum Beispiel bei seinem Gridsystem 960.gs der Fall ist.

Nicht nur deshalb sei jedem, der Formulare mit CSS gestalten will, auch ein ausführlicher Blick in  den Formalize- Code empfohlen. Ein paar interessante Fundstücke: Die Zeilen 1 bis 27  enthalten Klassen wie .input_tiny und .input_xlarge, über die sich die Breite von Eingabefeldern steuern lässt. Die Breiten sind in Pixeln angegeben. Wenn Sie ein flexibles Webdesign umsetzen  möchten (Stichwort responsives Webdesign), sind Sie besser aufgehoben, wenn Sie die Inputs in <div>-Tags mit der Klasse .inputwrapper stecken. Das kombinieren Sie mit folgendem CSS:

Webkit und Input-Type Search

In Zeile 34 verwendet Smith diesen Code, um Chrome, Safari und anderen webkitbasierten Browsern das besondere Styling von Eingabefeldern für Suchbegriffe abzugewöhnen:

Wenn Ihnen die Wirkung dieses CSS noch nicht weit genug geht, sollten Sie mit dem  herstellerspezifischen -webkitappearance arbeiten:

Knöpfe

Wir überspringen die folgenden Zeilen, in denen Formalize dem aktiven Formularelement einen  Box-Shadow verpasst. Weiter geht's ab Zeile 69 und mit dem Styling der Knöpfe. Gemeint sind  hier sowohl die Input-Typen reset, submit und button wie auch das <button>-Tag. Über die  Eigenschaft -webkit-appearance gewöhnt Formalize Webkit-Browsern eine Reihe von layouttechnischen Besonderheiten ab. Anschließend erhalten alle Buttons border-radius und ein  Hintergrundbild. In modernen Browsern wird dieses per linear-gradient gezeichnet, ansonsten als  Datei nachgeladen. Abgeschlossen wird die Regel durch zwei Padding-Eigenschaften, die wegen  des vorangestellte Asterisk nur in Internet Explorer 7 und darunter ihre Wirkung entfalten. Besser,  Sie verzichten auf diesen wenig empfehlenswerten Hack und dienen den alten Internet Explorern das entsprechende CSS über ein per Conditional Comment verlinktes Stylesheet an.  Oder Sie verwenden Paul Irishs Methode, bei der das <html>- oder <body>-Tag mittels  Conditional Comment IE-spezifische Klassen erhalten (bit.ly/7nHf9) - wenn Sie diese alten  Surfbretter denn überhaupt noch unterstützen wollen beziehungsweise müssen.

Texteingabe

Weiter geht's ab Zeile 146, ab der sich Formalize der Formatierung von Texteingabefeldern (das  heißt <textarea> und diverse <input>-Tags) sowie Selects widmet. Sicherlich die herausragende  Eigenschaft ist die Verwendung von

Zu dessen Erklärung müssen wir etwas ausholen. Gemäß dem Standard-Boxmodell errechnet  sich die Breite eines Block-Elements aus dessen Breite zuzüglich Padding und Border (jeweils  links und rechts). Steckt man ein weiteres Block-Element in dieses Element hinein, erhält es automatisch eine Breite von 100 Prozent. Gibt man dem inneren Element nun etwas Padding,  wird letzteres nicht zur Gesamtbreite hinzuaddiert. Vielmehr geht die innere Breite, die dem  Content zur Verfügung steht, zurück. So weit, so gut.

Das Problem: <textarea> und <input type='text'> nehmen auch dann nicht die volle, zur  Verfügung stehende Breite ein, wenn sie per 'display: block' zu Block-Elementen erhoben  werden. Ihre Breite wird durch die HTML-Attribute cols beziehungsweise size bestimmt. Erst wenn Sie diesen Tags mit 'width: 100%' auf die Sprünge helfen, wachsen sie auf volle Breite -  und steuern direkt in das nächste Problem. Jetzt müssen Sie ein eventuelles Padding manuell von  den 100 Prozent abziehen, sonst wuchern die Eingabefelder aus dem sie umgebenden Elternelement heraus.

Gerade bei flexiblen Webdesigns sind entsprechende Berechnungen oft nicht mit der notwendigen  Präzision möglich - vom hohen Nervfaktor gar nicht erst zu reden. Deshalb ist es  leichter, wenn man das Box-Modell für Formularelemente ändert. Durch 'box-sizing: borderbox' wird Padding nicht mehr zur Breite von 100 Prozent addiert. Vielmehr sinkt durch Padding der  für den Inhalt zur Verfügung stehende Innenraum, so, als ob es das 'width: 100%' gar nicht gäbe.  So haben Sie sich über die volle Breite erstreckende Input- und Textarea-Elemente und  können diese ohne zusätzliche Verrenkungen mit Padding stylen.