Webkrauts Logo

Webkrauts Webkrauts Schriftzug

- für mehr Qualität im Web

Verrückte Formulare

Wir haben noch nicht alle älteren Artikel nachbearbeitet. Das bezieht sich in der Regel nur auf die Codebeispiele, die noch nicht optimal dargestellt werden.

Verrückte Formulare

Nachdem Eric Meyer sein Reset-Stylesheet vorgestellt hat, wurde er gefragt weshalb er nicht einfach den universellen CSS-Selektor (*) benutze um die Voreinstellungen des Browsers zurück zu setzen. Er wollte die Eigenschaften aller Elemente außer Formularelementen löschen. Und das geht bei heutiger Browserunterstützung nur indem man alle Elemente aufzählt, die man ansprechen will und die weglässt, die nicht betroffen sein sollen – die Formularelemente.

Das brachte die Frage auf, weshalb er sich überhaupt Gedanken über Formularelemente machte, und er sagte es läge an ihren „angeborenen Verrücktheiten“. Er findet, dass es unmöglich ist Formulare mit CSS wie es heute ist zu beschreiben. Und selbst wenn sie durch CSS beschreibbar wären, dann wären wir mit dem Ergebnis nicht zufrieden. Das Gestalten von Formularelementen wird also auf weite Sicht eine sehr fragile Angelegenheit in unserer Branche sein.

Eric Meyer hat sich diesem Thema jetzt in einem sehr langen Artikel angenommen und er erscheint hier in deutscher Übersetzung:

In diesem Text werde ich nur die Oberfläche dieses ganzen Durcheinanders ankratzen. Aber zuerst eine Warnung: Das wird ein langer Artikel. Und, wie Bette Davis einmal sagte: Schnallt euch gut an, es wird eine unruhige Fahrt.

Fangen wir mit einem scheinbar einfachen Element an: Einer Checkbox. Hier sind zwei in Firefox, die eine markiert, die andere ohne Markierung:

Gut, doch nun eine Frage: Was soll passieren, wenn diese Checkbox padding: 10px; zugewiesen bekommt? Nimm dir Zeit und denke auch an die Details.

„Das ist einfach“, könntest du sagen. „Es gibt einen 10-Pixel-Abstand zwischen dem Häkchen und dem Rahmen der Box.“ Und vielleicht hast du recht. Aber nun stellen wir uns die selbe Frage für die Checkboxen von Safari:

Siehst du wie unbeschwert das Häkchen aus der Box herausragt? Wenn wir jetzt Padding (Innenabstand) hinzufügen, ist das Häkchen dann von der Box umgeben – bleibt es also gleich groß während die Box größer wird – oder wird der Haken größer und ragt weiterhin aus der Box heraus? Und da muss man sich noch keine Gedanken über den Schattenwurf machen oder über den Glaseffekt bei der markierten Checkbox. Mache dir einfach nur Gedanken um das Häkchen. Nimm dir wieder Zeit um alle Zusammenhänge zu verstehen.

Okay. Jetzt solltest du eine Antwort haben. Die traurige Wahrheit ist: Wie auch immer du dich entschieden hast, deine Entscheidung war falsch. Ja, das war jetzt unnötig scharf formuliert: Vielmehr ist deine Entscheidung nicht richtig. Sie kann es nicht sein, weil es keine definitive Antwort auf diese Frage gibt.

Das heißt, wenn ein Browser das Verändern von Formularelementen erlaubt, dann tut er das im Blindflug, wenn man die Spezifikation betrachtet. Die Leute, die die Browser programmierten haben geraten. Ohne Zweifel waren das intelligente Vermutungen, aber trotzdem bleiben es Vermutungen.

Warum also nicht einfach die Antworten festlegen? Wir müssen feststellen, dass das ein wenig komplizierter ist als erhofft. Nehmen wir Checkboxen (bitte!). Das sind doch ersetzte Elemente, oder? Wir haben ein input-Element, das durch ein Symbol ersetzt wird, ähnlich wie ein img-Element durch das Bild ersetzt wird. Und das Symbol ändert sich, wenn die Checkbox angewählt wird. Das ist fast wie bei einem Bildwechsel durch JavaScript. Das Aussehen der Checkbox ist in keiner Weise definiert, den Browsern steht es also frei es zu tun wie wir das weiter oben gesehen haben.

