Vielen Dank, Corina!

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

Viele Webdesigner, mich eingeschlossen, kommen zum Internet mit einem grafischen Hintergrund. Wir denken in Bildern, nicht in Quelltext. Als wir zuerst angefangen haben, für das Internet zu designen, haben wir HTML und CSS in ungehobelter Weise – als Mittel zum Zweck – genutzt, um hübsche Kästen im Raum zu arrangieren, ohne die wahre Natur des Kastens oder seines Inhalts zu erfassen. Diese rein visuelle Mentalität zu verändern, ist die höchste zu überwindende Hürde, wenn ein Grafikdesigner erstmalig in Semantik und Webstandards eintaucht. Webstandards wirklich zu verstehen, heißt für den visuellen Designer, die Art und Weise an Design zu denken, grundlegend zu verändern.

Das Wort »grok« (Das Wort wird im Originaltitel und im Text des Artikels verwendet. – Anm. d. Übersetzers) kommt aus Robert A. Heinleins Zen-Hippie-Science-Fiction-Werk Fremder in einem fremden Land. Es ist ein Verb aus der Sprache der Marsianer und bedeutet so etwas wie »vollständig verstehen« oder auch »verinnerlichen«. Es geht darum, eine tiefe und intuitive Einsicht in eine Sache zu erlangen. Um Webstandards wirklich zu begreifen, musst du sie als mehr als nur Mittel zum Zweck verstehen; mehr als nur eine alternative Methode, visuelles Design zu produzieren.

Um Webstandards zu begreifen, ist es nötig, dass der visuelle Designer die Arbeitsweise seines Gehirns ändert und seine fantasievollen Nervenzellen entlang eines neuen Pfades ausrichten. Du kannst deine kreative Energie nicht rein auf die Erscheinung deiner Webseiten kanalisieren, ohne die darunterliegende Struktur zu beachten. Präsentationsbezogenes Denken führt zu präsentationsbezogenem Webdesign, zum Nachteil des Inhalts. Stattdessen musst du zusätzlich strukturell denken, um den Inhalt dabei zu unterstützen, ihn ungefesselt leben zu lassen. Als Webdesigner der mit Standards umzugehen weiß, musst du deine Herangehensweise an Designprobleme diversifizieren und zu gleichen Teilen Autor, Techniker und Künstler werden.

Denke wie ein Autor

Autoren handeln mit Ideen, wobei sie Wörter als Werkzeuge verwenden, um diesen nicht greifbaren Gedanken gerade genug Masse zu verleihen, dass sie in den Geist des Lesers transportiert werden können. Der Stoff eines Wortes ist aus Schichten von Bedeutungen gewoben: bestimmend, mitbedeutend, kontextabhängig und subjektiv. Ein Autor hat zu verstehen, was Wörter auf vielfachen Ebenen bedeuten und muss die Wörter wählen, die die Idee am besten vermitteln.

Semantik ist die Wissenschaft der Bedeutung von Sprache. Verfechter von Webstandards haben den Ausdruck von menschlichen Sprachen geborgt und auf Computer-Auszeichnungssprachen übertragen. Jedes Element in HTML trägt eine angestammte Bedeutung und Bestimmung in sich, die es an den enthaltenen Inhalt weitergibt. Der semantische Wert deines Markups sollte zum semantischen Wert deines Inhalts passen.

Um Bedeutungen im Webdesign zu verstehen, denke wie ein Autor. Erkenne die Bedeutung und die Bestimmung des Inhalts, das Wesentliche der Idee, die du vermitteln möchtest. Benutze dann die Auzeichnungen, als würdest du Wörter benutzen, wähle die richtigen, um deine Ideen zu vermitteln.

Eine Überschrift zum Beispiel fungiert als Titel, um einen Abschnitt des Inhalts einzuleiten. HTML stellt uns Elemente zur Verfügung, die speziell für diesen Zweck entworfen wurden, also sollten Überschriften als Überschriften ausgezeichnet werden. So einfach ist das. Berücksichtige die Wichtigkeit einer Überschrift im Zusammenhang des Dokuments und weise ihr den angemessenen Rang zu: h1 für die wichtigste Überschrift, h2 für die etwas weniger wichtige Überschrift, und so weiter. Mach dir keine Gedanken, wie es aussieht oder wie groß die Buchstaben sind – das ist präsentationsbezogenes Denken. Denke wie ein Autor und konzentriere dich auf die Bedeutung.

Wenn ein Autor die falschen Wörter wählt, werden die Ideen für den Leser unverständlich. Ebenso leidet die Idee, wenn eine Bedeutung, die einem Stück Internet-Inhalt anhaftet und die Bedeutung, die der dieses Stück umgebenden Auszeichnung anhaftet, nicht zusammen passen. Tabellen sind nicht nur falsch für die Seitengestaltung, weil sie codelastig und schwer zu warten sind, sondern auch weil eine Tabelle semantisch nicht ins Konzept passt. Es ist eine mangelhafte Wortwahl. Wenn du das verstanden hast, ist es keine wirklich praktikable Option, eine Tabelle zu verwenden, um das Aussehen deiner Seite festzulegen.