Das Bedeutet also, dass das „Innere“ dieser Art von input-Elementen – die Checkbox (aktiviert oder nicht) – eine Black Box ist, aus CSS-Sicht zumindest. Es gibt zum Beispiel nichts in der Struktur des Dokuments oder im Inhalt, welches das Häkchen beschreibt. Man kann das Häkchen nicht bewusst als Inhalt definieren und die Checkbox als Element, welches das Häkchen umgibt. Sollte Padding dann überhaupt angewandt werden? Vielleicht.

Aber wenn es angewandt werden sollte, und die Checkbox ein ersetztes Element ist, dann würde das Definieren einer Hintergrundfarbe und Padding bedeuten, dass beides um das gesamte Symbol – das ganze Symbol, also Häkchen und Box – herum passiert statt innerhalb der Box. Das ist nur eine logische Schlussfolgerung, wenn das Element ein ersetztes ist. Es ist aber total _un_logisch, wenn du ein visueller Typ bist, der diese Checkbox rot füllen möchte.

Also: Ist eine Checkbox eine Kombination von einer Element-Box, die einen Inhalt umgibt, oder ist sie ein komplett ersetztes Element? Welcher Hintergrund- bzw. Padding-Effekt sollte greifen?

Um noch ein wenig Öl ins Feuer zu gießen, betrachte folgendes:

  • Was passiert mit dem Häkchen, wenn das input kursiv gestellt wird, entweder direkt oder durch Vererbung? Was, wenn es als fett ausgezeichnet wird? (Nehmen wir mal an, dass das Häkchen aus einer Schriftart mit kursiven und fetten Schnitten entnommen ist.) Was, wenn überhaupt, passiert mit der Box in diesen Fällen?
  • Wenn text-decoration: underline auf die Checkbox angewandt wird, sollte dann nur das Häkchen unterstrichen werden oder die ganze Checkbox? Ändert sich deine Antwort, wenn du Padding in deine Überlegungen einbeziehst?
  • Welchen Effekt sollte line-height auf die Checkbox und ihren Inhalt haben? Was soll z.B. passieren, wenn du input[type=checkbox] {line-height:3em;} festlegst? Und vergiss nicht, dass die Zeilenhöhe meist durch Vererbung bestimmt wird.
  • Sollten Breite und Höhe einer Checkbox beachtet werden? Und wenn, beziehen sie sich dann auf das gesamte Element oder nur auf den „Inhalt“ (also das Häkchen)? Wenn du dich für das erste entscheidest, was geschieht dann mit dem Häkchen? Sollte es die selbe Größe behalten und an irgendetwas ausgerichtet werden oder sollte es mit der Checkbox skaliert werden?

Die Antworten auf diese Fragen haben sich als höchst unterschiedlich herausgestellt – die einen nehmen an, dass es sich um ein Box-und-Inhalte-Modell handelte, andere gehen von einem ersetzten Element aus. Schau dir doch einfach die knifflige Frage in der Mitte des letzten Punktes an. Was bedeutet Breite überhaupt, wenn es um Formularelemente geht? Geht es nur um den Inhalt, wie bei nicht-ersetzten Elementen oder geht es um die ganze Element-Box, Rahmen und all das, wie bei ersetzten Elementen?

Wenn man den letzten Entwurf der CSS 2.1-Spezifikation heranzieht sind alle inputs (eigentlich alle Formularelemente) ersetzte Elemente, genau wie Bilder. Also keine Hintergrundfarbe innerhalb von Checkboxen, keine Veränderung durch kursiv stellen oder fetten oder festlegen der Zeilenhöhe. Vertical-align verschiebt die Box als ganzes und Breite und Höhe werden auf die gesamte Box angewandt.

Generell findest du das vielleicht akzeptabel, aber wie ich schon sagte: CSS 2.1 betrachtet alle Formularelemente als ersetzt. Das betrifft also auch Eingabefelder und textarea-Elemente. Und das können die meisten Menschen nicht akzeptieren. Ein Beispiel: Eine Zuweisung von vertical-align: baseline würde die Unterkante des Eingabefelds auf die Grundlinie des umgebenden Textes gerückt werden, statt den Text im Eingabefeld an dem Text drumherum auszurichten. Fast jeder bevorzugt das zweite Verhalten und die meisten Browser verhalten sich nach dieser Präferenz, aber das sollte nicht passieren. Tatsächlich ignorieren die meisten bekannten Browser die Annahme der Spezifikation, dass Formularelemente ersetzte Elemente sind.