Semantisches Markup zu schreiben, erfordert Verständnis für Beides: den Inhalt und die Auszeichnung, die ihn beschreibt. Du liest richtige Wörter und siehst dir nicht Bilder von wortähnlichen Objekten an. Erweise dem Inhalt den Respekt, den er verdient, indem du ihn in bedeutungsvolles Markup verpackst. Absätze sollten Absätze sein, Listen sollten Listen sein und Tabellen sollten Tabellen sein. Wenn du wie ein Autor denkst, ist das Schreiben semantischen Markups elementar einfach.

Denke wie ein Techniker

Ein Techniker entwickelt Strukturen und Geräte, die bestimmten Kriterien entsprechen, bestimmte Funktionen ausführen und bestimmten Zwecken dienen müssen. Nähte müssen halten, Wände müssen aufrecht stehen bleiben, Getriebe müssen ineinander greifen und sich drehen. Ein Techniker wird das Problem untersuchen, eine effiziente Lösung entwickeln und anschließend die Teile und Materialien auswählen, die der Belastung bei Gebrauch standhalten. Er wird die Folgen in Betracht ziehen, potenzielle Schwierigkeiten vorausahnen und Schritte unternehmen, um katastrophale Fehler zu vermeiden.

Wenn du ein Webdokument konstruierst, denke wie ein Techniker. Dein innerer Autor hat ein Element ausgewählt, weil es eine bestimmte Bedeutung hat, während dein innerer Techniker die Mechanik des Elements und die strukturelle Integrität des Dokuments, in dem es sich befindet, berücksichtigen muss. Auszeichnung gibt Inhalt zusätzliche Bedeutung, rahmt ihn aber auch ein und gibt ihm eine unterstützende Struktur, sodass er richtige Arbeit leisten kann.

Stelle dir HTML-Elemente als Bauteile vor – jedes mit seiner eigenen eingebauten Funktion –, die zusammengebaut und verbunden werden können, um eine größere Funktionseinheit zu bilden. Die Teile müssen genau zusammen passen, mit einem Platz für jede Auszeichnung und jeder Auszeichnung an ihrem Platz; sonst wird das Ganze nicht leisten, wozu es vorgesehen war –, wenn es überhaupt etwas leistet. Standardisierte Spezifikationen sind die Bauanleitung für Webdokumente. Beachte die Standards, validiere dein Markup und CSS, und behebe ernste Fehler, bevor das Ganze zusammenbricht.

Verstehe Markup als Gerüst, das den Inhalt stützt. Du weißt, was jedes Teil tut und wie die Teile zusammenwirken. Wenn dein Dokument passend zusammengebaut wurde, kannst du eine dekorative Schicht darüberlegen, ohne die innere Funktion zu beschädigen. CSS lässt dich die Anordnung und Erscheinungsweise von Elementen verändern, während die eigentliche Bedeutung und Struktur intakt bleiben. Denke wie ein Techniker und baue deine Webdokumente wie eine robuste Maschine.

Denke wie ein Künstler

Künstler bescheren uns umformende Erlebnisse durch die Interpretation der Schönheit. Sie werden durch die sie umgebende Welt inspiriert und möchten diese Inspiration an andere weitergeben. Das Design einer Website ist ein grundlegender Aspekt ihrer Nützlichkeit, der zu kommunizierenden Ideen und der zu vermittelnden Informationen auf eine attraktive und intuitive Art.

Visuelle Designer haben das Künstlerische bereits verinnerlicht. In Bildern zu denken ist ganz natürlich für uns; es ist nichts, was wir uns erst beibringen müssen. Das Internet ist allerdings kein rein visuelles Medium, es ist ein textbasiertes. Es geht darum, Sachen zu lesen und zu nutzen, nicht nur sie zu betrachten.

Wenn du für das Internet gestaltest, denke zuerst wie ein Autor und Techniker und dann fange an, wie ein Künstler zu denken. Reize die Sinne deiner sehenden Besucher mit Farbe, Typografie, räumlicher Anordnung und Bildern, aber lass die inhaltliche Struktur sauber und die Auszeichnung unbeschädigt. Die Präsentation von Inhalt und Struktur zu trennen, erlaubt deinem inneren Künstler, sein Ding zu machen, ohne dem Autor und dem Techniker auf die Füße zu treten.

Wenn du anfänglich den Eindruck hast, dass CSS deine Kreativität einschränkt, musst du möglicherweise nur mehr über CSS lernen. Mit CSS zu designen ist nicht schwerer, als mit dem präsentationsbezogenem Markup, an das du dich vielleicht gewöhnt hast; es ist eher ein anderer Satz von Werkzeugen. Es ist tatsächlich ein viel besserer Satz von Werkzeugen, speziell für diese Aufgaben entworfen. Lerne CSS, finde heraus, wie es funktioniert und was es kann, lies Bücher und stelle Fragen. Das Wichtigste: experimentiere. Schon bald wirst du dich mit dem CSS-Werkzeugsatz wohl fühlen und intuitiv wissen, welche Eigenschaft anzuwenden ist, um einen bestimmten Effekt zu erzielen.

Du musst auch lernen, was nicht einfach mit CSS bewerkstelligt werden kann und musst, wie ein Techniker, solche Hindernisse frühzeitig erkennen und dein Design dementsprechend anpassen. Jedes Medium hat seine Grenzen und jeder Künstler lernt, diese Beschränkungen zu beachten und das Medium einfach als einen anderen Absatzweg der Kreativität zu nutzen. Wie ein Künstler zu denken, wird dir helfen, kreative Lösungen für visuelle Probleme zu finden.

Die Mentalitäten zusammenführen

Diese drei Disziplinen – Schreiben, Technik und Kunst – unterscheiden sich nicht so stark. Jede erfordert kreative Problemlösungen und obwohl jede einen etwas anderen Angriffswinkel anregt, bleibt das Ziel doch das Gleiche. Kultiviere diese Aspekte deiner Persönlichkeit und widme jedem davon unabhängig deine Aufmerksamkeit. Wenn du es leicht schaffst, in diesen drei Modi nacheinander zu denken, wirst du bald merken, dass du in allen dreien gleichzeitig denkst. Der Autor, der Techniker und der Künstler überlagern sich und fließen im Voltron-Stil ineinander, um den Designer zu formen.

Den mentalen Schritt vom präsentationsbezogenen zum strukturellen Denken zu vollziehen, bringt vermutlich einige Änderungen in deinem kreativen Prozess mit sich. Um wie ein Autor zu denken, versuche, mit einem Entwurf des Inhalts zu starten, bevor du das erste Bildchen kritzelst. Zähle alles auf, was eventuell auf der Seite gezeigt werden wird, vom Logo bis zum Copyright-Hinweis, und gruppiere zusammengehörige Dinge in sinnvolle Teilbereiche. Nimm dir Zeit, deinen Inhalt zu verstehen, selbst wenn das heißt, ihn einfach nur zu lesen. Verstehe die Ideen, die du vermittelst und du wirst besser darauf vorbereitet sein, sie auszumalen.

Während du diese Informationseinheiten in einem visuell ansprechenden Design arrangierst, solltest du wie ein Techniker denken und die Reihenfolge der Elemente in deinem Markup ebenso planen wie die CSS-Eigenschaften, die du nutzen willst, um deren Präsentation zu beeinflussen. Runde Ecken und Schlagschatten sind leicht in Photoshop zu erstellen, aber wenn du dir nicht sicher bist, wie du sie mit sauberem Markup und CSS umsetzen kannst, willst du sie vielleicht nochmal überdenken. Plane deine Konstruktion so, wie du das Erlebnis planst und du wirst besser darauf vorbereitet sein, das Bild einer Internetseite in eine wirklich funktionierende Internetseite zu überführen.

Wenn du mit den Sprachen, die wir nutzen um Websites zu bauen, absolut vertraut bist, wird dein innerer Künstler frei in seinem Schaffen sein. Wenn dein Techniker weiß, wie man Kästen mit runden Ecken baut, ohne über die bedeutsamen Wörter deines Autors zu trampeln, kann dein Künstler sie ohne das kleinste ängstliche Zucken darstellen. Du wirst hübsche Sachen malen und instinktiv wissen, wie sie anzuwenden und mit sematischer Stärke zu versehen sind. Die drei Mentalitäten arbeiten innerlich zusammen, um Eloquentes, Robustes und Schönes zu schaffen.

Wenn du dein Hirn zerteilst, um Webstandards zu verinnerlichen, wirst du deren grundlegende Seele in deine Weltsicht übernehmen. Du kannst immer noch wie ein Designer denken – also in Bildern statt in Quelltext – aber deine Bilder werden praktikabler werden. Du wirst dir dein Seitendesign mehr als ästhetisches Arrangement von verzierten Kästen vergegenwärtigen und es mehr als poetische Maschine sehen, die aus aussagekräftigen Komponenten erbaut wurde.

Das Internet-Erlebnis aus makellos validem, semantisch reichem Markup und elegentem CSS zu formen, wird für dich so einfach wie Atmen. Die alten präsentationsbezogenen Methoden werden sich ungeschickt und geschmacklos anfühlen, primitiv in ihrer rohen Brutalität. Du wirst den Quelltext einer Site sehen, die ein Jahr zuvor gebaut hast und wirst verlegen erschauern, dich darüber wundernd, wie du jemals solchen schlampigen, unintuitiven Spaghetti-Code als auch nur annähernd akzeptabel ansehen konntest.

Wenn du verstehst, dass Inhalt und Quelltext mindestens genau so viel bedeuten wie Design, wirst du am Ende ein besserer Designer werden. Du wirst Webstandards verinnerlichen, und es gibt kein Zurück.

Translated with the permission of A List Apart Magazine and the author.

Zum Übersetzer

Stefan David wohnt im beschaulichen Bad Laer in der Nähe von Osnabrück und arbeitet beim Medienversandhändler jpc, wo er sich um Online-Marketing und Affiliate-Management kümmert. Nebenbei baut er für einen kleinen Kundenkreis Websites und schreibt viel zu selten in seinem eigenen Blog.