Und dabei haben wir noch nicht einmal die schwierigen Fälle betrachtet, wie Selectboxen. Hier sehen wir eine in Firefox, „geschlossen“ und „geöffnet“:

Lass uns direkt zur offensichtlichen Frage kommen: Was soll passieren, wenn man select {padding: 10px;} deklariert? Es gibt alleine drei verschiedene Möglichkeiten für die geschlossene Selectbox:

Such dir deine bevorzugte Variante aus… Fertig? Sollte das selbe passieren, wenn das Select geöffnet ist und alle Optionen zeigt? Und wenn wir schon dabei sind, sollte das selbe mit Safaris Selectbox passieren?

Auch die Feststellung, es wäre alles in Ordnung, wenn Safari sich genau so verhalten würde wie alle anderen Browser auch, hilft hier nicht weiter. Es gibt keine festgelegte Form für Selectboxen oder für irgendein Formularelement. Im Fall von Safari werden diese Dinge direkt aus OS X heraus ins Dokument platziert – genau die Definition vom ersetzten Element. (Und trotzdem, Browser behandeln die Elemente als wären sie nicht ersetzt.) Der Explorer macht das selbe, was der Grund dafür ist, dass Formularelemente unendlichen z-index (im IE6 und früher) zu haben scheinen. Sie werden vom Betriebssystem gezeichnet, nachdem alles andere auf der Seite bereits fertig ist. Firefox, auf der anderen Seite, bringt seine eigenen Formularelemente mit, weshalb sein Verhalten betriebssystemübergreifend gleich ist und er keine Probleme mit der Zeichenreihenfolge wie der Explorer hat. (Das ist auch einer der Gründe, weshalb Firefox auf vielen Systemen länger zum Starten benötigt; Anstatt für Dinge wie Formularelemente die Funktionen des Betriebssystem zu benutzen, muss er seine eigenen mit sich herum schleppen.)

Nun könnten wir in eine Diskussion verfallen, ob Formularelemente immer vom Betriebssystem entlehnt sein sollten oder nicht, was uns in HCI-Verfechter auf der einen und Designern auf der anderen Seite der Debatte aufteilen würde. Aber das machen wir nicht (zumindest nicht an dieser Stelle). Wir gehen einfach mal davon aus, dass Formularelemente gestaltet werden sollten, weil uns das direkt zum Dilemma führt: Wie genau?

Wir können das Selectbox-Rätsel noch ein wenig interessanter machen: Wenn man zum Beispiel das definierte:

select {padding:10px;}
option {padding:10px;}

Und was jetzt? Es ist ja von dem Moment an dem das Select erscheint, eine der Optionen zu sehen, oder? Vielleicht ist es aber auch eine spezielle Funktion des Selects, nur den Inhalt eines option-Elementes zu kopieren, wenn noch nichts angewählt ist um irgendwas anzuzeigen. Wir wissen es nicht. Nehmen wir einmal an, dass das was wir in der Selectbox sehen tatsächlich ein option ist. Es ist entweder die erste oder eine, die mit einem selected-Attribut versehen ist. Und was passiert bei folgendem?

select {padding: 10px;}
option {padding: 10px; border-bottom: 1px solid gray;}
option[selected] {font-style: italic; background: yellow;}

Juhuu! Jetzt könnte ich tausende Fragen stellen, aber ich werde mich auf eine der schwierigeren beschränken: Sollte die graue Linie an der Unterseite des @option@s gezeigt werden, wenn die Selectbox „geschlossen“ ist, oder nur, wenn sie „geöffnet“ erscheint? Oh, und hier ist noch eine gute Frage: Betrifft das Padding für die Selectbox auch das Dropdown-Menü, welches die Optionen enthält oder nicht?

Das schöne daran ist, dass egal welche Antwort für dich perfekt offensichtlich ist, es findet sich jemand, der findet, dass deine Antworten komplett falsch sind. Und umgekehrt.

Übrigens sind das die einfacheren Fälle. Wenn du an Radiobuttons und Dateiladefelder und deren Gestaltung denkst, dann wird’s erst richtig kompliziert. Ich meine, schau dir den Unterschied zwischen Firefox und Safari an:

Schon die Frage nach Padding und Hintergrund ist spannend genug. Aber jetzt werfen wir mal noch Text- und Schriftgestaltung in den Ring und bringen Rahmen und Vordergrundfarben ins Spiel. Das gibt eine Unmenge an komplexen Rätseln. Dieser Schmerz!

Und jetzt glaube nicht, dass die Gestaltung leichter wird, genauer gesagt macht uns das Safari-Team das Leben noch ein Stück schwerer. Wenn du ihren Artikel zu „Textfeldern“ gelesen hast, siehst du, dass Safari es bald möglich machen wird alle Arten von Dingen zu Eingabefeldern zu machen. (Wenn du dir heute schon Nightly-Builds (also Entwicklungsversionen) von Safari herunterlädst, erlaubt er es schon.) Von den neun Beispielen sind nur zwei mit heutigem CSS umzusetzen – und auch da ergeben sich Fragen, wie die nach der Ausrichtung an der Grundlinie (wie zuvor erwähnt).

Um die Formularelemente in irgendeiner bedeutungsvollen Art und Weise zu gestalten, wird es nötig sein ein ganzes Paket neuer Attribute und Pseudoklassen (oder vielmehr Pseudoelemente) zu erfinden und zu beschreiben wie sie sich untereinander verhalten. Das ist aber leichter gesagt als getan. Es hat länger als fünf Jahre gedauert CSS 2.1 nicht fertig zu stellen, und das ist nur eine umformulierte und vereinfachte Version von CSS 2. Stelle dir vor wie lange es dauern würde einen neuen Teil CSS zu erfinden.

Nicht, dass irgendjemand daran arbeiten würde. Das, was dem am nächsten kommt ist das Basic User Interface Module, welches am 11. Mai 2004 (ja, das ist drei Jahre her) die Candidate Recomendation erhalten und sich seit dem nicht bewegt hat. Es gibt kein anderes Modul für Formularelemente. Es gibt Dinge aus verschiedenen Modulen die anwendbar wären (wie Das Box-Modell, Erstellte und ersetzte Elemente oder Linien), aber keines geht explizit auf Formularelemente ein, das heißt ihre Relevanz ist zumindest bestreitbar.

In diesem Vakuum gibt es Vorstöße von Browsern in verschiedenen Stärken: Wie wir gesehen haben nimmt Safari eine Vorreiterrolle ein. Der Explorer erlaubt ein wenig Gestaltung aber nicht viel. Und Firefox erlabt mehr – aber vor gar nicht all zu langer Zeit hat er alle Versuche Formulare zu gestalten ignoriert. Opera blockte alle Versuche der Formulargestaltung ab, als ich zuletzt nachgeschaut habe.

Weil es keine festgelegten Antworten auf diese Fragen gibt und jeder Browser rät, was zu tun ist, muss es Konflikte geben. Wenn einer von fünf Browsern (beispielsweise) für den Abstand von Text und Rahmen in Textfeldern Padding benutzt, dann bedeutet eine Anweisung wie * {padding: 0;}, dass Text und Rahmen aneinander kleben. Die anderen vier würden es jedoch komplett ignorieren. Man könnte dann input[type="text"] {padding: 2px;} definieren, was aber wenn einer der anderen vier diese Anweisung interpretiert und das Padding hinzufügt, weil er das gesamte Innere und nicht nur den Text als Inhalt sieht?

Wie langjährige Leser von meyerweb bereits gemerkt haben gibt es in diesem Text keine Antworten. Wie viele meiner längeren Texte stellt er viele Fragen und regt (wie ich hoffe) zum Nachdenken an. Was ich auch hoffe erklärt zu haben ist meine Aversion gegen CSS für Formulare und damit weshalb ich in meinem Reset-Stylesheet einen großen gruppieren Selektor benutze, anstatt des universellen Selektors. Ich verstehe weshalb so viele lieber den Universalselektor benutzen wollen: Es ist viel einfacher zu tippen und es sind viel weniger Zeichen. Und während ich normalerweise jemand bin, der gerne Zeichen spart, denke ich, dass diese Zeichen sich lohnen.

Zum Autor:

Eric Meyer ist Autor von zwei Standardwerken über CSS, „Eric Meyer On CSS“ und „More Eric Meyer on CSS“. Letzteres wurde unter dem Titel „Eric Meyer’s CSS“ auch auf deutsch veröffentlicht. In seinem Blog meyerweb.com teilt er seine Gedanken zu den Themen HTML, CSS und Webstandards mit. Zudem ist er mit „An Event Apart“ Mitveranstalter von und Sprecher bei einer der wichtigsten Serien von Workshops zum Thema Webdesign.

Übersetzung: Eric Eggert

Kommentare

Stefan David

Stefan David (Webkraut)
am 31.05.2007 - 13:59

Klasse Übersetzung Eric. Den Original-Artikel kannte ich im schon länger, es ist aber schön, ihn noch einmal auf deutsch zu lesen.

Gerade heute schlage ich mich wieder mit Formulargestaltung rum. Es ist frustrierend, was schon ein BUTTON für Probleme machen kann, wenn die Gestaltung wirklich pixelgenau sein soll. Stichworte: Text als Beschriftung erhalten, Aussehen per Sliding-Doors-Technik steuern.

Abgesehen davon bin ich aber der Meinung, dass man nicht nur wegen der im Artikel genannten Probleme sondern auch aus Gründen der Bedienbarkeit möglichst auf das Stylen von Formularelementen verzichten sollte. Ich konnte schon oft – auch bei erfahrenen Nutzern – beobachten, dass z.B. Eingabefelder für eine Suche nicht als solche erkannt wurden, da sie zu sehr vom gewohnten Browser-/OS-Layout abwichen. Die Folgen für einen Onlineshop sind dann verhehrend. Auch eine Select-Box bringt Frust für den User, wenn sie nicht erkannt wird.

Permanenter Link

GE
am 31.05.2007 - 19:24

Hallo, zu einem Browser-Reset gibt es ja grundsätzlich unterschiedliche Meinungen. Ich mag das eher nicht. Was den Reset auch für Formulare angeht, kann ich dem Autor nur zustimmen.

Der Normal-User hat seinen Lieblings- oder einzigen Browser und hat sich so an das Aussehen der Formulare gewöhnt. Während man sich beim Design einer Seite immer streiten kann, was Priorität hat (Schönheit oder Funktionalität, das "besondere" oder das "gewohnte"), gibt es bei Formularen eigentlich nur eine Antwort: Die Funktionalität ist das wichtigste.

Ein Formular muss ganz einfach so aussehen, wie der Besucher es von seinem Browser kennt und erwartet. Deshalb denke ich, dass es richtig ist, die Formulare vom Reset auszuschliessen.

Da ich mich um die Gestaltung der Formularelemente dann nicht kümmern muss, kommt das auch meiner Faulheit entgegen ;-)

Permanenter Link

Webstandard-Team
am 01.06.2007 - 07:52

Respekt, Eric, klasse Fleissarbeit! Genau diesen Artikel müsste man denjenigen vorlegen, die einen täglich mit den Fragen bombardieren, warum vor allem die Formularelemente nicht überall gleich aussehen bzw. identisch verhalten.

Permanenter Link

Bertram Simon
am 04.06.2007 - 10:26

Ich habe das Thema Webdesign von HTML-Formularen aufgegeben, nachdem ich festgestellt habe, dass die Windows XP Themes eine Formatierung völlig unmöglich machen.

Permanenter Link

Isotopp
am 05.06.2007 - 08:56

Ich habe Farben, Fonts und Größen in einem Betriebssystem so eingestellt wie sie für mich gut und richtig sind. Und ich bin sehr dankbar dafür, daß es wenigstens eine Komponente auf Webseiten gibt, die wegen der o.a. Probleme nicht nur problemlos wiederkennbar, sondern auch problemlos lesbar bleibt.

Das sehe ich auch als Sicherheitsfeature - keine 0px breiten Texteingabefehler, die von JS mit irgendwelchem Scheiß gefüllt werden.

Permanenter Link

Jürgen Brocke
am 06.07.2007 - 21:59

Hey, danke für die Übersetzung. Sehr genialer Artikel. Ich bin auch der Meinung, das dieses Problem nicht zu lösen ist und es kein Standard-Rezept für die Brause geben wird. Das wird noch schlimmer, jeder Browser-Klempner kocht sein eigens Süpchen, da wird man in Zukunft immer wieder neue Hacks verwenden müssen.

Permanenter Link

Die Kommentare sind geschlossen.