This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Das Beste an HTML & CSS Best Practices für standardkonformes Webdesign
O’Reilly
Ben Henick Deutsche Übersetzung von Jørgen W. Lang
Das Beste an HTML & CSS Best Practices für standardkonformes Webdesign
Das Beste an HTML & CSS Best Practices für standardkonformes Webdesign
Ben Henick Deutsche Übersetzung von Jørgen W. Lang
Beijing Cambridge Farnham Köln Sebastopol Taipei Tokyo
Die Informationen in diesem Buch wurden mit größter Sorgfalt erarbeitet. Dennoch können Fehler nicht vollständig ausgeschlossen werden. Verlag, Autoren und Übersetzer übernehmen keine juristische Verantwortung oder irgendeine Haftung für eventuell verbliebene Fehler und deren Folgen. Alle Warennamen werden ohne Gewährleistung der freien Verwendbarkeit benutzt und sind möglicherweise eingetragene Warenzeichen. Der Verlag richtet sich im wesentlichen nach den Schreibweisen der Hersteller. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.
Kommentare und Fragen können Sie gerne an uns richten: O’Reilly Verlag Balthasarstr. 81 50670 Köln Tel.: 0221/9731600 Fax: 0221/9731608 E-Mail: [email protected] Copyright der deutschen Ausgabe: 2010 by O’Reilly Verlag GmbH & Co. KG 1. Auflage 2010
Die Originalausgabe erschien 2009 unter dem Titel HTML & CSS The Good Parts im Verlag O’Reilly Media, Inc.
Die Darstellung eines Katzenfretts im Zusammenhang mit dem Thema HTML und CSS ist ein Warenzeichen von O’Reilly Media, Inc.
Bibliografische Information Der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.
Lektorat: Inken Kiupel & Susanne Gerbert, Köln Korrektorat: Friederike Daenecke, Zülpich Satz: Reemers Publishing Services GmbH, Krefeld; www.reemers.de Umschlaggestaltung: Michael Oreal, Köln Produktion: Karin Driesen, Köln Belichtung, Druck und buchbinderische Verarbeitung: Druckerei Kösel, Krugzell; www.koeselbuch.de ISBN 13 978-3-89721-617-4 Dieses Buch ist auf 100% chlorfrei gebleichtem Papier gedruckt.
HTML und CSS sind schon recht alte Technologien, die bereits über 10 Jahre im Einsatz sind und sich immer noch weiterentwickeln. Langjährige Webentwickler (mit 15 Jahren Berufserfahrung und mehr) haben Projekte für die unterschiedlichsten Browser realisiert, mit diversen Funktionen experimentiert und dabei deren Vor- und Nachteile kennengelernt. Trotz bester Absichten haben die Erfinder von HTML und CSS nicht alles richtig gemacht. Manche Experimente sind eher misslungen, andere Teile haben sich als wesentlich nützlicher herausgestellt, als ursprünglich geplant. Wer diese Technologien meistern will, muss wissen, welche Teile der Spezifikationen nur überflüssiger Müll sind und welche die echten Goldstücke, die möglichst oft verwendet werden sollten. Wenn Sie sich auf die besten Methoden (Best Practices) konzentrieren, können Sie in kürzerer Zeit bessere Websites erstellen.
Über dieses Buch Hoffentlich halten Sie dieses Buch in den Händen, weil Sie auf Ihrer Lieblings-Website eine fabelhafte Rezension gelesen haben oder weil ein Bekannter Ihnen gesagt hat, dass Sie dieses Buch unbedingt lesen müssen. (Der Traum jedes Autors.) Vermutlich brauchen Sie ein paar weitere Informationen zu der Frage: Ist dies das richtige Buch für Sie? Wenn Sie sich und Ihre Schwerpunkte auf den nächsten Seiten wiederfinden, dann sollten Sie mit diesem Buch unter dem Arm aus dem Geschäft laufen – oder sich zumindest auf den nächsten Stuhl setzen und gleich mit dem Lesen anfangen.
Was ist das Beste an HTML und CSS Der größte Teil von HTML und CSS ist zweifellos ziemlich langweilig. Und damit meine ich: zum Einschlafen. So gesehen, haben Webtechnologien Ähnlicheit mit gewissen Filmen. Der Betrachter würde gern die Einführung überspringen und gleich dort beginnen, wo es interessant wird. |
XV
Dieses Buch soll genau diesem Gefühl Rechnung tragen. Der gesamte Einstieg ins Thema – zu dessen Studium wir unsere Leser herzlich einladen – wird in den Kapiteln 2 und 3 abgehandelt. Hier können Sie schnell mal etwas nachlesen, falls Sie meinen, irgendetwas verpasst zu haben. So richtig zur Sache geht es aber in den Teilen danach: Sie lernen, solide Layouts zu entwickeln, sich von Programmierfehlern nicht einschüchtern zu lassen, Templates zu bauen, die auch nach einem Redesign noch funktionieren, und vieles andere.
Was Sie vor dem Lesen dieses Buches wissen sollten Um dieses Buch zu verstehen, sollten Sie ein paar Dinge bereits wissen: Sie sollten sich mit HTML 4.01-Elementen, CSS-Selektoren und CSS-Eigenschaft/Wert-Paaren auskennen. Auf der englischen Website zu diesem Buch (http://www.htmlcssgoodparts.net) finden Sie Referenztabellen mit Links auf umfangreiche Beschreibungen von HTML und CSS auf anderen Websites. Es ist allerdings deutlich einfacher, diesem Buch zu folgen, wenn Sie sich bereits mit CSS und HTML auskennen. Dieses Buch ist außerdem leichter verständlich, wenn Sie wissen, was mit der Trennung von Präsentation, Inhalt und Struktur in einer Website oder -applikation gemeint ist. Wenn Sie sich mit diesen Begriffen nicht wohlfühlen, finden Sie Trost und Rat in O’Reillys umfassenden Handbüchern zu HTML und CSS und den Bänden aus der Taschenbibliothek (kurz & gut). Zum Wohle der Leser, die ihr Wissen etwas überschätzt haben, werden die Grundlagen zur Struktur von Webseiten, Stylesheets und HTML-Elementen trotzdem angesprochen, allerdings so kurz wie möglich.
Der ideale Leser Wenn einer der folgenden Punkte auf Sie zutrifft, können Sie sich als idealen Leser dieses Buches bezeichnen: • Sie kennen sich mit der Serverseite einer Webapplikation aus. Ein Redesign ist aber nichts für Sie, weil Sie dafür zu tief in den Code eintauchen müssen, um den enthaltenen Markup-Code anzupassen. Die effektivste Lösung dieses Problems besteht in der Verwendung der »CSS Zen«-Technik, die im CSS Zen Garden (http://www.csszengarden.com/) von Dave Shea zu sehen ist. Dieses Buch zeigt Ihnen den Weg des CSS Zen – die Strukturierung des Markup-Codes auf eine Weise, die ein Redesign vollkommen auf Stylesheets beschränkt – aus einer Perspektive, die auch für Entwickler verständlich ist. • Sie sind geschickt in der Verwendung von Tools zur Website-Erstellung wie Adobe Dreamweaver oder Microsoft Visual Studio, aber Ihre Erwartungen kollidieren ständig mit den Einschränkungen dieser Systeme. Wenn Sie nicht aufpassen, füllen diese Tools Ihre Webseiten mit jeder Menge Krempel (soll heißen: nutzlosem, überflüssigem Müll) und verstoßen dabei gegen das KISS-Prinzip. Hiermit ist nicht die XVI
|
Einleitung
Rockgruppe gemeint, sondern der Tipp »Keep it simple, stupid!« – »Einfacher ist besser«. Das passiert, weil Web-Entwicklungsumgebungen eben nur Konfektionsgrößen bieten, keinen Maßanzug. Dieses Buch erklärt HTML und CSS so detailliert, dass Sie Ihre Werkzeuge genau auf Ihren Arbeitsalltag abstimmen können. • Sie haben, aus welchem Grund auch immer, eine Menge schlechter Angewohnheiten, die Sie durch bessere ersetzen wollen. Einige unter Ihnen verwenden womöglich immer noch HTML, um nicht nur die Struktur, sondern auch die Darstellung von Webseiten zu steuern. CSS kommt Ihnen dagegen wie ein undurchdringlicher Dschungel vor. Dieses Buch bringt Licht in das CSS-Dickicht. • Sie sind ein Grafikdesigner aus dem Printbereich. Um einen Karriereknick zu vermeiden, müssen Sie die Stärken und Schwächen des Webs als Medium verstehen. Sie haben einen Blick auf HTML und CSS geworfen und glauben, dass beides gut zusammenpasst, aber Sie verstehen einfach nicht, wie. In diesem Buch betrachten wir die Verbindung beider Techniken, um Designelemente genau am gewünschten Ort zu platzieren. • Sie müssen sich in Ihrem Beruf an bestimmte Richtlinien für die Barrierefreiheit (Accessibility) der Seiten halten oder Anforderungen an die medienübergreifende Benutzbarkeit erfüllen. Ist Ihr Markup-Code nicht für die Verwendung von CSS vorbereitet, gibt es wenig Hoffnung, medienübergreifende Websites zu erstellen, geschweige denn, diese für Benutzer mit Behinderungen zugänglich zu machen. Dieses Buch erklärt, wie Sie bestimmte Standards zur Zugänglichkeit einhalten können, ohne hierfür mehrere Websites parallel erstellen zu müssen. • In einem Bereich außerhalb der Präsentationsschicht haben Sie bereits Expertenwissen und wollen sich Ihren Job erleichtern. Eine zu starke Spezialisierung führt möglicherweise zu einem Mangel an Überschneidungen bei den Fähigkeiten des Einzelnen. Das schafft Barrieren bei der Kommunikation im Team. Dieses Buch zeigt, welche Prioritäten bei der Arbeit für Entwickler am direktesten mit den Besuchern der Site zu tun haben, und gibt Ihnen dadurch die Informationen für eine effektivere Kommunikation im Team. • Sie haben es einfach satt, ständig mit dem Schädel gegen die Wand namens Internet Explorer 6 zu knallen. Mehrere Websites, insbesondere Position Is Everything (http://www.positioniseverything.net/), helfen Ihnen, das Bereitstellen zusätzlicher Stylesheets für alte Versionen von Internet Explorer zu vermeiden. Hierbei befassen sich die meisten Online-Ressourcen jedoch mit speziellen Programmierfehlern und Eigenarten. In Kapitel 14 finden Sie eine erklärende Zusammenfassung der Macken »unter der Haube«, die zu ungewollten Zusammenstößen und Reifenpannen führen können. Außerdem finden Sie in diesem Teil ein Kochbuch mit Praktiken und Techniken, mit denen Sie diese Probleme gleich ganz vermeiden können.
Eine Warnung zum Thema (mangelnde) Kenntnis Teilweise sind Ihnen die Inhalte dieses Buches möglicherweise schon vertraut. Dieses Buch richtet sich an einen großen Kreis von Spezialisten. Dadurch kann es gelegentlich
Einleitung
|
XVII
passieren, dass z.B. Dinge, die für Entwickler gedacht sind, den Designern unter Ihnen so offensichtlich vorkommen, dass es fast schon wehtut, und umgekehrt. Es kann auch passieren, dass Ihnen die Diskussion mancher Themen vorkommt wie ein Streitgespräch. Oft fallen kreative Entscheidungen und solche zur Implementierung nicht aus Vernunft, sondern aus einer Position politischer Stärke. Wir hoffen, dass dieses Buch dabei hilft, vernunftbasierte Argumente gegen schlechte Ideen durchzusetzen. Wenn Ihnen alles in diesem Buch neu vorkommt, kann es sein, dass Sie sich ein bisschen überschätzt haben. In diesem Fall kann hoffentlich die Website zu diesem Buch weiterhelfen. Sie soll sicherstellen, dass alle Käufer dieses Buches etwas davon haben. Erscheint Ihnen das Material trotzdem etwas zu komplizert, sollten Sie sich auf Schwierigkeiten einstellen. Das Problem lässt sich am besten mit Geduld lösen und indem Sie Ihren Freunden und Kollegen eine Menge Fragen stellen.
Ziele dieses Buches Oft sind die Eigenheiten von HTML, CSS und des Dokumentenbaums ohne gute Anleitung oder Erfahrung nur schwer zu verstehen. Dieses Buch soll Ihnen diese Dinge in verständliches Deutsch übersetzen. Hierzu gehören unter anderen die folgenden Themen: •
die Auswahl und Verwendung der besten HTML-Version für Ihr Projekt
•
wie Sie die Hindernisse zwischen Ihrer gegenwärtigen Vorgehensweise und durchgehend gültigem Markup-Code überwinden
•
wie Sie HTML für die Strukturierung – aber nicht für die Darstellung verwenden, unter der bestmöglichen Nutzung von CSS
•
seltsame und trotzdem nützliche HTML-Elemente
•
wie Sie Plugin-Inhalte zum Laufen bringen
•
die richtige und effektive Verwendung von Tabellen
•
wie Sie CSS-Selektoren verstehen und verwenden, besonders diejenigen für Nachfahren-Elemente
•
welche CSS-Selektoren vor anderen Vorrang haben
•
die Zusammenhänge des CSS-Block-Layouts
•
zusammengefasste CSS-Außenabständen (Margins)
•
Programmierfehler und andere Seltsamkeiten in Internet Explorer 6
•
wie Sie die Darstellung von Formularen in den Griff bekommen
•
die Geschichte der Programmierfehler in Webbrowsern
•
was HTTP tut, wenn Sie gerade nicht hinsehen (und warum das wichtig ist)
Dieses Buch versucht, alle Dinge abzudecken, die Frontend-Entwickler wissen sollten. Es soll die Beziehungen zwischen den Schichten der Webtechnologien beschreiben, mit
XVIII
|
Einleitung
denen Designer und Entwickler der Präsentationsschicht zu tun haben. Außerdem sollen die Stärken von HTML und CSS aufgezeigt werden. Dieses Buch gibt den weniger erfahrenen Lesern außerdem eine lange Liste mit CSSLayout-»Tricks« an die Hand, die für die Darstellung, Zugänglichkeit und Optimierung für Suchmaschinen (Search Engine Optimization, SEO) essenziell sind. Hierzu gehören: • Inhalte zentrieren • eine erweiterte Version der »Fahrner Image Replacement«-Methode zur Bildersetzung, um mehr Kontrolle über die Schriftart und Gestaltung von Überschriften zu bekommen • die Erstellung von Layouts mit ausgerichteten Spalten mit (scheinbar) gleicher Höhe • die Verwendung der CSS-Eigenschaft float für die optimale Nutzung der Spaltendarstellung und der Reihenfolge des Markup-Codes • die Erstellung vielseitiger und optisch ansprechender Navigationsbereiche • die Entwicklung von Arbeitsangewohnheiten, die Ihre Websites auf den Einsatz von Ajax vorbereiten • wie Sie die CSS-Eigenschaft position möglichst effizient nutzen • die Erstellung vielseitiger Grid-Layouts für Ihre Websites Nach der Lektüre dieses Buches sollten Sie beliebige Kombinationen aus Struktur- und Darstellungscode in die Präsentations- und Inhaltsschicht einer barrierefreien, anwenderfreundlichen und von Suchmaschinen indizierbaren Website verwandeln können – und das unabhängig davon, wie hanebüchen die Anforderungen scheinbar sind.
Was Sie nicht in diesem Buch finden Dieses Buch konzentriert sich auf Praktiken, die die Effektivität von Markup-Code und Stylesheets maximieren. Aus diesem Grund werden Sie einige Dinge hier nicht finden: Kaum unterstützte Teile von plattformspezifischem CSS-Code Mit CSS lässt sich eine Menge anstellen – leider funktioniert einiges davon nur mit schlecht unterstützten CSS-Selektoren und Eigenschaften. Solche Fälle behandeln wir ergebnisabhängig, d.h.: Gibt es für einen ActiveX-Filter in Firefox eine Entsprechung, wird er vermutlich erwähnt. Das Gleiche gilt für -moz-*-Eigenschaften, für die es Analogien in der IE-Laufzeitumgebung gibt. Damit etwas in diesem Buch erwähnt wird, muss es mindestens von Firefox 3 und von Internet Explorer 8 unterstützt werden. Damit Sonderfunktionen erwähnt werden, müssen sie von einer größeren Menge an Plattformen unterstützt werden. CSS-Eigenschaften für vergleichsweise seltene Medientypen Die in diesem Buch behandelten Produktionstechniken helfen Ihnen, barrierefreie Sites zu erstellen. Allerdings können wir hier aus Platzgründen nur eine Einführung in diese Methoden geben.
Einleitung
|
XIX
JavaScript und das Document Object Model (DOM) Obwohl JavaScript in diesem Buch erwähnt wird und gelegentlich sogar ein paar Codeschnipsel auftauchen, liegt das Hauptaugenmerk auf HTML und CSS. Die Manipulation von HTML und CSS mit JavaScript oder dem Document Object Model wird hier nicht behandelt. Die Integration in Frameworks wie jQuery und YUI Über JavaScript-Frameworks gibt es viele gute Dinge zu sagen. In diesem Buch werden Sie allerdings nichts dazu finden. Obwohl Sie in vielen Umgebungen nützlich sind, haben wir hier auf ihre Behandlung verzichtet, um den Rahmen des Buches nicht zu sprengen. Die besten Ressourcen, um die Arbeit mit JavaScript-Frameworks, den dazugehörigen Stildefinitionen und dem passenden Markup-Code zu lernen, finden Sie im Web und in Büchern, die sich spziell mit diesen Frameworks befassen. Eine umfassende Diskussion von CSS-Frameworks wie YUI Grids und Blueprint Ein Ziel dieses Buches besteht darin, Ihren Talenten den nötigen Feinschliff zu geben. Ihr Lebenslauf soll für die Leute der Personalabteilung genauso angenehm aussehen wie für diejenigen, die Ihnen schließlich einen Job geben (hoffentlich!). Das Lesen dieses Buches kann Ihnen dabei helfen, das CSS-Framework zu verstehen, für das Sie sich gerade entschieden haben, ohnedass wir hier eine Anleitung für ein bestimmtes Framework geben. Techniken zur Webserver-Konfigurierung Die Standardeinstellungen vieler Webserver vernachlässigen eine Reihe von Optionen, mit denen die Usability (Benutzerfreundlichkeit), Barrierefreiheit und Standardkonformität erhöht werden können. Allerdings sind diese Dinge eher die Aufgabe von Systemadministratoren. Eine Reihe von anderen O’Reilly-Titeln, insbesondere Webmaster in a Nutshell (http://oreilly.com/catalog/9780596003579/) und Website Optimization (http://oreilly.com/catalog/9780596515089/), befassen sich speziell mit diesem Interessengebiet. Zusätzlich befassen sich verschiedene Online-Communities und Blogs gelegentlich mit diesem Thema. Entwicklung für das mobile Web Sie haben das Pech, dass dieses Buch von einem lebenslangen Bewohner der USA geschrieben wurde, eines Landes, in dem die Fähigkeiten und die Verlässlichkeit mobiler Webzugänge noch sehr zu wünschen übrig lassen. Die Beliebtheit des iPhones hat die Situation zwar verbessert, aber längst noch nicht erträglich gemacht. Nur wenige Benutzer mobiler Endgeräte in den USA (wie auch in Deutschland, Anm. d. Ü.) können vom mobilen Web einen ähnlich hohen Standard erwarten wie die Benutzer von PCs. Zusätzlich erschwert wird die Entwicklung von mobilen Inhalten durch die Kosten bei den Prepaid-Tarifen und das Fehlen von unbelasteten Emulatoren für Mobilplattformen. Ich hoffe sehr, in die folgende Auflage dieses Buches auch Entwicklungstechniken für mobile Endgeräte aufnehmen zu können. Die Erwähnung von Opera für Desktop-Computer Wenn mir eine Sache in diesem Buch wirklich fehlt, so ist es die Erwähnung des Opera-Browsers für Desktop-Computer in der Diskussion des Browserverhaltens. XX
|
Einleitung
Beim Abwägen des Marktanteils von Opera gegen den Testaufwand, der für dieses Buch nötig gewesen wäre, war das Ergebnis äußerst entmutigend. Da ich Chris Mills von Opera für Vermittlung des Vertrages zu diesem Buch direkten Dank schulde, können Sie sicher sein, dass mir diese Entscheidung nicht leichtfiel. Sollte es auch nur ein geringes Leserinteresse an einer Diskussion von Opera geben, werde ich diese auf der Website zu diesem Buch nachreichen.
Über Webstandards Zum Schluss noch ein paar Worte zur Konformität mit den Empfehlungen des World Wide Web Consortiums (W3C) in kommerziellen Umgebungen, hier insbesondere bei Großunternehmen. Mir war es immer wichtig, zwischen »Standardfreundlichkeit« und der »buchstabengetreuen Befolgung« der Standards zu unterscheiden. Im ersten Fall geht es darum, dem Geist der sogenannten Webstandards gerecht zu werden, was sich in der Praxis leicht erreichen lässt. Der zweite Fall bedeutet, den Empfehlungen buchstabengetreu zu folgen, was manchmal schlicht unmöglich ist. Die Effektivität einer Website wird wesentlich mehr durch ihre Standardfreundlichkeit erhöht als dadurch, dass sie die Standards komplett einhält. Hierbei basieren die größten Verbesserungen darauf, beiden Zielen möglichst treu zu bleiben. Dieses Buch bevorzugt die Kompromisse und Ausweichlösungen, bei denen die Standardfreundlichkeit trotz ungünster Entwicklungsbedingungen gewahrt bleibt und es nur selten lange Gesichter gibt. Sie haben vielleicht gemerkt, dass ich den Begriff »sogenannte« Webstandards verwendet habe. Dieser Ausdruck basiert auf der Ironie, dass Webstandards eben keine Standards sind – jedenfalls nicht im wörtlichen Sinne. Standardisierung erfordert industrieübergreifend die gewissenhafte Verwendung eines formal definierten Systems. Hierfür sind Standardisierungsinstitutionen zuständig, deren Arbeit direkt oder indirekt in die Entscheidungen und Veröffentlichungen der International Organization for Standardization (ISO) einfließt. Ein weiteres Hauptmerkmal echter Standards sind objektive Kriterien, mit denen die Einhaltung von Standards durchgesetzt werden kann – eine Fähigkeit, die dem W3C in weiten Teilen fehlt. Aus diesen Gründen ist die beliebte Definition der W3C-Empfehlungen als »Standards« zwar sinngemäß vertretbar, echte Standards sind sie aber nicht. Allerdings hat sich die Praxis der Webstandards seit den Pionierjahren der 1990er enorm verbessert. Auch hierauf wird auf der Website zu diesem Buch detaillierter eingegangen.
Einleitung
|
XXI
Über Photoshop In den Kapiteln 9 und 11 wird die Erstellung von Bildern und Grafiken detailliert beschrieben. Die dort behandelten Vorgehensweisen beziehen sich auf Adobe Photoshop. Ich habe diesen Ansatz gewählt, weil in einer genügend großen Gruppe von Webprofis äußerst verschiedene Werkzeuge und Implementierungstechniken zum Einsatz kommen – bis es um die Arbeit mit Grafiken geht. Alternativen zu Photoshop (besonders Fireworks, ein weiteres Adobe-Produkt) haben ebenfalls ihre Anhänger. Aber selbst diese werden mir zustimmen, dass Grundkenntnisse zu den Werkzeugen von Photoshop und dessen Benutzeroberfläche äußerst nützlich sind. Meine Wahl basiert außerdem auf persönlicher Erfahrung. Ich habe seit meiner Anfängerzeit nie etwas anderes als Photoshop benutzt, um Webgrafiken zu bearbeiten. Ich hoffe, dass die Besucher der Website zu diesem Buch ihre eigenen Rezepte als Ergänzung zu den hier beschriebenen Arbeitsweisen beitragen werden. Außerdem unterstreicht die Verwendung von Photoshop, wie wichtig das richtige Werkzeug für eine effektive Zusammenarbeit ist. Kapitel 4 verdeutlicht den Wert von Produktionsstandards und Codebibliotheken, wobei sich die Vorteile einheitlicher Werkzeuge auch auf Software »von der Stange« erstrecken.
Was Sie auf der Website zu diesem Buch finden Die englische Website zu diesem Buch, www.htmlcssgoodparts.net, enthält eine Menge Informationen. Hierzu gehören unter anderem: • Errata und Korrekturen (englisch) • Blog-Einträge zu Leserfragen, aktuellen technischen Entwicklungen und besten Vorgehensweisen • schrittweise Demonstrationen der in diesem Buch besprochenen Techniken, inklusive Markup-Quellcode und Stylesheet-Regeln. • Vorlagen und/oder Templates für mehrzeilige Layouts und andere Website-Bausteine (Widgets) • HTML- und CSS-Referenztabellen, die auf diverse externe Dokumentationsquellen verweisen • Besucherrezensionen von Büchern und Programmen, die für die Leser dieses Buchs von Interesse sein könnten
Nomenklatur Im Webdesign gibt es viele Fachbegriffe, die uneinheitlich verwendet werden. Um die Gefahr der Verwirrung möglichst klein zu halten, werden die im Folgenden hervorgehobenen Begriffe durchgängig in diesem Buch verwendet. Dateien sind eigenständige Knoten im Dateisystem des Serverrechners, während Ressourcen Dokumente oder Teile davon sind, auf die mit separaten URIs (Uniform Resource XXII
|
Einleitung
Identifiers) verwiesen wird. Nicht alle Dateien besitzen entsprechende URIs, und nicht alle URIs verweisen auf einzelne Dateien. So kann ein URI beispielsweise auf die Ergebnisse einer Datenbankabfrage oder Datenströme verweisen. Gleichzeitig kann eine Datei auch einfach nur die Logik sein, die den Inhalt mehrerer URIs bestimmt. Seiten oder Dokumente enthalten eine oder mehrere Ressourcen beliebiger Art. Sie entsprechen der Ausgabe, die ein Benutzer auf die Anforderung eines einzelnen URI erhält (bzw. auch mehrerer URIs, wenn auf der Website Ajax eingesetzt wird). Der Unterschied zwischen den Begriffen »URI« und »URL« wird in diesem Buch als unerheblich betrachtet. Das liegt teilweise daran, dass der Begriff »Ressource« aufgrund der schnellen Entwicklung selbst fast schon bedeutungslos geworden ist. Als Inhalt bezeichnen wir die Dinge, um die herum eine Website aufgebaut ist. HTML-, XHTML- und XML-Code wird allgemein als Markup bezeichnet. Als Stylesheets bezeichnet man den Inhalt von CSS-Dateien oder style-Elementen. Stylesheet-Regeln definieren die Darstellung eines oder mehrerer Elemente einer Seite. Stylesheet-Regeln besitzen einen Selektor. Dieser definiert, auf welche Elemente einer Seite die Regel angewandt werden soll. Die Regel selbst besteht aus einem oder mehreren Paaren aus CSS-Eigenschaft und einem dazugehörigen Wert. Browser werden auch als Benutzerprogramm, User Agent oder Client bezeichnet. HTML und CSS werden seriell geparst. Das Ergebnis ist die Darstellung (das »Rendering«) der Seite im Browser. JavaScript ist ein eingetragenes Warenzeichen von Sun Microsystems. Es bezeichnet in diesem Buch die Programmiersprache, mit der in Form von Skripts die Datenverarbeitung und verschiedene interaktive Elemente im Browser gesteuert werden können. Um rechtliche Probleme zu vermeiden, benutzen einige Browserhersteller gelegentlich leicht abweichende Namen. Wo ein Browser ist, ist aber normalerweise ein JavaScript-Interpreter nicht weit. Das Document Object Model (oder DOM) ist steht einerseits für die Darstellung der Dokumentstruktur. Gleichzeitig definiert das DOM aber auch, wie diese Struktur durch Programme organisiert, abgefragt und verändert werden kann. Zwar gibt es unterschiedliche DOM-Spezifikationen für Webdokumente, von diesen ist allerdings nur eine vom W3C offiziell abgesegnet. Zur Schicht der webbasierten Dienste gehören dem allgemeinen Verständnis nach ein Betriebssystem, ein Webserver, eine relationale Datenbank, eine serverseitige Skriptsprache, HTML, CSS und JavaScript. Die Plattformen, die für die ersten vier Ebenen dieser Schicht verwendet werden, können unterschiedlich ausfallen. Allgemein spricht man bei den ersten vier Ebenen von der serverseitigen Umgebung, während die letzten drei Ebenen der clientseitigen Umgebung zuzuordnen sind. Die clientseitige Umgebung wird künstlich in vier Unterschichten unterteilt: Struktur (definiert durch das Markup), Inhalt (von Markup umgeben), Präsentation (mit CSS definiert) und Verhalten (mit JavaScript definiert). Zusammengenommen bilden diese
Einleitung
|
XXIII
Schichten eine MVC-(Model, View, Controller-)Architektur, die die MVC-Architektur auf der Serverseite widerspiegelt und mit dieser interagiert. Ajax steht für Asynchronous JavaScript And XML. Hierbei handelt es sich um einen Implementierungsansatz, der durch die GetXMLHttpRequest-Programmierschnittstelle (API) ermöglicht wird. HTML-Elemente sind die Hauptbestandteile des HTML-Namensraums. Tags bilden das eigentliche Markup. Sie können verschiedene Attribute enthalten, die bestimmte Werte besitzen. Tags umgeben in den meisten Fällen den Inhalt. Eine Dokumenttyp-Deklaration kann (und sollte in der Regel auch) am Anfang eines Webdokuments stehen. Sie definiert, gegen welche HTML-Version das Dokument validieren sollte. Die DTD (Dokumenttyp-Definition) besteht aus einer eine Reihe maschinenlesbarer Anweisungen, die die Gültigkeit der anzuwendenden HTML-Version festlegt. Die Angaben einer Dokumenttyp-Deklaration beziehen sich direkt auf eine bestimmte DTD. W3C-Empfehlungen (Recommendations) sind offizielle Dokumente, die als Spezifikationen für Webtechnologie-Plattformen und als Best Practices für die Verwendung dieser Plattformen dienen. Projektmanager sorgen dafür, dass die Hindernisse zwischen einem Projektteam und dem Erreichen seiner Ziele möglichst klein sind. Designer entwickeln das Erscheinungsbild (»Look and Feel«), und gestalten die Art und Weise, auf die Besucher eine Site benutzen und erleben (User Experience). Ingenieure und Anwendungsentwickler entwerfen und schreiben den Code, der die Site zusammenhält und antreibt. Frontend-Entwickler erstellen sämtliche Teile, die direkt mit dem Benutzer zu tun haben. Die meisten anderen Rollen, die häufig in Webentwicklungsteams zu finden sind, werden so benannt, wie es im Werbe- und Marketingumfeld üblich ist. Die Bezeichnung aktuelle Browser bezieht sich auf weitverbreitete Browserversionen zum Zeitpunkt der Drucklegung dieses Buches: Internet Explorer 6–8, Firefox 3.x und Safari 3.x und 4.x. Viele der hier aufgelisteten Begriffe beziehen sich auf bestimmte Prozesse, die beeinflussen, wie der Benutzer die Website erlebt. Diese Prozesse werden im Laufe dieses Buches detaillierter diskutiert.
»Read the Source, Luke!« Als ich im Jahr 1995 mit der Entwicklung von Webplattformen begann, war der Spruch »Read the Source, Luke!« der populärste Tipp, den man absoluten Neulingen in den Mailinglisten geben konnte. Er bezieht sich auf den Höhepunkt des Films Star Wars: Eine neue Hoffnung und ermahnt den Fragesteller dazu, den Markup-Quellcode (und heute auch die Stylesheet-Regeln) zu lesen, um daraus zu lernen. Dieser Hinweis ist weit mehr als nur der verschrobene Humor von Science-Fiction-Fans. Das beste Verständnis von effektivem Markup und Stylesheets erhält man durch das
XXIV
|
Einleitung
ungefilterte Lesen des Codes. Dies funktioniert auf ähnliche Weise, wie die Star WarsProtagonisten ihre Talente am besten nutzen konnten, indem sie »die Macht spüren«, ohne sich dabei von vorurteilsbehafteten Gedanken ablenken zu lassen. Um zu verstehen, wie jemand eine bestimmte Präsentation umgesetzt hat, müssen Sie deren Quellcode lesen. Ansonsten sind Enttäuschungen vorprogrammiert. Bevor wir uns allerdings damit beschäftigen, Ihnen die Feinheiten des Markup-Codes und von CSS nahezubringen, ist es am besten, das Web als ein System zu begreifen, inklusive der Beziehungen zwischen den zugrunde liegenden Konventionen und Technologien, die es im Innern antreiben.
Typografische Konventionen Wir verwenden die folgenden typographischen Konventionen: Kursiv Kennzeichnet die Namen von Dateien, Pfaden und Programmen sowie InternetAdressen, wie Domainnamen und URLs. Nichtproportionalschrift
Kennzeichnet Befehle und Optionen, die wörtlich eingegeben werden sollten; Namen und Schlüsselwörter in Programmen, inklusive Namen von Methoden, Variablen und Klassen; außerdem HTML-Tags und CSS-Regeln. Nichtproportionalschrift fett
Bezeichnet Hervorhebungen in Code-Beispielen Nichtproportionalschrift kursiv
Zeigt an, an welchen Stellen der Text durch Benutzereingaben ersetzt werden soll. Dieses Symbol kennzeichnet einen Tipp, einen Vorschlag oder eine allgemeine Bemerkung.
Dieses Symbol kennzeichnet eine Warnung oder mahnt zur Vorsicht.
Die Verwendung der Codebeispiele Dieses Buch soll Ihnen bei Ihrer Arbeit helfen. Im Allgemeinen dürfen Sie den Code aus diesem Buch in Ihren Programmen und Dokumentationen weiterverwenden. Hierfür brauchen Sie uns nicht um Erlaubnis zu fragen, es sei denn, Sie wollen größere Teile des Codes reproduzieren. Wenn Sie beispielsweise ein Progrmm schreiben, das größere Teile des Codes aus diesem Buch verwendet, ist keine Erlaubnis nötig. Der Verkauf oder die Verteilung einer CD-ROM mit Beispielen aus O’Reilly-Büchern bedarf dagegen einer
Einleitung
|
XXV
Erlaubnis. Das Beantworten einer Frage durch Zitieren einer Stelle dieses Buchs oder des enthaltenen Beispielcodes bedarf keiner Erlaubnis. Wenn Sie dagegen einen größeren Teil des Codes aus diesem Buch für die Dokumentation Ihres Produkts verwenden wollen, ist eine Erlaubnis nötig. Eine Quellenangabe ist erwünscht, aber nicht verpflichtend. Eine Quellenangabe enthält normalerweise die Nennung von Titel, Autor, Verlag und ISBN, zum Beispiel: Das Beste an HTML & CSS von Ben Henick. O’Reilly Verlag 2010, 978-3-89721-617-4. Wenn Sie sich nicht sicher sind, ob Ihre Verwendung der Codebeispiele einer Erlaubnis bedarf, können Sie unter der E-Mail-Adresse [email protected] Kontakt mit uns aufnehmen.
Danksagungen Wenn ich auf meine Erfahrungen der letzten 15 Jahre als Entwickler von Website zurückblicke, beeindruckt mich am meisten die Unwissenheit. Davon gibt es jede Menge, und wie viele andere Webentwickler nehme ich die Gelegenheit gerne wahr, die Unwissenheit der anderen, weniger talentierten Kollegen zu verurteilen – aber nicht in diesem Buch. Warum nicht? Wesentlich stärker beunruhigt mich jedoch meine eigene Ignoranz, die nicht weniger Kritik verdient. Kurz nach der Ignoranz kommen Angst und Sturheit, die beide gleichermaßen zu dem inneren Dialog beigetragen haben, der mich während des Jahres begleitet hat, in dem ich dieses Buch geschrieben habe. Aus dieser Haltung heraus soll dieses Buch ein Beispiel für die Überzeugung sein, dass es besser ist, eine Kerze anzuzünden, die anderen den Weg weist, als die Dunkelheit zu verfluchen. Auch ich habe mich lange in der Bequemlichkeit veralteter Produktionsmethoden wohlgefühlt. Daher versuche ich dort, wo es um beste Praktiken geht, möglichst vorsichtig vorzugehen, um meine Botschaft nicht zu verwässern. Zusammenfassend habe ich versucht, dieses Buch mit all jenen Empfehlungen zu füllen, die mir vor acht oder neun Jahren sehr geholfen hätten. Stattdessen wurden diese Probleme von vielen Leuten (mich eingeschlossen) oft durch Versuch, Irrtum und Unfall gelöst, und die Informationen, wie man es besser macht, konnten dadurch auch nur scheibchenweise weitergegeben werden. Ich hoffe, dieses Buch ist für Sie so nützlich, wie es mir hätte nützlich sein können, als ich meine HTML- und CSS-Fähigkeiten gerade entwickelte. Es gibt eine Anzahl von Leuten, deren Teilhabe an meinem Leben mich überhaupt erst dazu in die Lage versetzt hat, dieses Buch zu schreiben. Da dies die erste Gelegenheit ist, sie in aller Öffentlichkeit nennen zu können, möchte ich die Gelegenheit nicht verstreichen lassen. Abgesehen von meiner Familie sind dies unter anderem: Christian Cepel, Steven Champeon, Sumin Chou, Teddi Deppner, Nick Finck, David Hemphill, Molly Holzschlag, Brenda Houston, Ethan Marcotte, Doug Petersen, Lance Taylor, Thomas Vander Wal, XXVI
|
Einleitung
Peter Zale und Jeffrey Zeldman. Diese Menschen haben enorm zu meinem Leben beigetragen, und ohne sie alle wäre dieses Buch vermutlich nie geschrieben worden. Viele Leute kommen außerdem direkt in diesem Buch vor. Von diesen Leuten gebührt mein besonderer Dank Chris Mills von Opera Software. Chris stand diesem Projekt immer sehr nahe – schließlich war er es, der mich O’Reilly Media als Autor vorgeschlagen und die Sache ins Rollen gebracht hat, indem er mich einlud, einen Beitrag für das Opera Web Standards Curriculum (http://www.opera.com/company/education/curriculum) zu schreiben. Der Inhalt und die Qualität dieses Buches sind nicht nur meiner Arbeit zu verdanken. Tatsächlich wurde es durch die unermüdliche Geduld meines Lektors bei O’Reilly Media, Simon St. Laurent, vor dem Scheitern bewahrt. Zwar stehen meine Worte in diesem Buch, und auf dem Einband steht mein Name, aber nur die beständige Unterstützung dieses Projekts durch Simon hat die tiefe Schlucht zwischen meinen Anstrengungen und dem erfolgreichen Abschluss überbrückt. Michael Smith ist verantwortlich für die Teile dieses Buches, die sich mit HTML 5 befassen. Die Abwesenheit seines Namens auf dem Einband ist kein wirklicher Dank dafür, dass er mich davor bewahrt hat, durch das sprichwörtliche Minenfeld zu stolpern. Ich hatte das Glück, mir drei technische Gutachter selbst auszusuchen: Kimberley Blessing, Gez Lemon und Chris Van Domelen. Alle drei leisteten äußerst kritische Beiträge zur Genauigkeit und Aktualität dieses Buches. Sollte dennoch etwas fehlen, liegt dies allein in meiner Verantwortung. Kimberly und Chris waren außerdem viele Jahre tapfere Verbündete und Quellen technischer Ratschläge, und ich sehe mich außerstande (wie in so vielen anderen Fällen), ihnen angemessen für ihre Hilfe zu danken. O’Reilly Media war gnädig genug, mir drei weitere technische Gutachter zur Seite zu stellen: Edd Dumbill, Elaine Nelson und Shelley Powers. Ihre Beiträge halfen mir, viele weitere Fehler auszuräumen und die Struktur dieses Buches zu verbessern. Auch wenn ich dieses Buch eines Tages sowieso geschrieben hätte, würden Sie es ohne die herausragende Arbeit von Douglas Crockford jetzt nicht lesen. Er hat bewiesen, dass eine »Das Beste an«/»Good Parts«-Buchreihe begeisterte Leser finden würde. Ich bin der Überzeugung, dass Dinge nur durch die Arbeit der vielen Leute im Hintergrund funktionieren, und dieses Projekt hat diesen Glauben bestätigt. Besonders hohes Lob gebührt Emily Quill, die die Knoten im Manuskript entwirrt und dafür gesorgt hat, dass dieses Buch wirklich sein Geld wert ist. Loranah Dimant hat sich unermüdlich um die Änderungen in letzter Minute gekümmert und sichergestellt, dass das Buch den letzten Schliff bekam. Mein abschließender Dank geht an Eric Meyer, der die Messlatte für uns andere, die wir versuchen, Entwickler weiterzubilden, ziemlich hoch gehängt hat. Abschließend hoffe ich, dass das Wissen, das dieses Buch Ihnen vermittelt, Sie zu Erfolgen führt, die nicht weniger eindrucksvoll sind als die der Menschen, die hier erwähnt sind.
Einleitung
|
XXVII
KAPITEL 1
Hypertext von innen
Eine ordentlich programmierte Website besteht aus weit mehr als der Summe aus Markup, Stylesheets, Scripting und Multimedia-Ressourcen. Gut gebaute Websites reizen die Vorteile des Mediums voll aus. So wird eine einst undurchsichtige Technologie zum zentralen Faktor für die Art, auf die wir heute Informationen aufnehmen: Ohne die leicht zu aktivierenden Links wäre das Web nicht das, was es ist, sondern nur ein starrer Haufen Dokumente. Hypertext ist enorm vielseitig. Das Preis ist, dass Entwickler oft den Besuchern einer Website den Weg weisen müssen. Oft entscheiden sich Besucher selbst innerhalb einer Website für einen unerwarteten Weg, oder sie kommen von Websites oder Bookmarks, über die Sie als Entwickler keine Kontrolle haben. Die Macht, die Ihnen Hypertext verleiht, enthält auch die Verantwortung, Ihre Site so zu strukturieren, dass Ihre Besucher sich darin zurechtfinden und bewegen können.
Das Web ohne Links Durch die Verwendung von Links, um Informationen zu verbinden (das »Verlinken«), unterscheidet sich das Web von anderen, früheren Medien. Heute ist dieser Weg so normal, dass man diese Unterschiede leicht vergisst. Dennoch machen sie es erst möglich, erfolgreiche Websites zu erstellen. Was würde passieren, wenn Sie die Hyperlinks aus einer Website entfernten? • Wenn Sie Hypertext aus einem netzwerkbasierten Informationssystem entfernen, ist das erste und deutlichste Ergebnis, dass der Inhalt strikt linear wird. Der Leser muss sich erst durch eine bestimmte Menge Inhalt arbeiten, bevor er an die tatsächlich interessante Stelle gelangt. Ohne die Links ist das Ergebnis so gut wie nutzlos, es sei denn, die Informationen erhalten eine nachvollziehbare innere Struktur und Ordnung. • Lineare Ressourcen werden basierend auf unterschiedlichen Annahmen angelegt und strukturiert. Es wird erwartet, dass der Leser die vorigen Inhaltsteile zumindest ansatzweise kennt. Nehmen Sie beispielsweise ein Buch. Sie können darin herumblättern, die Kapitel sind aber weiterhin durch die absteigende Bedeutung der behandelten Themen geordnet. Gäbe es beispielsweise keine Website zu diesem Buch, wäre dieses Buch gespickt mit Mengen von Markup-Beispielen.
|
1
• Der Ortssinn des Lesers wird von gängigen Hinweisen geleitet. Die meisten Bücher und andere lineare Informationsressourcen besitzen auf jeder Seite eine der Orientierung dienenden Kopf- oder Fußzeile (oder eine Titelzeile des verwendeten Leseprogramms). Bei einer digitalen Informationsressource (z.B. einem großen PDF-Dokument) lässt sich der Fortschritt des Lesers z.B. anhand eines vertikalen Scrollbalkens ablesen. Diese Betrachtungen zeigen, wie Hyperlinks Dokumenten eine zusätzliche Dimension verleihen. Zwar erhält das Web dadurch eine enorme Flexibilität, gleichzeitig schaffen die neuen Möglichkeiten auch neue Herausforderungen. Die erweiterten Navigationsmöglichkeiten können die Orientierung erschweren. Während der Benutzer einer traditionellen Ressource sich auf die ihm bekannten »Wegweiser« und seinen gesunden Menschenverstand verlassen kann, benötigt der Benutzer von verlinkten Ressourcen für die Orientierung die Hilfe von Designern und Implementierern. Begriffe wie »Anfang« und »Ende« haben bei webbasierten Medien wenig bis keine Bedeutung. Dies ist der wesentliche Unterschied zwischen verlinkten Medien und der Natur linearer Ressourcen, die schon per Definition begrenzt sind.
URIs In einem perfekten System nimmt der Besucher einer Site die URIs gar nicht wahr. In ihrer Zusammensetzung aus einem Protokollbezeichner einem Verweis auf einen bestimmten Host und etwas, das aussieht wie eine Dateisystemreferenz, es aber nicht ist, sind URIs nicht gerade menschenlesbar. Oftmals enden URIs mit Paaren aus Bezeichnern und dazugehörigen Werten, die vor allem computerlesbar und weniger besucherfreundlich angelegt sind. Einfache URIs wie http://www.example.com, die auf eine bestimmte Website verweisen, hat vermutlich jeder schon einmal gesehen. Sie erscheinen in der Werbung und auf Visitenkarten. Die Zeichen http:// stehen inzwischen für: »Geben Sie das Folgende ein, um zu unserer Website zu gelangen.« Darüber hinaus können gut präparierte URIs eine Menge Informationen enthalten. Nehmen Sie bespielsweise die URIs Ihrer Lieblingssuchmaschine oder Nachrichten-Website, und Sie werden feststellen, dass da noch viel mehr passiert. Die URIs für Googles Suchergebnisse zum Beispiel können den Parameter start enthalten, der die Anzahl von Ergebnissen angibt, die eine höhere Wertung (»ranking«) haben als die aktuell angezeigten, z.B. http://www.google.com/?q=hypertext&hl=en&start=10. Auf ähnliche Weise können CMS-(Content-Management-System-)Plattformen und E-Commerce-Kataloge mehrere URIs verwenden, die auf die gleiche Ressource verweisen. Die längeren URIs können die Durchsuchbarkeit der Ressource erhöhen oder angeben, dass zusätzlich zur eigentlichen Ressource weitere Informationen mitgeliefert werden (z.B. bei einer Produktliste oder der Zusammenfassung eines Blogeintrags.) Browser und andere Werkzeuge verwenden das HTTP-Protokoll, um URIs zu verarbeiten und Informationen abzurufen. Details zur Art der Verarbeitung und dazu, wie ihre Funktionen und Beschränkungen sich auf Ihre Seiten auswirken können, finden Sie im Anhang. 2
|
Kapitel 1: Hypertext von innen
Mit Links umgehen Hypertext, wie wir ihn heute kennen, wurde erstmals in den 1960er-Jahren an der Stanford University implementiert. Allerdings brauchte es weitere drei Jahrzehnte, bis kommerzielle Internetzugänge bezahlbar wurden und der Umgang mit Hypertext zum Alltag wurde. Durch die »Explosion« des Internets war es nicht nur möglich, dass Hyperlinks Ressourcen in einem weltumspannenden Netzwerk miteinander verbanden, sondern sie begünstigte auch die Wahrnehmung, dass Hyperlinks im Web einfach und fehlertolerant sein müssten. Wenn jemand einen Link anlegt, wird allgemein erwartet, dass die Person auch weiß, worauf der URI verweist. Das muss nicht heißen, dass diese Person auch kontrolliert, was sich am Ende des Links befindet. Der Erfolg des Webs beruht zu einem großen Teil darauf, dass man einen Link auf beliebige Inhalte anlegen kann, ohne den Autor des Inhalts vorher fragen zu müssen. Hat eine Ressource einen URI, können Sie darauf auch einen Link anlegen. Funktioniert ein URI einmal nicht, wird eine gut gebaute Website eine entsprechende Fehlerseite anzeigen (den berühmten 404-(Datei nicht gefunden-) Fehler, die dem verlorenen Besucher wieder auf den richtigen Weg hilft. Die Stärke und Unmittelbarkeit von Weblinks warf alle möglichen kulturellen (und in manchen Fällen auch rechtlichen) Fragen darüber auf, was es bedeutet, direkt auf das Material anderer verweisen zu können. Im Laufe der Zeit wurde ein anderes und wahrscheinlich viel schwerer zu lösendes Problem immer wichtiger: tote Links. Das Anlegen von Links auf Informationen, die Sie nicht kontrollieren, bedeutet auch, dass diese Links irgendwann nicht mehr funktionieren. Informationen und ganze Websites verändern sich oder verschwinden sogar ganz. Das hat zur Folge, dass Besucher Ihrer Website möglicherweise verwirrt oder frustriert sind, weil sie das Gesuchte nicht sofort finden. Teilweise lassen sich tote Links nicht vermeiden. Selbst für automatisierte Systeme (z.B. Suchmaschinen) ist es schwer, aktuell zu bleiben. Und sogar dann, wenn die Links auch weiterhin auf nützliche Seiten verweisen, können sich diese im Laufe der Zeit in etwas vollkommen Anderes verwandeln. Innerhalb Ihrer eigenen Sites haben Sie schon deutlich mehr Kontrolle über diese Problematik, aber auch hier kann ein größeres Redesign schwere Probleme aufwerfen. Vorsicht, sauber erstellte Fehlerseiten und eine klare Navigation können bei der Minimierung dieser Probleme helfen. Mit normalen Links, die einen an den falschen Ort schicken, können Benutzer meist noch umgehen. Wenn den Seiten aber plötzlich Grafiken, Code, Stylesheets oder andere Bestandteile fehlen, die über korrekte hrefoder src-Werte eingefügt werden, wird die Sache schon schwieriger. Je wichtiger die Bestandteile für Ihre Seite sind, desto eher wollen Sie diese von einem Ort aus einbinden, der unter Ihrer Kontrolle steht.
Den Anwenderkomfort durch Links verbessern Links sind der Teil von HTML, über den URIs innerhalb der Applikationsschicht des Webs am zugänglichsten sind. Sie sind der Kreuzungspunkt von HTML und HTTP. Auf
URIs
|
3
der Anwendungsebene ist es der Unterschied zwischen dem Klicken auf einen Link und dessen Eingabe in die Adressleiste eines Browsers. Links bieten dem Ersteller einer Website unendliche Möglichkeiten – Möglichkeiten, die oft übergangen werden. Alles lässt sich mit allem verbinden. Hyperlinks in Dokumenten sind nicht auf die Navigation innerhalb der Website, Referenzen auf Stylesheets oder die Syndizierung von Inhalten beschränkt. Sie können außerdem auf eine unbegrenzte Zahl verwandter Dokumente und alle möglichen alternativen Inhalte verweisen. Hyperlinks, die auf Benutzereingaben reagieren, können an beliebiger Stelle platziert werden, auf beliebige Dinge verweisen und bestimmte Aktionen auslösen, die allein durch die Grenzen der Plattform, gesunden Menschenverstand und die Vorstellungskraft der Person beschränkt sind, die die Website erstellt. Gut implementierter Hypertext bereichert die Inhalte um die folgenden Dinge (nebenvielen anderen): Erweiterte Zugänglichkeit und Kontrolle der Informationen Hyperlinks können prinzipiell auf alle Teile des Webs verweisen, die keiner Zugangskontrolle unterliegen. Sie ermöglichen es den Benutzern, selbst zu entscheiden, wie sie auf welche Informationsressourcen zugreifen. Das Erschaffen mehrerer Erzählstränge aus dem gleichen Inhalt Hyperlinks machen es möglich, dass die »Reise« eines Besuchers sich innerhalb eines angemessenen Rahmens weitestmöglich seinen Wünschen anpasst. Die Gemeinschaft bestimmt, was wichtig ist Eingehende Hyperlinks verleihen dem Linkziel Glaubwürdigkeit, die auch ohne Fachleute funktioniert. Diese Tatsache definiert bereits eine Reihe von Systemen, die schon im Einsatz sind. Hierzu gehört insbesondere Googles PageRank-Algorithmus. Zwar kann es sein, dass die »Weisheit der Massen« nicht immer korrekt ist, aber die Genauigkeit verbessert sich im Laufe der Zeit, da Fachleute für ein bestimmtes Thema eng in den Prozess einbezogen sind.
Herausforderungen bei der Implementierung von Hypertext Die Webtechnologie ermöglicht es Benutzern, ihre Erfahrungen auf eine Art selbst zu steuern, die vor 1992 noch als Science Fiction abgetan wurde. Keine einzelne Person oder Instanz hat uneingeschränkte Kontrolle über die Art, wie ein Benutzer das Web erlebt (obwohl auch das durchaus versucht wird). In einer einzigen Sitzung kann ein Benutzer mit einem beliebigen Grad an Interaktion Inhalte von diversen Autoren oder Themenbereichen anfordern, die nichts oder nur wenig miteinander zu tun haben. Diese scheinbare Anarchie schafft neue Herausforderungen für die Entwickler und Autoren von Websites: 1. Abgesehen vom eigentlichen Inhalt gehört Kontext (ständige Signale, die sagen »Sie sind hier« oder »das finden Sie dort«) zu den wichtigsten Teilen einer effektiven Site. 2. Wenn Sie Ihre Annahmen über die Ziele und das Wissen der Benutzer nicht überprüfen, steuern Sie geradewegs auf eine Katastrophe zu.
4
|
Kapitel 1: Hypertext von innen
3. Die Verdoppelung von Inhalt erzeugt unnötige Belastungen beim Anwenderkomfort (und bei der Erstellung der Site). 4. Der Mangel an Grenzen, verlässlichen Annahmen und Kontext kann im Web zu unvorhersehbaren Beeinträchtigungen der Benutzerfreundlichkeit (Usability) führen. Oftmals ist es absolut notwendig, auf diese Schwierigkeiten einzugehen. Die enorme Offenheit des Webs erfordert Spezialwissen zur Informationsarchitektur und Benutzbarkeit des Webs. Da das Web fast schon wörtlich mit linearen Strukturen bricht, dürfen Web-Entwickler und -Autoren niemals vergessen, dass ihre Arbeit vor allen Dingen Zusammenhänge schafft und definiert.
URIs
|
5
KAPITEL 2
Mit HTML-Markup arbeiten
Das Wichtigste bei der Erstellung einer Website ist das Anlegen von Links. Darüber hinaus bietet die Hypertext Markup Language (HTML) aber noch viele weitere Funktionen und Möglichkeiten. HTML-Dokumente beschreiben den Hypertext und enthalten einen Großteil der Inhalte, die Besucher der Website zu sehen bekommen. Gleichzeitig enthalten die Dokumente die nötigen Links auf weitere Ressourcen, wie Präsentationsanweisungen, Skripte, Bilder, Video, Ton und so weiter. Sie werden sehen, dass es bei der Arbeit mit HTML oft darum geht, zu entscheiden, wann es besser ist, andere Technologien (oder Leute) für sich arbeiten zu lassen. HTML, wie auch die dazugehörige Software (z.B. Browser oder webzentrierte Entwicklungsumgebungen), wird seit seiner Erfindung 1992 beständig weiterentwickelt. In den mittlerweile fast 20 Jahren, die es HTML inzwischen gibt, hat sich eine Reihe von bewährten Vorgehensweisen (Best Practices) für das HTML-Markup und für dessen Einsatzgebiete herausgebildet. Eine klare HTML-Syntax ermöglicht die Erstellung eines verlässlichen Dokumentenbaumes für Ihre Inhalte und die Unterstützung zusätzlicher Schichten für Stile und Verhalten. Kapitel 5 beschäftigt sich mit den Funktionen und Möglichkeiten von CSS für die Interaktion mit dem Dokumentenbaum.
HTML-Syntax HTML und dessen striktere Variante XHTML definieren eine Reihe von Regeln, mit denen bestimmte Dokumententeile gekennzeichnet werden können. Hierzu gehören auch Regeln, die festlegen, wie diese Markierungen (das Markup) strukturiert werden. HTML-Parser (aber nicht XHTML-Parser) folgen hierbei der als »Postels Gesetz« bekannten Regel: »Be conservative in what you do, be liberal in what you accept from others.«
Während der Autor eines Dokuments bei der Verwendung von XHTML sehr präzise vorgehen muss, vergeben HTML-Parser deutlich mehr Fehler, reparieren Weggelassenes und entfernen überflüssige Markup-Elemente. Hierdurch wird erreicht, dass das Dokument für den Benutzer »funktioniert«, allerdings nicht immer mit der ursprünglich vom Gestalter gewünschten Struktur. (In HTML 5 gibt es für dieses Verhalten klare Definitionen. In der Vergangenheit variierte es von Browser zu Browser.)
|
7
Tags, Elemente und Attribute HTML definiert eine Reihe von Elementen, die bestimmten semantischen Bereichen zuzuordnen sind. Die Namen der Elemente sind entweder an bestimmte englische Begriffe angelehnt oder entsprechen diesen. Elemente definieren die Struktur des Dokuments und legen das Fundament für dessen Präsentation und Manipulation. Jedes Element eines Dokuments wird durch ein oder zwei Tags gekennzeichnet. Tags sind von spitzen Klammern (< und >) umgebene Marken, die den Namen des verwendeten Elements enthalten. Öffnende Tags beginnen mit einer öffnenden spitzen Klammer (). Schließende Tags enthalten nur den Namen des Elements, dem ein Schrägstrich vorangestellt wird. Elemente ohne eigene schließende Tags werden unterschiedlich behandelt: • Bei HTML-Elementen mit optionalem schließenden Tag darf dieses weggelassen werden. Dies ist besonders bei den Elementen li (Listeneintrag) und p (Absatz) der Fall. • HTML-Elemente, bei denen schließende Tags nicht erlaubt sind, unterscheiden sich nicht von öffnenden Tags anderer Elemente. • Bei der Verwendung von XHTML sind schließende Tags entweder zwingend vorgeschrieben oder zwingend verboten. Der Begriff »optional« kommt in XHTML nur selten vor. • Tags, die XHTML-Elemente ohne schließendes Tag kennzeichnen, müssen mit der Zeichenfolge /> abgeschlossen werden. Üblicherweise wird dem Schrägstrich ein Leerzeichen vorangestellt, um die Kompatibilität mit älteren Browsern sicherzustellen. Tags können beliebig viele Whitespace-Zeichen (Leerzeichen, Tabulatoren etc.) enthalten; Attribute können im öffnenden Tag in beliebiger Reihenfolge angegeben werden. Sämtliche Elemente können durch die Verwendung bestimmter Attribute modifiziert werden, auf die i.d.R. ein oder mehrere Werte folgen (z.B.: id="nav"). Bei der Verwendung von einfachem HTML wird nicht zwischen Groß- und Kleinschreibung unterschieden, während in XHTML die Namen von Elementen und Attributen prinzipiell kleingeschrieben werden müssen. Da XHTML ein XML-Dialekt ist, gibt es hier zwei zusätzliche Regeln: • Bei XHTML wird weitestgehend zwischen Groß- und Kleinschreibung unterschieden, was bei der Verwendung von Werten eine Rolle spielt, während HTML diesen Unterschied nur bei der Verwendung der Attribute class und id vorschreibt. • Wird in XHTML ein Attribut verwendet, muss dieses einen Wert besitzen. Während in HTML auch Attribute ohne Wert erlaubt sind, wird in XHTML üblicherweise der Name des Attributs im Wert wiederholt (z.B. checked="checked" anstelle von checked). Beispiel 2-1 zeigt einige in XHTML 1.0 gültige Markup-Formen.
8
|
Kapitel 2: Mit HTML-Markup arbeiten
Beispiel 2-1: XHTML 1.0-Codeschnipsel AcmeStore.com
Die erste Zeile von Beispiel 2-1 enthält drei Elemente, die ähnlich wie bei einer Matrjoschka-Puppe ineinander verschachtelt sind. Hierbei ist zu beachten, dass die Tags in umgekehrter Reihenfolge geschlossen werden müssen, wie Abbildung 2-1 zeigt. Wird diese Regel nicht beachtet, kann es leicht zu Pannen kommen.
Literale HTML-Tags werden genauso ineinander verschachtelt wie Matrjoschka-Puppen. Bei der Struktur … … …
werden die schließenden Tags in umgekehrter Reihenfolge der Einfügung Ihrer öffnenden Entsprechungen eingefügt.
Abbildung 2-1: Korrekt strukturierte HTML-Tags werden wie russische Matrjoschka-Puppen ineinander verschachtelt.
Beispiel 2-1 behandelt die Attributwerte ebenfalls gemäß den XHTML-Regeln. XHTMLWerte werden prinzipiell mit Anführungszeichen umgeben. Für HTML-Werte gibt es eine andere Regel: In bestimmten Fällen können Autoren Attributwerte ohne Anführungszeichen angeben. Diese Werte dürfen nur Buchstaben (a–z und A–Z), Ziffern (0–9), Bindestriche (ASCII Dezimal 45), Punkte (ASCII Dezimal 46), Unterstriche (ASCII Dezimal 95) und Doppelpunkte (ASCII Dezimal 58) enthalten. Wir empfehlen dringend die Verwendung von Anführungszeichen, auch wenn dies nicht zwingend vorgeschrieben ist. HTML 4.01 Specification, World Wide Web Consortium
Zeichenreferenzen innerhalb von Attributwerten werden im Abschnitt »Zeichen-Entities zur Definition von Nicht-ASCII-Zeichen« auf Seite 232 und im Kasten »URL-Kodierung im Detail: ASCII-Entities« auf Seite 255 besprochen.
HTML-Syntax
|
9
Seitenstruktur Hält der Browser Teile des Inhalts für HTML-Code, versucht er, diese anhand des enthaltenen Markups darzustellen. Selbst wenn das Dokument unvollständig oder seltsam strukturiert ist oder auf andere Weise nicht den Standards entspricht, kann ein Browser meist etwas darstellen, was der Absicht des Autors oft ziemlich nahe kommt. Damit ein Dokument gültig oder valide ist, muss es jedoch eine Reihe von korrekt strukturierten Elementen und die dazu passenden Inhalte enthalten. Ein gültiges HTMLDokument enthält die folgenden Teile in der hier angegebenen Reihenfolge: 1. die Dokumenttyp-Deklaration 2. genau ein html-Element, das alle anderen Elemente im Dokument umgibt 3. innerhalb des html-Elements genau ein head-Element 4. innerhalb des head-Elements genau ein title-Element sowie ggf. benötigte link-, script-, base- und meta-Elemente 5. innerhalb des html-Elements und nach dem head-Element das body-Element des Dokuments. Dieses enthält (bzw. verweist auf) sämtliche Teile der Seite, die der Besucher angezeigt bekommt. 6. innerhalb des body-Elements mindestens ein Block-Element (z.B. p oder div)
Darstellungsmodi, Varianten von HTML und Dokumenttyp-Deklarationen Als ich dieses Buches schrieb, hatte sich HTML über einen Zeitraum von mehr als 17 Jahren beständig weiterentwickelt. Inzwischen gibt es fünf verschiedene Versionen, von denen die aktuellste, HTML 5, zwar immer beliebter wird, aber noch nicht vollständig ist. Das World Wide Web Consortium (W3C) hat außerdem eine Empfehlung für XHTML, die XML-kompatible Variante von HTML 4.01, veröffentlicht. Auch wenn es noch zu früh ist, die guten Seiten von HTML 5 zu benennen, werden wir in diesem Buch auf neue HTML 5-Funktionen eingehen, sofern sie die bewährten Vorgehensweisen beeinflussen.
Seit der Version 1.0 enthielt HTML eine sogenannte Dokumenttyp-Deklaration, die ganz am Anfang des Dokuments eingefügt wird. Hiermit wird angegeben, welche HTML-Version das Benutzerprogramm für die Darstellung des Dokuments verwenden soll. Bis 2001 wurde diese Angabe jedoch weitgehend ignoriert. Die Dokumenttyp-Deklaration für HTML 4.01 Strict sieht beispielsweise so aus:
Den größten Einfluss haben Dokumenttyp-Deklarationen darauf, wie die einzelnen Elemente dargestellt werden. Verschiedene DOCTYPEs sorgen für die Aktivierung unter10
|
Kapitel 2: Mit HTML-Markup arbeiten
schiedlicher Darstellungsmodi. (Sie definieren auch, welche Erwartungen HTML-Validatorprogramme an die Elemente stellen.) Vermutlich kennen Sie »DTD« als Akronym für den Begriff »Document Type Definition«. Die DTD ist eine maschinenlesbare Definition, auf die mit der DOCTYPE-Deklaration verwiesen wird. Deklaration und Definition sind also vollkommen unterschiedliche Dinge. Die Deklaration verweist auf die Definition, und nur die Definition wird als DTD bezeichnet. Auf der Website zu diesem Buch (http://www.htmlcssgoodparts.net) werden die Feinheiten von DTD und DOCTYPE-Deklaration genauer untersucht.
HTML oder XHTML? Die gegenwärtig am häufigsten verwendeten Geschmacksrichtungen von HTML sind zwei Varianten von HTML 4.01. Während die eine Variante der traditionellen HTML-Syntax folgt, wurden für XHTML Teile der Syntax neu definiert, um den strikteren Anforderungen von XML zu entsprechen. Wenn XHTML mit dem richtigen MIME-Typ (siehe Tabelle A-1 im Anhang) übergeben wird, wird es auch gemäß den XML-Regeln geparst. Die Regeln von »normalem« HTML sind etwas lockerer gefasst. So dürfen schließende Tags weggelassen werden, und es wird kaum zwischen Groß- und Kleinschreibung unterschieden. Bei XHTML müssen dagegen alle Elemente korrekt mit einem schließenden Tag bzw. /> beendet werden und müssen komplett in Kleinbuchstaben geschrieben sein. XHTML hat einen großen Nachteil: Der vorgeschriebene MIME-Typ wird vom Internet Explorer nicht unterstützt. Eine detaillierte Betrachtung dieses Problems finden Sie in Kapitel 14. Dennoch bietet sorgfältig formatiertes XHTML (oder HTML, das den Vorschriften von XHTML entsprechend geschrieben wurde) einen noch größeren Vorteil, der zur Auswahl der Markup-Beispiele dieses Buches und den dazugehörigen externen Ressourcen geführt hat. Da die für XHTML nötige Syntax strenger ist, sind XHTML-Quellcode-Fragmente deutlich leichter lesbar als ihre HTML-Entsprechungen, und die Regeln für gültiges XHTML weniger verwirrend. HTML 5 enthält Unterstützung für eine XML-Schreibweise, macht dieses aber nicht zur Pflicht.
Strict, Transitional oder Frameset? Im Laufe der Entwicklung von HTML wurden einige Elemente verworfen (»deprecated«). Das heißt, sie gelten als veraltet und ihre Verwendung wird offiziell nicht mehr unterstützt. Gleichzeitig wurde die Definition mancher Elemente verändert: Sie müssen innerhalb bestimmter anderer Elemente stehen oder bestimmte andere Elemente enthalten.
Darstellungsmodi, Varianten von HTML und Dokumenttyp-Deklarationen
|
11
Kurz gesagt besteht der Hauptunterschied zwischen den HTML-Varianten Strict, Transitional und Frameset in der Definition, was erlaubt ist und wie strikt es umgesetzt wird. Die Strict-Versionen besitzen die strengsten Anforderungen an die Inhalte oder Behälter bestimmter Elemente und haben nur eine geringe Toleranz gegenüber der Verwendung veralteter Elemente. Die Variante Frameset ist für ein bestimmtes Szenario zuständig: für Dokumente, die eine Reihe von frame-Elementen definieren. Eine detaillierte Abhandlung von Framesets und Frames finden Sie in Kapitel 14. Abschließend sollten Sie bedenken, dass iframe-Elemente trotz ihres Namens nicht zum Dokumenttyp Frameset gehören, sondern zu Transitional. HTML 5 entspricht im Prinzip dem Typ HTML 4.01 Strict, der um neue HTML 5-Funktionen und -Fähigkeiten erweitert wurde.
In CSS 3 können diese Definitionen durch die Eigenschaft box-sizing unabhängig vom Dokumenttyp vorgenommen werden. Diese besitzt zwei mögliche Werte: content-box oder border-box. Das zu diesen Werten gehörige Darstellungsverhalten wird detailliert in Kapitel 6 behandelt.
Die Geschichte der zwei Boxmodelle Aktuelle Browser verwenden DOCTYPE-Deklarationen als eine Art »Schalter«, um festzustellen, nach welchem Boxmodell die Maße für die Darstellung berechnet werden. Die Größe einer in HTML definierten Elementbox kann durch verschiedene CSS-Eigenschaften verändert werden. Hiermit können verschiedene Eigenschaften, wie der Inhaltsbereich selbst, Abstände (padding etc.), Rahmen (border) usw., unabhängig voneinander gesteuert werden. Ältere Browser berechnen deren Größe substraktiv: Innenabstände und Rahmen werden hierbei dem Inhaltsbereich zugerechnet. Außenabstände werden, was die enthaltenen Elemente angeht, ebenfalls unterschiedlich behandelt. Gemäß der CSS 2.1-Spezifikation müssen die Berechnungen für den Inaltsbereich jedoch additiv vorgenommen werden. Das heißt, Innenabstände, Rahmen und Außenabstände werden separat von der Größe des Inhaltsbereichs berechnet. Natürlich ist das Web noch immer voll mit Layouts, die nach der älteren Layoutmethode gestaltet wurden. Mithilfe der DOCTYPE-Deklaration kann der Autor einer Seite ausdrücklich festlegen, nach welchem Layoutmodell die Blockelemente der Seite dargestellt werden sollen. Manche Deklarationen sorgen dafür, dass die Rendering-Engines sich an die Regeln der CSS 2.1-Spezifikation halten, während andere Deklarationen dafür sorgen, dass die Seiten nach der älteren Methode (dem sogenannten Quirks Mode) dargestellt werden. Ohne Angabe eines DOCTYPEs wird standardmäßig das alte Boxmodell verwendet.
12
|
Kapitel 2: Mit HTML-Markup arbeiten
Sofern die Unterscheidung wichtig ist, wird in den Quellcode-Beispielen dieses Buches das Boxmodell gemäß der CSS 2.1-Spezifikation verwendet. Eine ausführliche Liste möglicher DOCTYPEs und der verschiedenen Browser-Darstellungsmodi finden Sie unter http://hsivonen.iki.fi/doctype/.
Der richtige Dokumenttyp für Ihr Projekt In den Händen erfahrener Entwickler ist die Wahl des richtigen Dokumenttyps eine Frage persönlicher Vorlieben. Ich verwende prinzipiell XHTML 1.0 Transitional für neue Projekte und komplett neu aufgebaute Redesigns. Dank der Beständigkeit der XML-Regeln erscheint mir das resultierende Markup während der Produktions- und Qualitätssicherungsphase eines Projekts wesentlich leichter verständlich. Allerdings sind meine Bedürfnisse nicht die gleichen wie Ihre. Um die wichtigsten Anforderungen für Ihr Projekt herauszufinden, sollten Sie sich vor der Wahl eines Dokumenttyps die folgenden Fragen stellen: Welche »Geschmacksrichtung« von HTML verwendet der Auftraggeber aktuell in seinen anderen Online-Präsenzen? Allgemein ist es am besten, sich an die Konventionen bereits aktiver Seiten zu halten. Erwartet irgendjemand, dass die Inhalte in einem Datenspeicher abgelegt werden, der von verschiedenen Systemen aus zugänglich sein soll? In diesem Fall ist XHTML eine deutlich bessere Wahl, da Portabilität eine der größten Stärken von XML ist. Wie wahrscheinlich ist es, dass Ihre Arbeitsergebnisse anhand von Informationsalgorithmen wie Suchen-und-Ersetzen-Funktionen verarbeitet werden? Informationsalgorithmen funktionieren besser, wenn Dokumententypen des Typs Strict verwendet werden. Bleibt noch die Frage, wie Sie Ihre Werkzeuge benutzen. Werkzeuge, die Ihnen vertraut sind, sollten Sie nur austauschen, wenn es keine andere Möglichkeit gibt.
Die schönen Seiten: universelle Attribute Sie werden feststellen, dass die Attribute class und id in diesem Buch recht häufig verwendet werden. Dies sind sogenannte universelle Attribute, die mit beliebigen HTMLElementen verwendet werden können, selbst mit dem Element body. Neben class und id gibt es noch vier weitere Attribute, die ähnlich oft vorkommen: • title • lang/xml:lang
Die schönen Seiten: universelle Attribute
|
13
• dir • style dir legt die Schreibrichtung fest, style wird in Kapitel 14 behandelt.
Stylesheet-Anweisungen per »class« und »id« einbinden Zwei Attribute, die Sie mit fast allen Elementen verwenden können, sind class und id. Hierbei können einem Element mehrere Werte für class zugewiesen werden, während für id nur ein Wert möglich ist. Mehrere Werte für class werden durch Leerzeichen getrennt, z.B. . Gültige Werte für class und id dürfen nur Buchstaben, Zahlen, Bindestriche und Unterstriche enthalten. Die Werte sollten ausschließlich mit Buchstaben oder Zahlen beginnen. In Internet Explorer 6 ist es allerdings möglich, auch Werte zu verwenden, die mit einem Unterstrich beginnen – ein Versehen, das es Stylisten ermöglicht, für diesen Browser spezielle Anweisungen zu formulieren. Wichtiger noch ist allerdings die Frage, wo class- und wo id-Attribute verwendet werden. Als Faustregel kann man sich merken: class-Attribute sollten für häufig vorkommende Elemente benutzt werden, die sowohl im Design als auch in der Präsentation gemeinsamen Zwecken dienen, deren Verwendung aber nicht vorhersehbar ist. Auf vielen Websites wird das class-Attribut auch für body-Elemente von thematisch verwandten Seiten verwendet, wie etwa für die Seiten »Über uns« und »Kontakt«. Auch die Struktur eines Gestaltungstemplates für eine Website kann Aufschluss darüber geben, wo und wie class und id eingesetzt werden sollten. In den von mir erstellten Website-Templates verwende ich so gut wie immer die folgenden ids: • hauptteil • kopfteil • hauptnavigation • haupttext • seitenleiste • fussteil • unternavigation Wenn Sie sich die Liste ansehen, werden Sie feststellen, dass es keine Werte gibt, die sich auf bestimmte Positionen innerhalb der Seite oder der Website (z.B. linke oder rechte Spalte), Farben oder Größen beziehen. Auf ähnliche Weise werden die Werte für classAttribute ausgewählt: Werte, die sich auf bestimmte Abschnitte oder Zwecke (z.B. fehlermeldung) beziehen, kommen regelmäßig vor, während Verweise auf absolute Größen oder Farben nicht verwendet werden. Die einzige »Ausnahme« von dieser Regel finden Sie bei der Gestaltung von Formularen, wo minimal subjektive class-Werte wie kurz, mittel oder lang häufig auftauchen, um Paare aus Beschriftung und Formularfeld nicht einzeln mit Stilen versehen zu müssen.
14
|
Kapitel 2: Mit HTML-Markup arbeiten
Inhalt beschreiben mit »title« und »lang« Neben id und class wurden in HTML 4.x und XHTML 1.x zwei weitere universelle Attribute eingeführt, mit denen Metadaten über die Sprache und die Inhalte bestimmter Elemente angegeben werden können. Hierbei kommt das Attribut title deutlich häufiger zum Einsatz. Sein Wert ist eine beliebige Zeichenfolge, die den Inhalt des Elements kurz beschreibt. Es kann aber auch dafür verwendet werden, den Inhalt eines Linkziels zu beschreiben, eine Technik, die häufig bei Wikipedia verwendet wird. Außerdem können Browser die Werte für das title-Attribut auch zurückstellen und als Metadaten für das Dokument darstellen. Richtig implementiert, können title-Werte den Benutzern eine enorme Hilfe sein, wenn nadelgroße Informationen in heuhaufengroßen Informationssammlungen gefunden werden sollen. Das Attribut title ist vergleichbar mit dem alt-Attribut für Bilder. Der Hauptunterschied ist, dass alt als Alternative für ein nicht darstellbares Bild verwendet wird, während title eine Beschreibung des Inhalts ist und nicht dessen Ersatz. In aktuellen Browsern wird der Attributwert von title in Form eines Tool Tip dargestellt, wenn sich der Mauszeiger über dem dazugehörigen Element befindet, wie in Abbildung 2-2 gezeigt. Sind die Tool Tips zu lang, werden sie von manchen Browsern nicht vollständig angezeigt. An welcher Stelle der Text abgeschnitten wird, hängt vom verwendeten Browser ab.
Abbildung 2-2: Ein mit dem »title«-Attribut erzeugter Tool Tip in Firefox (Mac)
Das Attribut lang würdigt die Tatsache, dass das Web tatsächlich »World Wide« ist. Ähnlich wie title kann es verwendet werden, um zusätzliche Informationen zum Inhalt eines Elements oder zum Ziel eines Links bereitzustellen. Das Attribut lang macht das Gleiche für fremdsprachliche Inhalte. Wenn Sie das Attribut lang verwenden, sind Sie äußerst höflich, da es Besuchern beim Verständnis fremdsprachiger Inhalte hilft, selbst wenn die genaue Bedeutung der Inhalte nicht bekannt ist. Außerdem benötigen Bildschirmleseprogramme akkurate lang-Attribute oder einen Content-Language-Header, um fremdsprachige Inhalte richtig »auszusprechen«. Als Gegenstück zu lang gibt es noch das Attribut hreflang. Es wird verwendet, um anzuzeigen, dass die Ressource, auf die ein Link verweist, in einer anderen Sprache verfasst ist als das aktuelle Dokument.
Die schönen Seiten: universelle Attribute
|
15
Wenn XHTML mit dem MIME-Typ application/xhtml+xml MIME an den Browser übergeben wird, muss anstelle von lang das Attribut xml:lang verwendet werden. Werden lang oder xml:lang verwendet, um den Inhalt eines ganzen Dokuments zu beschreiben, sollte das Attribut nicht dem html-Element, sondern dem body-Element zugewiesen werden.
Der Wert für das lang-Attribut (und den HTTP-Response-Header Content-Language) wird aus einer Liste verschiedener Landeskürzel nach ISO-Standard ausgewählt und gemäß den Regeln der IETF (Internet Engineering Task Force, eine Organisation, die sich mit der technischen Weiterentwicklung und Verbesserung des Internets befasst) strukturiert. Weitere Informationen über die effektive Verwendung des title-Attributs in Links finden Sie in Kapitel 8 im Abschnitt »Effektiver Inhalt für Links und Werte für das ›title‹-Attribut« auf Seite 139. Gängige Werte für lang finden Sie in Tabelle 2-1. Tabelle 2-1: Häufig für das Attribut »lang« bzw. den Content-Language-Header verwendete Werte Sprache
Wert für lang/Content-Language
Englisch
en
Englisch (amerikanisch)
en-US
Englisch (britisch)
en-GB
Chinesisch (vereinfacht)
zh-Hans
Chinesisch (traditionell)
zh-Hant
Chinesich (taiwanesisch, keine Schreibweise angegeben)
zh-TW
Spanisch
es
Japanisch
ja
Französisch
fr
Portugiesisch
pt
Portugiesisch (brasilianisch)
pt-BR
Deutsch
de
Arabisch
ar
Russisch
ru
Koreanisch
ko
Das Attribut »contenteditable« in HTML 5 Die Spezifikation von HTML 5 erweitert HTML um einige neue universelle Attribute, u.a. contenteditable. Dieses Attribut wird bereits von den meisten modernen Browsern unterstützt und soll bei der Erstellung von Text/WYSIWYG-Editoren im Browserfenster helfen. Diese Art von Bearbeitungsmöglichkeit finden Sie beispielsweise in Online-Werkzeugen zur Erstellung von Blog-Artikeln.
16
|
Kapitel 2: Mit HTML-Markup arbeiten
Das Attribut contenteditable ermöglicht dem Autor, die Inhalte bestimmter Elemente als »editierbar« zu kennzeichnen. Innerhalb dieser editierbaren Bereiche soll es Benutzern z.B. möglich sein, Textteile auszuwählen, per Kopieren und Einfügen (auch per Drag and Drop) zu verändern, zu verschieben oder zu löschen, eine Zeichenformatierung (fett, kursiv, bestimmte Farben etc.) anzugeben oder sogar Hyperlinks anzulegen. Damit der Browser die zur Bearbeitung nötigen Werkzeuge bereitstellt, reicht es allerdings nicht aus, ein Element mit dem Attribut contenteditable zu versehen. Immerhin sollte es möglich sein, bestimmte Aktionen durchzuführen, für die es gängige Tastaturkürzel gibt (z.B. Ctrl-X zum Ausschneiden oder Ctrl-B und Ctrl-I für »fett« bzw. »kursiv«). Manche Browser stellen sogar ein Kontextmenü mit Funktionen zur Textbearbeitung bereit, das Sie durch einen Rechtsklick in den mit contenteditable markieren Bereich öffnen können. Hierdurch stehen möglicherweise weitere Funktionen zur Zeichenformatierung bereit, für die es keine üblichen Tastaturkürzel gibt, etwa das Ändern von Schriftgröße oder -farbe des ausgewählten Textes. Möglicherweise folgen andere Browser diesem Beispiel (z.B. um Hyperlinks einzufügen). Benötigen Sie eine einheitliche Benutzerschnittstelle für contenteditable-Bereiche, kommen Sie nicht umhin, etwas in JavaScript zu programmieren. So kann leicht ein Button definiert werden, um ausgewählten Text fettgedruckt darzustellen (anstatt Besucher zur Verwendung eines Tastaturkürzels zu zwingen). Damit das funktioniert, müssen Sie per JavaScript eine Verbindung zwischen Ihrem Button und der auszuführenden Aktion schaffen. (Die HTML 5-Spezifikation definiert eine Reihe von APIs, über die ein Scripting zusammen mit contenteditable realisiert werden kann. Allerdings fehlt in diesem Buch der Platz, um näher darauf einzugehen.) Eine weitere Einschränkung von contenteditable besteht darin, dass es dem Benutzer, für sich genommen, keine Möglichkeit gibt, die veränderten Inhalte auch zu sichern. Diese Aufgabe wird ebenfalls dem Autor überlassen.
Die Trennung von Inhalt, Strukur, Präsentation und Verhalten Stellen Sie sich ein Wohnhaus vor. Die einfachste Struktur dieser Art soll eine beliebige Zeit halten. Sie besitzt demnach ein stabiles Fundament, Außenmauern und einen Dachstuhl. Auf der Clientseite werden Mauern, Fundament und Dachstuhl von der strukturellen Schicht gebildet, sprich: vom Markup. Es definiert die allgemeine Form einer Website. Wenn Sie anfangen, Ihr Haus auszubauen, können Sie Dinge hinzufügen wie Dachziegel, Innenwände, vielleicht sogar einen Wintergarten. Dies entspricht der Präsentationsschicht Ihrer Website, die komplett mit CSS realisiert wird. Ist der Dachstuhl nicht stabil gebaut, fallen Ihnen beim nächsten Sturm die Ziegel auf den Kopf. Auf die gleiche Weise ist es schwierig, CSS zu verwenden, wenn das Markup nicht vernünftig strukturiert ist.
Die Trennung von Inhalt, Strukur, Präsentation und Verhalten
|
17
Ein gutes Haus besitzt außerdem Dinge wie Heizung, Türen, Fenster, Elektrizität und ein Abwassersystem. Oft sorgen diese Dinge dafür, dass man sich in seinem Haus erst richtig wohlfühlt. So ähnlich ist das mit der Verhaltensschicht Ihrer Website. Dieser Teil reagiert am direktesten auf das Benutzerverhalten. Ohne die übrigen Teile der Architektur und die technischen Einrichtungen wird die Verhaltensschicht jedoch nicht sonderlich effektiv sein. Und was ist mit dem Inhalt? Ein Haus ist dafür gedacht, Menschen und ihrem Besitz Schutz zu bieten. Analog dazu soll eine Website das ideale Behältnis für jede Menge Inhalte sein. Jede HTML-Seite enthält eine Markup-Struktur, die bestimmte Inhalte umgibt.
Die Trennung in der Praxis Arbeitet ein Entwickler nach diesen Prinzipien, sind die Schichten der Clientseite äußerst unabhängig von den Details der übrigen Schichten. Diese Unabhängigkeit wird zwar niemals vollständig sein; bestenfalls ermöglicht diese Trennung aber die Wiederverwendung bereits bestehender Ressourcen. In jedem Fall geht das Prinzip der Trennung von den folgenden Abhängigkeiten aus: 1. Ohne eine effektive Präsentation verliert das Verhalten einer Website ihren Biss. 2. Die Präsentation einer Site hängt direkt von der Qualität der darunterliegenden Struktur ab. 3. Ohne sorgfältig zusammengestellte Inhalte können Sie auch keine solide Struktur für die Website erstellen. Jedenfalls ist es relativ einfach, einen Grad an »Schichtenunabhängigkeit« zu erreichen, der die Auswirkungen von Veränderungen möglichst gering hält. Wenn Sie also eine CSS-Klasse definieren, die einem Element nur zugewiesen wird, wenn ein Benutzer mit diesem interagiert, können Sie unbegrenzt viele Veränderungen an der Präsentation eines Elements vornehmen, ohne hierfür das JavaScript verändern zu müssen, das sein Verhalten definiert. Anders herum können Sie beliebige Änderungen am Stylesheet vornehmen und die Präsentation einer Site vollkommen umkrempeln, ohne hierfür die Struktur oder den Inhalt anfassen zu müssen. Dieses Vorgehen nennt man auch den »Weg des CSS-Zen« (mehr dazu lesen Sie im Abschnitt »Die Funktionsprinzipien des CSS-Zen« auf Seite 60).
Mit Dokumentenbäumen arbeiten Wird eine Website neu erstellt, besteht ein Großteil der Arbeit in der Entwicklung einer einfachen HTML-Struktur. Diese kann dann von CSS (und möglicherweise JavaScript) als Rahmen (Framework) für die Präsentation und das Verhalten benutzt werden. Hierbei geht es um die Erstellung einer Grundstruktur (Template), die viele Dokumente als Fundament verwenden können. In dieser Arbeitsphase geht es weniger um den Inhalt als um die allgemeinen Strukturen, die den Inhalt umgeben. Beispiel 2-2 zeigt das body-Element einer einfachen HTML-Dokumentenstruktur. 18
|
Kapitel 2: Mit HTML-Markup arbeiten
Beispiel 2-2: Die Struktur eines einfachen HTML-Dokuments ... ... ... ... ... ...
...
In der einfachen Implementierung wird nur die erste Stylesheet-Regel verwendet. Die vier b-Elemente werden nicht benötigt, genauso wenig wie das zusätzliche Hintergrundbild. Da der Internet Explorer noch keine abgerundeten Ecken unterstützt, bekommen dessen Benutzer auch keine zu sehen. (Wir sind uns darüber im Klaren, dass die hierfür verwendeten Eigenschaften -webkit-border-radius und -moz-border-radius nicht standardkonform sind.) Die komplexere Implementierung runder Ecken funktioniert auch für IE. Mit etwas Erfahrung springen einem die Probleme aber sofort ins Auge: • Das Markup ist unwiderruflich mit der Präsentation verbunden. Wenn sie die abgerundeten Ecken aus dem Design entfernen, werden auch die nur für diesen Zweck ins Markup eingefügten b-Elemente entfernt. • position, z-index und die damit verbundenen Schwierigkeiten gelten zwar nur für diese Implementierung abgerundeter Ecken. Jedoch haben die meisten unnötig komplexen Gestaltungen einen ähnlich hohen Anteil an »Übergepäck«. Das Ergebnis dieses unnötigen »Zeugs« ist immer das gleiche: Zusätzliches Markup und Stilregeln verringern die Flexibilität der Site durch ungewollte Beschränkungen des Designs.
Die vier wichtigsten Angewohnheiten für effektive Stylesheets
|
51
• Eine große Menge an Markup-Code und Stilregeln erhöht die Wahrscheinlichkeit von Eingabefehlern und Darstellungsproblemen. Sowohl die Vorteile der Schlichtheit, wie auch die Nachteile ihres Fehlens scheinen sich zu vervielfachen. Wenn Sie in Ihren Templates nur eine komplexe Implementierung verwenden, sind die Folgen vermutlich noch unerheblich. Sobald die Komplexität aber die erste oder zweite Instanz überschreitet, führt das zwangsläufig zu Templates, die unter ihrem eigenen Gewicht aus unlösbaren Konflikten, Darstellungsfehlern und Wartungsaufwand zusammenbrechen. Hält man sich dagegen an die Prinzipien der Schlichtheit, lässt sich CSS-Zen bei Redesigns und neuen Projekten mühelos anwenden. Sobald Sie Ihre Templates auf das Wesentliche reduziert haben, steht Ihnen auch nichts mehr im Weg. Der wichtigste Schritt bei der Umsetzung der Schlichtheit besteht also in der Erkenntnis, welche Dinge wesentlich sind oder wesentlich sein werden.
Schlichtheit bei sehr großen Sites Was Schlichtheit tatsächlich bedeutet, hängt teilweise von der Größe eines Projekts ab. Oft ist es hier für Entwicklungsteams äußerst schwierig, sämtliche Sonderfälle der Präsentation und anderer Akzente zu beachten, die auf kleineren Sites vertretbar sind. Im Vergleich zu den Quellcodebeispielen in diesem Buch müssen diese Teams die Anzahl der id-Attribute zugunsten besserer Wartbarkeit oft reduzieren, während die verbleibenden ids einem strikten Standard folgen. In der Praxis nehmen Designer dieses »Ausdünnen« oft auf Anraten der Entwickler vor. Dies geschieht aus drei Gründen: Geschäftsziele, erwartete Besucherziele und Liefertermine. Das Ergebnis einer solchen Zusammenarbeit ist oft ein Gerüst aus wenigen Templates, die ihrerseits oft nur auf einem einzelnen, sehr einfachen Template basieren. Das Grundlayout wird in kleine, separate Bausteine aufgeteilt. Diese landen jeweils in einem eigenen Container, der eines oder mehrere der folgenden id- oder class-Attribute trägt: • #kopfteil • ul#navigation • #haupttext • #fussteil In die Seite eingefügte Bestandteile können dann automatisch mit Inhalt gefüllt werden. Die Art der Inhalte hängt typischerweise von den angeforderten Ressourcen ab. Außerdem spielt es eine Rolle, welchen Authentifizierungsstatus der Besucher hat und ob auch Inhalte von Drittanbietern eingebunden werden müssen. Die Quellcodebeispiele in diesem Buch unterscheiden sich vom Markup auf großen Sites besonders bei der Behandlung der Navigation, die aufgrund von Sachzwängen stark vereinfacht wird. So werden Sie auf großen Sites nur selten Verfahren zur Bildersetzung
52
|
Kapitel 5: Effektive Stylesheets und Dokumentenstrukturen
(image replacement) finden. Der Grund ist die Vielzahl an unterschiedlichen Benutzeranforderungen, die die Ressourcenkosten für die Bildersetzung in die Höhe treiben können. Content-Management-Systeme von der Stange und Blogging-Plattformen arbeiten ebenfalls oft nach diesem Designprinzip. Hier ist der Grund jedoch nicht in den Bedürfnissen der Benutzer zu suchen, sondern in der Vielfalt der Anwendungsmöglichkeiten.
Angewohnheit 2: Flexibilität Damit eine Site flexibel bleibt, muss das Verhältnis zwischen kurz- und langfristigen Notwendigkeiten ausgewogen sein. Hierbei geht es in erster Linie um die Menschen. Jedes Projekt hat schließlich eine einmalige Kombination aus Auftraggebern, Benutzern, Anforderungen, Zeitplan und Erwartungen an die Lebensdauer (oder sollte sie zumindest haben). In einem so variablen Umfeld verändern sich natürlich auch die Definitionen. Die Flexibilität einer Webapplikation ist anders definiert als die Flexibilität eines Datenarchivs. Websites, die Veranstaltungen bewerben, können sich komplett von den beiden ersten Formen unterscheiden. Während die Flexibilität in den ersten beiden Fällen hauptsächlich aus der Wiederholbarkeit zukünftiger Arbeitsabläufe besteht, sind sich schnell ändernde Websites am flexibelsten, wenn ihre Bestandteile (inklusive des Markups) für spätere, ähnliche Projekte wiederverwendet werden können. Am wichtigsten ist Flexibilität für den Prozess, die Ziele der Site und die Arbeitsbedingungen. Erfolgreiche Gestalter beachten diese Dinge, bevor sie mit der Arbeit beginnen. Auf die Ergebnisse bezogen heißt das: Das Arbeitsergebnis eines Gestalters ist am flexibelsten, wenn seine Arbeitsmethoden sich an den wahren Gründen für die Erstellung der Website orientieren.
Die Anwendung der Flexibilität basiert hauptsächlich auf zwei Dingen: progressive Verbesserungen und »Overbuilding« (das Übererfüllen der Anforderungen). Um Webapplikationen fortschreitend verbessern zu können, müssen Entwickler oftmals mehr als eine Codebasis pflegen: Eine läuft auf dem Client, um die Serverlast zu verringern, und eine läuft auf dem Server, falls der Benutzer clientseitige Skripts deaktiviert hat.
Auf progressive Verbesserungen wurde implizit bereits im Abschnitt »Die Trennung von Inhalt, Strukur, Präsentation und Verhalten« auf Seite 17 eingegangen. Die Inhalte werden von Markup umgeben, auf dem die Präsentationsschicht in Form von CSS aufsetzt. Über diesen beiden liegt eine abschließende Skripting-Schicht, die Verhalten wie Fehlerbehandlung und Interaktivität bereitstellt. Werden diese Bestandteile korrekt implementiert, verlaufen die Abhängigkeiten nur in eine Richtung, und das Verhalten basiert auf den Erfordernissen des Inhalts und Markups. Selbst wenn die Präsentationsschicht entfernt wird, sollte die Site weiterhin benutzbar sein.
Die vier wichtigsten Angewohnheiten für effektive Stylesheets
|
53
Im Webdesign haben sich einige Praktiken und Fehler etabliert, die die Erstellung einer flexiblen Webapplikation durch progressive Verbesserungen erschweren können. Diese Hässlichkeiten werden in Kapitel 14 beschrieben.
Die zweite Säule der Flexibilität besteht im Overbuilding, dem Übererfüllen der Anforderungen. So hat fast jedes Template Stellen, an denen Markup eingefügt werden kann, um beispielsweise die Anwendung klassenbasierter Regeln und die absolute Positionierung von Elementen zu erleichtern. Ihre Anwendung hängt von den langfristigen Anforderungen Ihres Projekts ab und davon, ob die erstellen Ressourcen wiederverwendbar sein müssen. Bei meiner Arbeit verwende ich oft class-Attributwerte wie abschnitt oder artikelMetadaten. Das mache ich sogar bei Sites, bei denen diese aufgrund der Designrichtlinien auch weggelassen werden könnten. Ich denke hier besonders an die ästhetische und strukturelle Weiterentwicklung der Site. Nach den anfänglichen Anforderungen werden möglicherweise noch keine speziellen Stile für bestimmte Abschnitte oder Metadaten benötigt. Das kann sich mittel- oder langfristig aber leicht ändern. Der Nachteil des Overbuilding besteht darin, dass es direkt mit dem Ziel der Schlichtheit im Konflikt stehen kann, was wiederum den Anspruch an eine gute Balance unterstreicht. Um die Notwendigkeit einzuschätzen, können Sie sich drei Fragen stellen: 1. Kann jedes zusätzliche Element mit einem relevanten oder beschreibenden classoder id-Wert versehen werden? 2. Soll das zusätzliche Markup mehrere mögliche Präsentationsanforderungen unterstützen oder nur eine? 3. Ist es absehbar, dass die Site sich im Laufe der Zeit weiterentwickelt? Wenn Sie alle drei Fragen mit »Ja« beantworten können, ist es nicht nur akzeptabel, sondern mehr als wünschenswert, die Templates mit zusätzlichem Markup zu versehen. Der Schlüssel für dessen Wartung liegt in der sorgfältigen Auswahl der Elemente und Attribute und einheitlichen Ergebnissen.
Flexibilität, eigene Bibliotheken und die Wiederverwendung von Code Bei der langfristigen Planung können Entwickler die meisten Ressourcen einsparen, wenn sie einen Template-basierten Ansatz verfolgen, wie bereits im Bezug auf Flexibilität beschrieben. Teams ohne nennenswerte externe Unterstützung verwenden gerne ein PublishingSystem von der Stange, um die eigenen Ressourcen zu schonen, und benutzen dann einen internen Prozess, um dessen Ausgaben an die eigenen Erfordernisse anzupassen. Erfahrene freischaffende Entwickler arbeiten oft lieber direkt mit den Webtechnologien. Sie gehen das Problem oft anders an und entwickeln im Laufe der Zeit ihre eigenen Markup-Bibliotheken, Stylesheets und Codesammlungen. Wieder andere, mich selbst eingeschlossen, verwenden spezialisierte, aber effektive Produktionstechniken. Sie beginnen nach Möglichkeit jedes Projekt mit dem sprichwörtlichen unbeschriebenen Blatt. Das
54
|
Kapitel 5: Effektive Stylesheets und Dokumentenstrukturen
heißt: Der Prototyping-Prozess (siehe im Abschnitt »Prototyping und Layout« auf Seite 258) wird manuell durchgeführt, allerdings mit so wenig geistigem Aufwand, dass das übrige Gehirnschmalz dazu verwendet werden kann, die besonderen Anforderungen des jeweiligen Projekts zu verstehen. Teams mit externer Unterstützung, die an großen Sites arbeiten, können die Vorteile beider Methoden kombinieren: Der beste Ansatz besteht oft darin, gemäß den Anforderungen neue »Module« zu entwickeln und ansonsten bereits bestehende Projekte wiederzuverwenden. Dieser Ansatz funktioniert nur mit internen Produktionsstandards und Stilrichtlinien, die die Arbeit der Gestalter folgendermaßen beeinflussen: • Der größte Teil der Präsentationsschicht wird über class-Attribute realisiert und ist umfassend dokumentiert. Änderungen und Erweiterungen können nur vorgenommen werden, nachdem ein mühsamer Genehmigungsprozess durchlaufen wurde. Dieser ist hauptsächlich dafür gedacht ist, einzelne Teammitglieder von eigenen »Verbesserungen« abzuhalten. • Einzelne, austauschbare Teile der Site sind oft »anonymer« als nötig. Ihr Verwendungszweck ist im Produkt selbst wenig bis gar nicht dokumentiert. Dieser Umstand basiert einerseits auf Notwendigkeit, andererseits auf Trägheit: Bevor CSS ausreichend unterstützt wurde, konnte ein effektives Site-Layout nur über die Verwendung verschachtelter table-Elemente erreicht werden. • Unvermeidliche Lücken zwischen den Standardanforderungen (siehe im Abschnitt »Abgestufte Unterstützung« auf Seite 281) und den Fähigkeiten der Browser werden durch die rohe Gewalt von JavaScript-Frameworks und eingebetteten StylesheetHacks gelöst. • Die Übererfüllung der Anforderungen findet höchstens innerhalb kleinerer Inhaltsbausteine statt. Die genannten Schritte resultieren alle aus dem bereits erwähnten Bedarf nach Balance. Stellen Sie sich vor, es gibt eine Gruppe von Webautoren, die sich mit der redaktionellen und gestalterischen Seite ihrer Texte besser auskennen als mit Webtechnologien. Soll nun ein Team aus vier bis sechs Entwicklern deren Ergebnisse aufbereiten, so müssen die Bedürfnisse der ersten Gruppe eine geringere Priorität erhalten als die der zweiten, damit die Entwickler für die Qualitätssicherung und andere Projekte weiter zur Verfügung stehen.
Angewohnheit 3: Konsistenz Idealerweise kann ein Gestalter seine Arbeitsergebnisse mit geringfügigen Änderungen am Markup- und CSS-Code aus einem früheren Projekt übernehmen. Das ist »CSS-Zen« in Aktion (siehe im Abschnitt »Die Funktionsprinzipien des CSS-Zen« auf Seite 60). Um Templates wiederverwenden zu können, muss der Gestalter in solchen Fällen bei deren Erstellung und Verfeinerung möglichst konsistent arbeiten. Das ist in der Praxis schwieriger, als es theoretisch erscheint. Der Mangel an Disziplin und Eingriffe seitens der Manager zwingt die einfachen Entwickler (und die Gestalter unter ihnen) oft, das sprichwörtliche Rad für jedes Projekt neu zu erfinden.
Die vier wichtigsten Angewohnheiten für effektive Stylesheets
|
55
Daher gehört es zur Angewohnheit der Konsistenz, dass ein Gestalter bekannte Umstände erkennt, sich auf sie vorbereitet und engagiert darauf reagiert, wann immer es möglich ist. Konsistenz ergibt sich aus Beobachtung, Vorbereitung und Reflexion.
Konsistenz kann sowohl innerhalb einer Site als auch über mehrere Websites hinweg von Vorteil sein. Die Konsistenz innerhalb einer Site ist einer der wichtigsten Vorteile der Kaskade. Nehmen Sie beispielsweise ein Template für ein dreispaltiges Layout. Die wichtigsten Layoutstile lassen sich mit relativ wenigen Regeln definieren. Haben Sie eine zweispaltige Präsentation, die das gleiche Layout verwenden soll oder ein paar Seiten mit einer anderen Spaltenreihenfolge, werden zusätzliche Stilregeln nötig, wie diese: #hauptteil #haupttext { width: 42em; float: left; } #haupttext #innen { float: right; width: 24em; padding: 0 1.5em 0 1.5em; } #hauptteil #seitenleiste { margin-right: 27em; } #hauptteil #drittrangig { margin-left: 42em; } body.sonderfall #hauptteil #haupttext body.sonderfall #haupttext #innen body.sonderfall #haupttext #seitenleiste body.sonderfall #hauptteil #drittrangig
Die Selektoren in diesem CSS-Quellcodebeispiel sind überladen, um die verwandtschaftlichen Beziehungen der Elemente zu verdeutlichen.
Die oben gezeigten Stilregeln beschreiben mit den ersten vier Regeln ein mögliches dreispaltiges Layout. Die übrigen Regeln entfernen #drittrangig aus dem Textfluss des Dokuments und passen das Layout der verbleibenden Elemente an den Sonderfall an. Gibt es keine Ausnahmen, sind nur die ersten drei Regeln notwendig. Die zusätzlichen Regeln verdeutlichen die Vorteile der Schlichtheit. Verglichen mit der Aussicht, für zwei- und dreispaltige Layouts eigene Templates zu erstellen, wiegt diese Methode sogar noch schwerer. (Der Kompromiss und die suchmaschinenfreundlichste Lösung besteht darin, die optionale Spalte – den .sonderfall – über die include-Anweisung eines Skripts einzubinden, das nur bei Bedarf aufgerufen wird.) Schreibt ein Gestalter die vorigen Stilregeln, geht er davon aus, dass das gleiche Template für zwei- wie für dreispaltige Layouts verwendet wird, was für eine Form der Konsistenz spricht. Eine zusätzliches Template birgt gewisse Risiken – in erster Linie die Notwendigkeit weiterer Tests. Ein weiteres Risiko besteht in einer Verzweigung des Codes, wenn die Templates, aus welchen Gründen auch immer, separat verändert werden. Im Laufe der Zeit werden die Unterschiede immer größer. Schließlich wird der Bedarf an Regeln für die Vereinheitlichung der Gestaltung im Vergleich zur Verwendung eines einzelnen Templates unverhältnismäßig groß.
56
|
Kapitel 5: Effektive Stylesheets und Dokumentenstrukturen
Die in diesem Beispiel erläuterte Konsistenz erstreckt sich aber auch auf das Design. Wie das Beispiel zeigt, sind die Stile für die Umsetzung inkonsister Designs deutlich zahlreicher und umfangreicher. Die Folge sind ungewollte Interaktionen zwischen den Elementen, weitere mögliche Darstellungsfehler und zusätzliche Tests. Der letzte und höchste Ausdruck von Konsistenz ist schließlich die Möglichkeit, den Code wiederzuverwenden. Haben Sie beispielweise eine Bibliothek mit Templates und Stylesheets, die Sie in alltäglichen Layoutsituationen verwenden können, wird der Beginn neuer Layoutprojekte mit der Zeit immer einfacher. Öffnen Sie Ihr Template, verändern Sie die class- und id-Werte nach Bedarf, und passen Sie die CSS-Eigenschaften an die Designvorgaben an. Schon nach kurzer Zeit können Sie sich auf die Typografie, Akzente und andere Feinheiten konzentrieren, anstatt stundenlang ein komplett neues Markup und die nötigen Stile anzulegen Wenn Sie die Struktur Ihres Dokuments und des Templates von vornherein kennen, brauchen Sie sich um die Details nicht mehr zu kümmern. Stattdessen können Sie Ihre ungeteilte Aufmerksamkeit der Benutzerfreundlichkeit widmen. Diese Vorteile erhöhen außerdem die Notwendigkeit, gestalterische Akzente zu nutzen, um dem Benutzer zu zeigen, wo er sich gerade befindet.
Konsistenz durch Template-Verwaltung Die detaillierte Diskussion der Verwendung von Templates in diesem Buch basiert auf der Idee eines »Baugerüsts« (scaffolding), also einer einfachen Markup-Struktur mit maximal vier oder fünf Abschnitten pro Seite. Dieser äußere »Rahmen« enthält alle verwendeten Seiten- oder Abschnitts-Templates. Dadurch kann der für die Präsentation zuständige Gestalter den Kontext jeder Layoutspalte oder anderer Bestandteile der Seite leicht verstehen. Die größte Gefahr bei diesem Ansatz sind die Designer. Sie könnten glauben, dass der Aufwand für die Wartung und Pflege des Codes bei der Verwendung mehrer Templates arithmetisch steigt. Tatsächlich steigt der Aufwand jedoch logarithmisch. Verdoppelt sich der Aufwand bei zwei Templates, liegt er bei der Verwendung eines dritten Templates bereits deutlich höher. Dieser unverhältnismäßige Ressourcenverbrauch entsteht, weil ein Template am besten erstellt wird, um bestimmte (größtenteils oder vollkommen) einmalige Anforderungen zu erfüllen. Das führt zu einmaligen Beziehungen zwischen den Bestandteilen. Das hat wiederum zur Folge, dass jedes neue Template zusätzlich zu den zu erwartenden Herausforderungen bei seinem ersten Einsatz auch neue Fehler und Präsentationsanforderungen mit sich bringt. Außer durch die sparsame Verwendung von class- und id-Werten, lässt sich der wachsende Ressourcenhunger am besten dadurch eindämmen, dass man sich an einen bestimmten Arbeitsablauf hält. Das heißt, jedes neue Template wird erst dann erstellt und getestet, wenn sich alle Verantwortlichen darüber einig sind, dass eine weiteres Template wirklich nötig ist.
Die vier wichtigsten Angewohnheiten für effektive Stylesheets
|
57
Die Alternative wäre, bei jeder Gelegenheit neue Templates zu erstellen. Die bereits beschriebene Streuung und Codeverzweigungen wären unvermeidlich.
Angewohnheit 4: Auf Kurs bleiben Am schwierigsten ist es, sich einen Ortssinn anzugewöhnen. Eine gute Orientierung innerhalb Ihres Codes erwerben Sie vor allem durch die Praxis. Schließlich existieren alle Webdokumente in mehreren Kontexten und Informationsräumen, und Ihr Projektteam kann nur einige davon kontrollieren. Daraus ergibt sich, dass die Orientierungsfähigkeit (siehe im Abschnitt »Navigation: Ortsbestimmung und Orientierungshilfen« auf Seite 64) und eine klare Standortbestimmung für die Benutzerfreundlichkeit absolut notwendig sind. Wenn Sie sich nicht einmal innerhalb Ihres eigenen Arbeitsbereichs zurechtfinden, ist der Versuch fast aussichtslos, Ihren Nutzern diese Fähigkeiten zu vermitteln. Die in diesem Buch gezeigten Konventionen für Seitenstruktur, Markup und Benennung orientieren sich so eng wie möglich an den gängigen Praktiken für große Websites, um die es später in diesem Kapitel geht.
Die Möglichkeit, seinen Standort zu bestimmen, bildet den Anfang und das Ende der Kaskade: Elemente befinden sich innerhalb anderer Elemente, die wiederum in Dokumenten gespeichert sind. Diese sind Teil eines größeren Systems oder eines Universums aus Websites, das sich ständig wandelt. Je genauer Sie bestimmen können, worin Ihre aktuelle Aufgabe innerhalb dieses Kosmos besteht, desto einfacher ist es, qualitativ hochwertigen CSS-Code zu schreiben. Einem erfahrenen Benutzer reichen zur Orientierung im Web ein paar Hinweise auf seinen Standort. Ein erfahrener Webentwickler muss dagegen genau wissen, was er an welcher Stelle tut, um die Ortshinweise zu erstellen, die der Benutzer benötigt.
Nehmen Sie beispielsweise den folgenden Elementebaum: • body *
h1
*
div#hauptteil &
div#hauptinhalt &
div#haupttext &
h2
&
div.abschnitt &
&
div#seitenleiste &
&
|
...
div#drittrangig &
58
...
...
Kapitel 5: Effektive Stylesheets und Dokumentenstrukturen
&
ul#hauptnavigation
&
div#fussteil &
ul#unternavigation
&
p#kolophon
In diesem Baum gibt es mindestens 16 verschiedene Kontexte, auf die Präsentationsregeln angewendet werden können. Hinzu kommen mit ziemlicher Sicherheit Hinweise auf den Kontext des Inhalts, der mithilfe von class- und id-Werten realisiert wird, die für body (und vermutlich auch noch für andere Elemente) definiert werden. Kann ein Gestalter diese Signale deuten, ist es ihm möglich, den Kontext eines beliebigen Elements der Site zu bestimmen – und zwar unabhängig von seinem Platz im Quellcode, der Häufigkeit seines Auftretens oder der Wichtigkeit seines Inhalts. Kann ein beliebiges Element definiert werden, lässt es sich auch mit Stilregeln versehen. Dies ist die Voraussetzung dafür, dass ein Element als Orientierungshilfe für den Besucher dienen kann. (Das soll nicht heißen, dass jedes Element als Orientierungshilfe verwendet werden sollte, obwohl selbst das möglich ist.)
Produktdokumentation als »Kompass« Das ideale Stylesheet dokumentiert eine Site, weil es auf kontextabhängigen Selektoren und sorgfältig gestalteten Elementbäumen basiert. Aber auch kleinste Projekte profitieren von einem gewissen Maß an zusätzlicher Dokumentation. Oft geht es hierbei um das Design, insbesondere die Behandlung von Schrift und die Spezifikation eines Layoutrasters. Es gibt drei Bestandteile, die für eine Dokumentation im Laufe der Zeit nützlich sein können: Beschreibungen der Kaskade Beschreibungen der Kaskade sind typischerweise am einfachsten zu erstellen. Allerdings stellen sie auch die größten Herausforderungen an das Erinnerungsvermögen des Gestalters. Jede ausreichend komplexe Sammlung von Stylesheet-Regeln folgt bestimmten Mustern: Die Beschreibungen der Kaskade beschreiben diese Regelmuster an einem Ort und verweisen auf Teile der Website, in denen sie benutzt werden. Code- und Produktstandards Code- und Produktstandards bauen auf der Beschreibung der Kaskade auf. Dies geschieht, indem sie die Markup-Muster und Arten von Selektoren beschreiben, die üblicherweise für bestimmte Inhalte verwendet werden. Ein Beispiel für Produktstandards ist meine Angewohnheit, das h1-Element (ohne id) nur dafür zu verwenden, die Identität der Site zu definieren, während h2 die erste Überschrift für den Inhalt der Seite enthält. Stylesheet-Richtlinien Stylesheet-Richtlinien bereichern die Dokumentation der Site, indem sie nicht nur in klar verständlicher Sprache erklären, wie Dinge zu tun sind, sondern auch, warum eine Klasse oder ein Inhaltsteil auf eine bestimmte Art strukturiert und gestaltet wurde. Die vier wichtigsten Angewohnheiten für effektive Stylesheets
|
59
Eine effektive externe Dokumentation ist besonders wertvoll, wenn Entwickler eine Site noch nicht kennen. Auf diese Weise können Sie sich ein akkurates »inneres Bild« von der Informationsarchitektur und der Struktur der Templates machen. Alternativ dazu kann man Neulinge natürlich auch gleich in tieferes Wasser werfen. Das zwingt sie dazu, eigene Rückschlüsse zu ziehen, warum eine Site ein bestimmtes Design besitzt. Der größte Wert externer Dokumentation liegt aber vermutlich in ihrer schieren Größe – oder genauer in ihrem Fehlen. Je effektiver Sie die vier in diesem Abschnitt vorgestellten Gewohnheiten praktizieren, desto geringer ist der Bedarf an zusätzlicher Dokumentation.
CSS-Zen und die Erfahrung des Gestalters Eigentlich ist die Bezeichnung »CSS-Zen« nicht ganz korrekt. Der Zen-Buddhismus betont die gegenseitige Abhängigkeit aller Dinge, insbesondere lebender Dinge, in einer Reihe verschiedener Glaubensgrundsätze. Bezogen auf die Webentwicklung, ist der Begriff von einer gebräuchlichen Kurzbezeichnung für die japanischen karesansui-Steingärten abgeleitet, die einem bestimmten ästhetischen Zweck dienen: der Demonstration von begreifbarer Harmonie und Präzision trotz einer sich ständig wandelnden Umgebung und der Unberechenbarkeit der Natur. Der Wert von karesansui für die buddhistische Meditation (in Form von Reflektion und der Pflege des Gartens) führte zu dem Spitznamen »Zen-Garten«, der Dave Shea zu dem Namen für seine außerordentlich beliebte Website (http://www.csszengarden.com/) inspirierte. Der »CSS-Zen-Garten« soll eine wichtige Idee demonstrieren: Ein einziges, sorgfältig erstelltes Markup-Template kann eine praktisch unbegrenzte Anzahl von Designanforderungen befriedigen. Erfüllt ein Template die nötigen Vorraussetzungen, kann das Design ohne Anpassungen am Markup beliebig verändert werden, sofern es keine deutliche Änderungen an der Struktur der Informationen gibt, die im Dokument oder der Site enthalten sind.
Wie karesansui, so orientieren sich Sites, die CSS-Zen praktizieren, an den gegebenen Umständen, insbesondere den Projektzielen. Außerdem bleiben die Markup-Templates solcher Sites weitestmöglich unverändert – so felsenfest wie die karesansui inmitten eines scheinbaren Chaos.
Die Funktionsprinzipien des CSS-Zen Die in den vorigen Abschnitten besprochenen Angewohnheiten und Ideen gelten als gute Tugenden, um die Effizienz und Qualität der Arbeit des Gestalters zu steigern. Das Ideal des CSS-Zen passt dagegen in eine Struktur aus Prinzipien, die eine bestimmte Betrachtungsweise für Webinhalte und ihre Struktur fördern: 1. Information und Präsentation unterscheiden sich so stark, dass man unmöglich sagen kann, dass eines vom anderen abhängt.
60
|
Kapitel 5: Effektive Stylesheets und Dokumentenstrukturen
2. Es ist eine unumstößliche Tatsache, dass der Informationsfluss (und damit auch der Fluss der Webinhalte) nicht von ihrem Ort, sondern von ihren Beziehungen bestimmt wird. 3. Webinhalte können in kleinste Untereinheiten aufgeteilt werden, ohne dass der Durchschnittsbesucher davon etwas merkt. 4. Jeder Kreuzungspunkt zwischen Umgebung und Information einer Site hat seine eigene ideale Struktur. Sobald ein Gestalter diese Prinzipien bei seiner Arbeit bedenkt, ändert sich seine Sichtweise. In Tabelle 5-1 finden Sie einen Vergleich häufiger Ansichten von Gestaltern zu Markup und Stil bei Kenntnis bzw. Unkenntnis der Prinzipien des CSS-Zen. Die Reihenfolge entspricht der gerade vorgestellten Liste. Tabelle 5-1: Vergleich der Ansichten von Gestaltern bei Unkenntnis bzw. Kenntnis der Prinzipien des CSS-Zen Prinzip
Unkenntnis
Kenntnis
Trennung
Quellcode-Reihenfolge und -struktur werden von Präsentationsanforderungen bestimmt.
Quellcode-Reihenfolge und -struktur werden von der Priorität der Elemente und (wo nötig) ihrer Klassifizierung bestimmt.
Beziehungen
Jede beliebige Menge Inhalt ist unteilbar und besitzt Inhalt kann unterteilt werden, in beliebigen Zusameine ideale Flussrichtung. menhängen dargestellt werden, neu gestaltet und mit anderen Inhalten kombiniert werden; zusätzlicher Kontext kann durch Hyperlinks und Metadaten bereitgestellt werden.
Teilbarkeit
Das Markup richtet sich komplett nach der Präsentation und offensichtlichen Inhaltsdefinitionen; Markup ist oft verschachtelt und wird nur selten benutzt, um dem enthaltenen Inhalt zusätzliche Bedeutung zu verleihen.
Markup und Inhalt folgen einer logischen Struktur und können im Dokumentenbaum bei Bedarf bis hin zu einzelnen Silben oder Symbolen neu angeordnet werden.
Veränderlichkeit
Die Dokumentenstruktur hat entweder eine »Einheitsgröße«, die für alle Situationen passen muss, oder sie wird vollkommen willkürlich erstellt.
Inhalt und Aufteilung des Dokumentenbaumes folgen dem Prinzip »Alles hat seinen Platz«. Dies kann kann je nach Projektzielen, Publikum und Themen unterschiedlich angewandt werden.
Die konsequente Anwendung des CSS-Zen führt zu Websites, deren Form auf allen Ebenen der Funktion folgt. Da die Funktion die Besucher bringt, sollte dies doch die bessere Variante sein als umgekehrt, oder?
Informationsarchitektur und Usability des Webs Dieses Buch enthält einige Schlüsselideen zur Webentwicklung: • Hyperlinks sind der Anfang, das Ende und die Mitte des Webs. • Webressourcen sind im Grunde genommen n-dimensional und nicht linear.
Informationsarchitektur und Usability des Webs
|
61
• Die unbegrenzte Anzahl von Möglichkeiten, wie Inhalte verlinkt, unterteilt und kombiniert werden können, zeigt deutlich, wie wichtig effektive Orientierungshilfen für Websites sind. • Jede Website oder -applikation ist eigentlich eine Ressource aus mehreren Schichten, die nach und nach erweitert werden können. • Es gibt mehr als einen Weg, eine Website zu erstellen, weil sich die Anforderungen je nach den Geschäftszielen und Benutzerumgebungen verändern. Die Kunst der Informationsarchitektur (IA) versucht, diese Ideen zu konkretisieren und die dadurch entstehenden Designprobleme zu lösen. Das Hauptziel ist es, Informationen möglichst gut auffindbar und benutzbar zu machen. Was hat man schon von Informationen, die keiner findet? Dieser Abschnitt ist nicht als eingehende Unterweisung, sondern nur als Einführung gedacht. Weiterführende Informationen über die Informationsarchitektur des Webs finden Sie unter den folgenden Ressourcen: • Don’t Make Me Think: Web-Usability – Das intuitive Web, 2. Auflage, von Steve Krug (Mitp). • Information Architecture for the World Wide Web, 3. Auflage, von Peter Morville und Louis Rosenfeld (O’Reilly). • Boxes and Arrows, eine Website für und von Praktikern aus dem Bereich der Web-Benutzererfahrung (UX), zu finden unter www.boxesandarrows.com. • Die American Society for Information Science and Technology, unterstützt Interessengruppen, die sich mit Mensch-Computer-Interaktion (HCI) und Informationsarchitektur befassen. Die Website finden Sie unter www.asis.org.
Ein auf Webinhalte und -schnittstellen spezialisierter Informationsarchitekt muss die zuvor vorgestellten Ideen als Tatsachen annehmen. Die Alternative grenzt schon an Nihilismus. Schließlich wird es ohne jegliche Grundsätze – oder zumindest Annahmen – unmöglich, den Inhalt einer Site effektiv und konsistent zu organisieren und für Menschen präsentabel zu machen. Auf der praktischen Ebene brauchen nur die wenigsten Websites eigene IA-Experten, entweder weil es einfach nicht nötig ist oder weil das Budget nicht ausreicht. Daher sollten gewissenhafte Entwickler zumindest die Grundlagen der IA beherrschen.
Mehrdimensionalität Wie bereits mehrfach gesagt wurde, sind traditionelle Informationsquellen (Druckmedien, Video, Audio) überwiegend linear, das Web aber nicht. Die Dimensionen des Web lassen sich wie folgt beschreiben:
62
|
Kapitel 5: Effektive Stylesheets und Dokumentenstrukturen
Länge Analog zur linearen Natur traditioneller Medien ist mit Länge der offensichtliche Anfang und das Ende des primären Inhalts eines einzelnen Dokuments gemeint. Breite Breite bezeichnet Position eines Webdokuments innerhalb der logischen Menge aller Dokumente, die direkt mit ihm verlinkt sind. Der Begriff Breite ist verwandt mit (aber getrennt von) »Situation«. Um sich diese Dimension des Website-Designs vorzustellen, werden neuerdings gerne Mind-Mapping-Techniken verwendet. Tiefe Mit Tiefe meint man eine beliebige Betrachtungsweise des Inhalts für bestimmte Benutzerumgebungen. Tritt auf, wenn progressive Verbesserungen angewandt werden. Entropie Zeitempfindliche Dokumente oder solche, die ganz oder zum Teil aus benutzergenerierten Inhalten bestehen, können sich im Laufe ihrer Lebensspanne enorm verändern. Situation Die Position und der Kontext eines Dokuments in Bezug auf seine Position im Browserverlauf (History) während einer Benutzersitzung. Die Situation ist getrennt von Breite und Entropie zu betrachten, weil sie von jedem Benutzer selbst bestimmt werden kann. Anwendungsszenario Der Zweck, zu dem Inhalt und Struktur verwendet werden, z.B. ein RSS-Feed, über den Änderungen mitgeteilt werden, im Gegensatz zu HTML für normales Lesen; unterschiedliche Benutzerschnittstellen einer Webapplikation; Zusammenfassungen von Suchmaschinen-Ergebnisseiten (SERP) Granularität Die Art, auf die sich die Wahrnehmung des Inhalts verändert, wenn Teile entfernt, hinzugefügt, ex- oder importiert werden. Auf die gleiche Art, wie die Warhnehmung von Länge, Breite, Tiefe und Entropie eines begreifbaren Objekts unser Verständnis dieses Objekts verändert, ändert sich auch das Verständnis von Webinhalten durch unsere Wahrnehmung der gerade beschriebenen Eigenschaften. Die meisten Leute sind es gewohnt, in zwei Dimensionen zu denken, können normalerweise mit dreien umgehen und sind sich vier Dimensionen bewusst. Informationsarchitekten, Site-Designer und Gestalter müssen entscheiden, wie viele (und welche) der sieben gerade beschriebenen Dimensionen sie verwenden, um Benutzern Hilfen zur Ortsbestimmung und Navigation an die Hand zu geben. Dies war einfach eine grobe Beschreibung von Webinhalten und Dokumentenstruktur, die nicht nur die vier wahrnehmbaren Dimensionen einbezieht, sondern drei weitere. Informationsarchitektur und Usability des Webs
|
63
Verglichen mit den Grenzen traditioneller Medien, ist es kein Wunder, dass einige Mitmenschen durch Webinhalte ein gutes Auskommen haben – selbst wenn ihre Hauptaufgabe allein darin besteht, anderen zu helfen, sich darin zurechtzufinden.
Navigation: Ortsbestimmung und Orientierungshilfen Hinweise zum Erstellen von effektivem Linktext finden Sie im Abschnitt »Effektiver Inhalt für Links und Werte für das ›title‹-Attribut« auf Seite 139.
Betrachtet man die unbegrenzt wandlungsfähige Natur von Webinhalten und ihrer Schnittstellen, wird klar, dass die wertvollste Hilfe für den Besucher in Maßnahmen besteht, durch die er sich bei seinem Aufenthalt auf Ihrer Site zurechtfinden und seinen Weg finden kann. Websites verwenden typischerweise einen oder mehrere der folgenden sechs Strategien, um Benutzer »auf Kurs« zu halten: Primäre und sekundäre Navigation Im Seitenlayout gibt es meist einen oder zwei Bereiche mit Links, die auf für Besucher möglicherweise interessante Dokumente verweisen. Die Links können in zwei oder mehr Hierarchieebenen verschachtelt sein. In allen Fällen lässt sich das gerade angezeigte Dokument nicht nur durch den Seitentitel erkennen, sondern auch dadurch, dass es innerhalb der Linkliste nicht auf sich selbst verweist (self-link). Gut konzipierte Navgationspfade (»Brotkrumen-Navigation«) Wie die verschachtelte Navigation basieren auch diese Links auf einer hierarchischen Struktur der Site. In diesem Fall werden die Links jedoch in der Reihenfolge ihrer zugewiesen Bedeutung angezeigt. Dieser Ansatz ermöglicht zwar keine eindeutige Ortsbestimmung des Dokuments im Informationsraum einer ganzen Site, aber er ist eine hervorragende Ergänzung für gedruckte Seiten. Die »Brotkrumen« zeigen dem Leser gedruckter Inhalte genau, wie sie zur gedruckten Seite gelangen können. Stichwörter (»Tags«) Die Dokumente werden mit bestimmten Stichwörtern (»Tags«, nicht zu verwechseln mit HTML-Tags) versehen. Eine Zusammenfassung dieser Stichwörter wird auf jeder Seite der Website angezeigt. Folgt der Besucher einem dieser Stichwörter, erhält er eine Liste der Dokumente, auf die das gewählte Schlüsselwort passt. Die Dokumente können dann nach verschiedenen Gesichtspunkten sortiert werden (z.B. alphabetisch, nach Datum, Beliebtheit usw.). Sitemaps Der Hauptunterschied zwischen verschachtelter Navigation und einer Sitemap besteht darin, dass bei einer Sitemap Links auf alle Dokumente und Applikationen einer Site auf einer Seite zusammengefasst werden.
64
|
Kapitel 5: Effektive Stylesheets und Dokumentenstrukturen
Eingebettete Links Gewissenhafte Autoren versehen passende Schlüsselwörter und Sätze oft mit Links auf weiterführendes Material oder zumindest auf solches, das sich auf den ersten »Ebenen« der Site befindet. Suchfelder Im Prinzip wie Google, nur wesentlich kleiner. Bei der Bereitstellung lokaler Suchfunktionen sind die gleichen Dinge zu beachten wie bei der Suchmaschinenoptimierung (SEO) der Site. Die Bereiche der Navigation, die auf der Clientseite stattfinden, werden an anderen Stellen in diesem Buch behandelt: in den Abschnitten zur primären und sekundären Navigation in den Teilen, die sich mit Layout und Listen befassen. Wie die kontextbezogene Navigation werden auch Sitemaps in Form von Listen, und gelegentlich auf mehrere Spalten verteilt, dargestellt. Stichwortlisten verwenden ebenfalls das Listen-Markup, wobei die CSS-Eigenschaft display für die einzelnen Einträge oft den Wert inline erhält. Weitere Stile sind möglich, um die Häufigkeit der Stichwörter innerhalb der Site zu verdeutlichen.
Besucherstrategien Über Besucher lassen sich die folgenden allgemeinen Dinge sagen: • Die Ziele des Besuchers lassen sich in eine (oder mehrere) der folgenden Kategorien einordnen: Information, Dienste, Einkauf von Produkten oder Unterhaltung. • Die Besucher kommen auf eine von zwei Arten zum Ziel: durch Stöbern (Browsing) oder durch eine Volltextsuche. Oftmals bevorzugen Besucher die Suchmaschinen von Drittanbietern, weil diese ihnen innerhalb der Suchergebnisse genaue und vergleichbare Informationen bieten. Den meisten Besuchern ist außerdem bewusst, dass insbesondere große soziale Netzwerke mehr als nur eines der oben beschriebenen Ziele befriedigen können. Eine der wichtigsten Design-Entscheidungen besteht darin, ganz bewusst festzulegen, wie das Design und die Implementierung der Benutzerschnittstelle der Site diese gemeinsamen Ziele und Strategien umsetzen. Zwar ist es möglich, sämtliche hier beschriebenen Orientierungshilfen und Mechanismen zur Ortsbestimmung umzusetzen, aber nicht alle sind einfach zu implementieren. Auf jeden Fall müssen Gestalter wissen, an welcher Stelle eines Seitenlayouts diese Hinweise sich normalerweise befinden. So können sie den bestmöglichen Weg finden, die Hinweise zu gestalten, an denen sich die Besucher orientieren: Primäre Navigation Die primäre Navigation ist horizontal angeordnet und folgt, direkt nach dem Kopfteil; Links auf Unterbereiche befinden sich oft eine Zeile unterhalb der »Hauptlinks«.
Informationsarchitektur und Usability des Webs
|
65
Oftmals ist auch das Logo einer Site als Link auf die Startseite definiert. Das Logo befindet sich oft in der linken oberen Ecke des Layouts. Links in der Fußzeile Links innerhalb der Fußzeile werden ebenfalls als Liste definiert. Hierbei erhält die Eigenschaft display oft den Wert inline oder inline-block. Die Links werden oftmals horizontal zentriert und in einer kleineren Schrift als der Haupttext dargestellt. Navigationspfade Diese »Brotkrumen«-Navigation ist so gut wie immer horizontal orientiert und folgt normalerweise direkt auf die primäre Navigation. Bei gedruckten Seiten kann der Navigationspfad die primäre Navigation auch ganz ersetzen. Stichwortlisten In dreispaltigen Layouts erscheinen Stichwortlisten oft rechts vom Hauptinhalt; bei zweispaltigen Layouts unterhalb des sekundären Inhalts. In den seltenen Fällen, in denen ein einspaltiges Layout verwendet wird, erscheinen sie auch unterhalb des primären Inhalts, benötigen bei häufiger Verwendung jedoch eine eigene Spalte. Sitemaps Sitemaps werden üblicherweise aus dem Fußteil jeder Seite verlinkt und auf einer eigenen Seite als Hauptinhalt dargestellt. Suche Suchfelder werden normalerweise in der rechten oberen Ecke des Kopfteils platziert und manchmal am rechten Rand der Fußzeile wiederholt. Ergebnisseiten werden meist einspaltig dargestellt, selbst auf Websites, die Standardinhalte normalerweise mehrspaltig darstellen. Diese Art der Darstellung ist normalerweise der mangelnden Flexibilität in der Ausgabe des verwendeten Erweiterungsmoduls oder der verwendeten Suchmaschine geschuldet.
Richtlinien für die Erstellung benutzbarer Schnittstellen Die Erklärung »X kommt hierhin« ist ein Startpunkt: Indem Sie sich an den üblichen Verfahrensweisen orientieren, können Sie die Erwartungen der Besucher für sich nutzen. Allerdings reicht es meist nicht aus, einfach der Masse zu folgen, um ein gutes Ergebnis zu erzielen. Das erste und wichtigste Ziel ist – wieder einmal – Konsistenz. Stellen Sie sich eine Reihe von Seiten vor, die alle an den Seitenanfang gescrollt sind. Idealerweise findet ein Besucher die nötigen Navigationselemente auf jeder Seite an der gleichen Stelle: die Navigationslinks, die Stichwortlinks, das Suchfeld, den Seitentitel und so weiter. Noch besser (wenn auch wesentlich schwieriger) wäre es, wenn diese Konsistenz möglichst über die gesamte Länge der Seite aufrechterhalten würde. Hierdurch können sich Besucher innerhalb der Seite schnell zurechtfinden, und genauso schnell finden sie die nächstgelegenen Navigationselemente auf der Seite.
66
|
Kapitel 5: Effektive Stylesheets und Dokumentenstrukturen
Für die Erstellung sinnvoller Navigationselemente gibt es Designtechniken, die den Besuchern helfen können, ihre Ziele schneller zu erreichen – zumindest schrittweise. • Navigationslinks und Stichwortlinks sollten verhältnismäßig groß gestaltet werden. Zumindest sollte dieser Bereich mit display: block definiert und mit zusätzlichen Innenabständen versehen werden, wie in Kapitel 8 erklärt wird. Die gleiche Technik kann die Usability von Submit-Buttons bei Suchfeldern erhöhen. • Menüs mit Links auf zusätzliche Ressourcen, die »aufklappen«, wenn der Mauszeiger sich darüber befindet (z.B. beim Ordner »Programme« im Windows-Start-Menü), sollten möglichst vermieden werden. Sie erfordern ein sehr hohes Maß an feinmotorischer Kontrolle. Microsoft kann sich das erlauben, weil sie auch auf Bildschirme mit geringster Auflösung Rücksicht nehmen müssen. Gleichzeitig bietet Windows den Benutzern aber auch die Möglichkeit, das Start-Menü über die Tastatur zu steuern und Links auf Programme direkt auf dem Desktop anzulegen, die deutlich häufiger benutzt werden. Folgen Sie dieser Desktop-Analogie, und gestalten Sie Ihre Links so, dass sie leicht erkennbar sind. • Die Links vieler Sites werden kleiner dargestellt als der Haupttext; bei manchen Sites wird für diese Links sogar der Kontrast herabgesetzt. Stattdessen sollte jede Anstrengung unternommen werden, die Größe und den Konstrast der wichtigen Links zu erhöhen, ohne dabei jedoch den Hauptinhalt der Seite zu »überfahren«. • Versehen Sie alle Dinge mit aussagekräftigen Beschriftungen. Die Alternative ist das, was der Webexperte Vincent Flanders als »Katze-im-Satz-Navigation« bezeichnet: Sie wissen, dass es da irgendetwas gibt, aber nicht, was es ist. Wollen Sie das Risiko eingehen und womöglich an einem unbekannten Ort landen? • Vermeiden Sie zu kleine input type="text"-Felder bei Such- und allen anderen Formularen. Sind die Felder zu klein, sind die Werte nur noch schwer lesbar. Nur wenige Dinge sind frustrierender als die Unfähigkeit, seine eigenen Eingaben zu lesen! Das soll nicht heißen, dass Texteingabefelder prinzipiell riesig sein müssen, aber ihr Inhalt sollte immerhin gut lesbar sein. • Wird die Identität des aktuellen Dokuments in einem Navigationskontext angezeigt, sollte sie deutlich von ihren Nachbarn unterschieden werden. Nach Möglichkeit sollte das a-Element für die aktuelle Seite aus der Navigation entfernt werden, der Inhalt aber erhalten bleiben.
Links auf das aktuelle Element deaktivieren Eine Deaktivierung des Browserverhaltens für Links ist nicht die richtige Methode, um Benutzern vorzugaukeln, dass ein Dokument keine Links auf sich selbst enthält. Stattdessen können Sie eine ordentliche Suchen-und-Ersetzen-Funktion verwenden, um die a-Tags tatsächlich zu entfernen. Offensichtlich können Sie Links in zwei Schritten entfernen: Erstellen Sie auf jeden Fall zuerst eine entsprechende class-Stildefinition, mit der inaktive Links markiert werden. Hierzu gehört auch, dass Sie die Eigenschaft cursor für den Link
Informationsarchitektur und Usability des Webs
|
67
in einen passenden Wert ändern, wie in Kapitel 8 und auf der Website zu diesem Buch (http://www.htmlcssgoodparts.net) beschrieben wird. Im folgenden Beispiel hat class den Wert selbstLink. Sofern Sie an einem Dokument arbeiten, das mit dem MIME-Typ text/html an den Browser übergeben wird, rufen Sie beim Laden der Seite über den Handler onLoad folgendes JavaScript auf: for (var i = 0; i < document.getElementsByTagName("a").length; i++) { if (document.getElementsByTagName("a")[i].href) { if (document.getElementsByTagName("a")[i].href == document.location.href) { document.getElementsByTagName("a").className = "selbstLink"; document.getElementsByTagName("a")[i].onclick = return false; } } }
Die gleiche Methode zur Zuweisung von class-Werten wird auch bevorzugt, um Benutzer von Eingabefehlern in Formularen zu unterrichten. Aus Sicherheitsgründen kann die Anzeige der Ziel-URIs in der Statusleiste aktueller Browser nicht deaktiviert werden. Daher ist es keine gute Idee, die Benutzerführung nur durch eine Verhaltensänderung der Links ändern zu wollen.
Szenarios und Benutzertests zur Vorhersage von Besucherverhalten Die allgemeine Navigation einer Website gibt die Richtung vor. Was ist aber mit der Standortbestimmung? Typischerweise werden hierfür nur recht einfache Mittel verwendet: • gut sichtbare Seiten- oder Artikelüberschriften • Hervorhebungen in den Navigationselementen, hoffentlich in Kombination mit einem deaktivierten Link • farblich unterschiedliche Hintergründe und Seitenakzente • eindeutige Stile für besuchte Links Wie Sie vielleicht merken, ist die gegenwärtige Praxis kaum geeignet, um Besuchern mitzuteilen, wo innerhalb einer Site sie sich gerade befinden. In der Praxis gibt die Benutzerführung zumindest einen Hinweis darauf, welchen Kontext die aktuelle Seite hat oder ob sich der Besucher seinem Ziel nähert oder sich davon entfernt. Die mangelnde Präzision hat viel mit den fehlenden Grenzen im Web zu tun. Erfahrene Benutzer haben daher nur geringe Erwartungen an die Benutzerführung einer Site. Überlegen Sie, wie ein Orientierungslauf in der wahren Welt funktioniert. Jemand mit einer Karte von entsprechend großem Maßstab und mit guter Sicht, der nötigen Kenntnis seiner unmittelbaren Umgebung, der Fähigkeit, Karten zu lesen, und einem guten Orientierungssinn kann seinen Standpunkt auf wenige Meter genau bestimmen.
68
|
Kapitel 5: Effektive Stylesheets und Dokumentenstrukturen
Das heißt: Um seinen Standort bestimmen zu können, muss man die Beschaffenheit des Geländes kennen und ausreichende detaillierte Grundinformationen besitzen. Dies sind Vorraussetzungen, die für das Überleben in Extremsituationen unbedingt nötig sind. Auf den in diesem Buch besprochenen Websites geht es glücklicherweise nicht ums Überleben, und man kann von seinen Besuchern auch nicht erwarten, die Beschaffenheit des virtuellen Geländes zu kennen. Das heißt, Designer und Gestalter müssen die gleiche Methode anwenden wie Rettungskräfte bei der Suche nach Unglücksopfern: ein eigenes Suchmuster. Im Web werden Aufgaben wie »Suchen« und »Finden« durch Tests des Benutzerverhaltens erledigt. Dies geschieht meist mithilfe von Szenarios oder ausgewachsenen Benutzertests. Bei Szenarios übernehmen die Teammitglieder die Rollen typischer Benutzer und simulieren ihre möglichen Entscheidungen, um bestimmte Rückschlüsse daraus ziehen zu können. Bei Benutzertests müssen »echte« Benutzer mit funktionierenden Prototypen der Website umgehen. Dies ergibt genauere Ergebnisse, erfordert vor der Durchführung des Tests aber auch wesentlich höhere Designanstrengungen. Sowohl Szenarios wie auch Benutzertests verbessern die Effektivität einer eindeutigen Sytematik (Taxonomie) für Ihre Site. Mit einer sinnvollen Systematik hat der Besucher schon nach wenigen Seitenaufrufen ein »inneres Bild« der Struktur Ihrer Website vor Augen.
Taxonomie und Nomenklatur Die Taxonomie ist die Erstellung sogenannter Taxa (strenger und hierarchischer Klassifizierungsmethoden). Als Erstes wurden Taxa von dem schwedischen Naturforscher Carl von Linné verwendet. Er entwickelte ein System zur Einordnung verschiedener Lebewesen, das heutzutage sieben verschiedene Ebenen besitzt. In Tabelle 5-2 sehen Sie diese Ebenen auf menschliche Lebensformen angewendet. Tabelle 5-2: Ein Beispiel für die Taxonomie in der biologischen Klassifizierung Ebene
Nomenklatur
Umgangssprachlich
Reich
Animalia
Tiere
Abteilung
Chordata
Wirbeltiere
Klasse
Mammalia
Säugetiere
Ordnung
Primates
»erster Ordnung«
Familie
Hominidae
»menschenähnliche«
Gattung
Homo
Mensch
Art
sapiens
»wissend«
Informationsarchitektur und Usability des Webs
|
69
Taxa lassen sich auch auf allgemeine Informationen und auf Sammlungen von Fachbegriffen anwenden. Viele Bewohner der Vereinigten Staaten kennen die »Library of Congress Classification« und das »North American Industry Classification System« – beides weithin akzeptierte System zur Organisation von Informationen in einem kompakten hierarchischen System. Nomenklatur lässt sich am einfachsten als »Sammlung von Fachbegriffen« beschreiben. Diese Fachbegriffe dienen einer Gruppe von Benutzern als gemeinsames Vokabular. Man kann sagen, dass die Taxonomie die Nomenklatur organisiert. Allerdings organisiert die Taxonomie auch »unkontrollierte« Vokabulare. (»Kontrolliertes Vokabular« ist ein Synonym für »Nomenklatur« und wird oft von professionellen Informationswissenschaftlern verwendet.) Nehmen Sie beispielsweise die folgenden Begriffe: • Inhalt • Seitenleiste • Titelbild • Schrift • Spacer (Abstandhalter) • Client (Benutzerprogramm) Sie können davon ausgehen, dass die meisten Webentwickler Sie ohne Probleme verstehen, wenn Sie diese Begriffe verwenden. Bei effektiver Verwendung können Taxonomie und Nomenklatur (wenn auch in geringerem Maße) Ihnen die Begriffe zur Verfügung stellen, um einen angemessenen Kontext für Ihre Kaskade zu schaffen. Dies gilt besonders in Bezug auf Flexibilität.
Taxonomie auf die Kaskade anwenden Taxa lassen sich auf zwei verschiedenen Ebenen in Websites integrieren: bezogen auf den Inhalt einer Site und in Bezug auf die Struktur ihrer Markup-Templates. Die Verwendung von Taxa für den Inhalt der Website hat mit den gerade besprochenen Szenarios und Benutzertests zu tun: Anhand von Tests können Sie feststellen, wie eine Site benutzt wird, und damit, wie wichtig die enthaltenen Informationen sind. Stellen Sie sich eine kleine bis mittelgroße Einzelhandelsfirma vor. Ihre Website dient sehr wahrscheinlich den folgenden Zwecken: • Herausfinden der Geschäftsadresse und der Öffnungszeiten • Ermitteln von Telefonnummern und anderen Möglichkeiten, Kontakt zu Mitarbeitern aufzunehmen • Finden von Sonderangeboten und Ausverkäufen • Überprüfen der Verfügbarkeit und Preise für bestimmte Artikel oder Artikelgruppen
70
|
Kapitel 5: Effektive Stylesheets und Dokumentenstrukturen
Wenn ich eine Website für einen Einzelhändler erstelle, empfehle ich folglich die folgenden Kategorien: • Standort(e) • Kontakt • Sonderangebote und Aktionen • Online einkaufen Auf der Startseite versuche ich dann, Informationen aus allen gerade genannten Kategorien zu präsentieren. Hierfür verwende ich folgende Inhalte: • die Straßenadresse und Öffnungszeiten des Geschäfts • die Haupttelefonnummer, die E-Mail-Adresse des Kundendienstes und Kontaktmöglichkeiten über soziale Netzwerke • das wichtigste Sonderangebot und die Gültigkeitsdauer des Angebots • kurze Produktbeschreibungen und »Zum Warenkorb hinzufügen«-Links für die drei bis vier beliebtesten im E-Commerce-Bereich der Site verkauften Artikel Ist das Warenangebot besonders groß, bekommt die sekundäre Navigation ggf. auch Links auf die einzelnen Produktkategorien. Die Seiten der Website befassen sich mit einer der vier genannten Informationskategorien, wobei sie schrittweise immer detaillierter werden. So enthält das Linkziel für »Online einkaufen« beispielsweise eine vollständige Liste der Produktkategorien, während das Linkziel für »Kontakt« eine ausreichend detaillierte Liste der wichtigsten Telefonnummern und anderen Kontaktmöglichkeiten enthält. Jeder Abschnitt dieser Site – und aller anderen gut konzipierten Sites – enthält Hinweise zur Ortsbestimmung. Hieraus ergeben sich die entsprechenden Werte für class und id, die in der Regel für body (oder ein anderes hierarchisch in dessen Nähe befindliches Element) definiert werden, wie hier:
Andere body-Elemente, die die Klasse produkte verwenden, könnten id-Werte wie leer_details, dangast_details etc. definieren. Hierbei handelt es sich um Orte im WeserEms-Gebiet in Norddeutschland. Unterhält der Händler weitere Geschäfte, beispielsweise in einzelnen Stadtteilen, so könnten hier weitere Zwischenebenen verwendet werden. Durch die hier gezeigte Verwendung von class und id für einzelne Seiten können Sie Ihre Selektoren sehr präzise formulieren, was die Erstellung spezieller Akzente z.B. für einzelne Überschriften sehr erleichtert. Zum Beispiel: #dangast_details h2 { background-image: url(/images/dangast_ueberschrift.gif); }
Oder stellen Sie sich vor, was man durch die Methode mit dem Navigationslayout anstellen kann, weil sich die Anzahl der Einträge für Unterebenen sehr wahrscheinlich unterscheidet:
Informationsarchitektur und Usability des Webs
|
71
/* #nav_onlineshop entha ¨lt zwei Zeilen mit Links, #nav_filialen nur eine */ .stores #nav #nav_filialen { height: 1.5em; padding-bottom: 1.5em; } /* nicht beno¨tigte Unterebenen VERSTECKEN */ .filialen #nav #nav_kontakt, .filialen #nav #nav_sonderangebote, .filialen #nav #nav_onlineshop { display: none; }
Das vorige Beispiel ist auch deshalb interessant, weil es zeigt, wie die Elemente in der Seite verschachtelt sind: ...
Unsere Filialen
Oldenburg
Dangast
...
...
Es gibt genügend Gründe, die inhaltliche Struktur Ihrer Site in die Kaskade einzubeziehen. Auf Seitenebene sind Taxonomie und Nomenklatur etwas subjektiver: Ihre #seitenleiste heißt woanders möglicherweise #randbereich. Solange Sie bei der Benennung Ihrer Elemente konsistent bleiben, kann eine Website durchaus ihre eigenen Taxa und ihre eigene Nomenklatur für Funktionen, Beziehungen und typische Verschachtelungsebenen verwenden. Meine eigene Methode zur Definition einer Dokumentenstruktur finden Sie überall in diesem Buch, wobei unterschiedliche Projekte andere Anforderungen besitzen können, auf die entsprechend eingegangen werden muss.
Die nötige Feinheit auch auf größeren Sites erreichen Besonders bei großen Websites oder solchen, die von größeren Frmen betrieben werden, ist es (aufgrund strengerer Richtlinien) oft nicht möglich, ids im hier gezeigten Umfang zu verwenden. In vielen Fällen könnten ids durch class-Definitionen ersetzt werden. In anderen Situationen haben Gestalter diese Möglichkeit nicht. Diese Beschränkungen haben oft weniger komplexe Designs zur Folge. Müssen Sie trotz der Beschränkungen ein bestimmtes Design umsetzen, können Sie die Stile möglicherweise mithilfe eines JavaScript-Frameworks wie jQuery trotzdem definieren.
72
|
Kapitel 5: Effektive Stylesheets und Dokumentenstrukturen
Neue Strukturelemente (HTML 5) Neben dem nav-Element, das in Kapitel 7 besprochen wird, gibt es Vorschläge für eine Reihe weiterer Strukturelemente in HTML 5: • section • article • header • footer • aside • figure Während dieses Buch geschrieben wurde, besaßen die aktuellen Browser noch keine native Unterstützung für diese Elemente. Allerdings ist es nicht besonders schwer, die Unterstützung umzusetzen, da für diese Elemente keine speziellen Darstellungs- oder Verarbeitungsanweisungen nötig sind. Aus diesem Grund werden diese Elemente auch nur wenig Einfluss auf die Endbenutzer haben. Ihr primärer Nutzen besteht darin, Entwicklern leichteren Zugriff auf häufig verwendete Teile einer typischen Seite zu geben. Es ist im Moment auch noch nicht klar, welche dieser vorgeschlagenen Strukturelemente nach dem Durchlaufen des Standardisierungsprozesses ihren Weg in die endgültige HTML 5-Spezifikation finden. So ist man sich allgemein einig darüber, dass das Element section eine sinnvolle Erweiterung der Sprache ist. Deutlich weniger Einigkeit herrscht jedoch über die Elemente article und aside. Über die Elemente header und footer ist man sich ebenfalls einigermaßen einig, jedoch nicht über ihre Verwendung innerhalb von section-Elementen. Der aktuelle Entwurf der HTML 5-Spezifikation erlaubt header und footer als Kindelemente von section, allerdings sind Seitenabschnitte mit eigenen Kopfund Fußteilen im Moment noch nicht sehr verbreitet.
Informationsarchitektur und Usability des Webs
|
73
KAPITEL 6
Lösungen für das CSS-Layout-Puzzle
Wenn Sie Seitenlayouts mit CSS erstellen, besteht die größte Herausforderung darin, die einzelnen Layout-Bestandteile genau an der richtigen Stelle zu platzieren. Hierfür gibt es in CSS drei Grundwerkzeuge: Positionierung, float und width/margin. Allerdings müssen Sie, um diese Werkzeuge verwenden zu können, die zugrunde liegenden Konzepte verstanden haben – und das kann recht schwierig sein.
Das CSS-Boxmodell und die Größe von Elementen Stellt der Browser Blockelemente wie div oder p dar, besteht jedes Element, wie in Abbildung 6-1 gezeigt, aus vier Grundbausteinen (von innen nach außen): Inhalt, Innenabstände, Rahmen und Außenabstände. In aktuellen Implementierungen des CSS-Boxmodells werden die Ausmaße der Box berechnet, indem die Maße dreier der vier Bestandteile addiert werden: die Werte für Breite (width) bzw. Höhe (height) des Inhalts, die Werte für den Innenabstand (padding) sowie die Dicke eines möglichen Rahmens (border). Außenabstände spielen hier ebenfalls eine Rolle. Dabei spielen jedoch auch die Außenabstände benachbarter Elemente eine Rolle. Deshalb gehen wir darauf etwas später ein. margin border padding Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nunc vitae volutpat metus. Suspendisse eu pharetra est. Suspendisse non lectus elit, faucibus aliquet nibh. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Donec erat velit, elementum at suscipit a, aliquet nec ante. Maecenas cursus lobortis massa, interdume erat.
Abbildung 6-1: Die berechnete Breite und Höhe eines Elements basiert auf vier Bestandteilen: Inhalt, Innenabstände (padding), Rahmen (border) und Außenabstände (margin)
|
75
Zu dieser Definition des Layoutverhaltens von Browsern gibt es zwei Ausnahmen: Zurücksetzen des Darstellungsmodus und die Verwendung von auto-Werten für Inhaltsboxen.
Quirks Mode und Strict Mode Webbrowser verwenden typischerweise einen von zwei Darstellungsmodi: den Quirks Mode (»Mackenmodus«) und den Strict Mode (strikter Modus). Welcher von beiden aktiviert wird, hängt davon ab, welche DOCTYPE-Deklaration verwendet wird (oder auch nicht). Eine allgemeine Beschreibung finden Sie in Kapitel 2 und auf der Website zu diesem Buch (http://www.htmlcssgoodparts.net). Anders als im strikten Modus und in der Definition des CSS 2.1-Boxmodells wird die Größe einer Box im Quirks Mode nicht additiv berechnet. Stattdessen werden die für width und height angegebenen Werte verwendet, um die Ausmaße der Box zu ermitteln. Die Werte der übrigen Bestandteile der Box werden von diesen Werten subtrahiert. In CSS 3 lässt sich dieses Verhalten mit der Eigenschaft box-sizing genauer steuern. Mögliche Werte sind content-box (additive Methode) und border-box (substraktive Methode). Die Internet Explorer-Versionen vor IE6 arbeiten ausschließlich im Quirks Mode.
auto-Werte Der Standardwert für die CSS-Eigenschaften width und height ist auto. Wird dieser Wert (implizit oder explit) angegeben, berechnet der Browser den tatsächlichen Wert für width eines Elements entsprechend der Breite des umgebenden Elements. Hat height den Wert auto, so wird die Höhe des Elements basierend auf der Höhe seines Inhalts berechnet. Das geschieht allerdings nur, wenn der Wert der Eigenschaft float für das Element den Wert none (Standardwert) hat. Wurden für ein Element mit der Definition width: auto Rahmen oder Innenabstände definiert, werden deren Werte vom berechneten width-Wert für den Inhalt des Elements subtrahiert. Das Gleiche gilt für eventuelle margin-Werte, die nicht mit den margin-Werten anderer Elemente zusammengefasst werden. Weisen Sie der Eigenschaft width für den Inhalt eines Blockelements dagegen einen ausdrücklichen Wert zu (z.B. 300px) und geben Sie dem linken und rechten Außenabstand den Wert auto (margin-left: auto; margin-right: auto;), so wird das Element innerhalb des umgebenden Elements horizontal zentriert, wie in Abbildung 6-2 gezeigt.
76
|
Kapitel 6: Lösungen für das CSS-Layout-Puzzle
432px
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nunc vitae volutpat metus. Suspendisse eu pharetra est Suspendisse non lectus elit, faucibus aliquet nibh. Class aptent taciti sociosqu ad litora torquent per conubia nostra, velevet per inceptos himenaeos. Donec erat velit, elementum at suscipit roof a, meep aliquet nec ante. Maecenas cursus lobortis massa, interdume erat. p { width: 424px; border: 4px solid black; margin: auto }
720px
Abbildung 6-2: Durch die automatische Berechnung der Außenabstände kann ein Blockelement zentriert werden. In diesem Abschnitt sprechen wir gelegentlich von »berechneten Werten« für width und height. Dies sind die tatsächlichen Ausmaße des Elements nach dem Rendern der Seite im Browser. Weitere Informationen hierzu finden Sie auch in Kapitel 14.
Die Eigenschaft »overflow« Ist ein Element schmaler als der umgebende Block, kann es, unabhängig von seiner angegebenen oder berechneten Breite, horizontal zentriert werden. Eine entsprechende vertikale Zentrierung ist dagegen nicht möglich. Die tatsächliche Höhe des Elements und des ihn umgebenden Blocks müssen bekannt sein, bevor eine vertikale Zentrierung per CSS möglich ist, und auch dann ist sie nur explizit möglich. Die Definition height: auto (als angegebener oder berechneter Wert) weist den Browser an, die Höhe der Box an die Höhe ihres Inhalts anzupassen, aber nicht weiter. Da es so gut wie unmöglich ist, die tatsächliche Höhe von Text zu bestimmen, ist eine Erweiterung der Fähigkeiten von margin: auto für die y-Achse nicht sehr sinnvoll. Auch wenn eine vertikale Zentrierung von Inhalten nicht sehr einfach ist, gibt es immerhin eine Möglichkeit, ein Element so weit auszudehnen, dass es die gesamte Höhe seines umgebenden Blocks ausfüllt. Hier verwendet man die Eigenschaft overflow.
auto-Werte
|
77
Abbildung 6-3: Für die Eigenschaft »overflow« gibt es vier mögliche Werte.
Mit der Eigenschaft overflow kann festgelegt werden, wie Inhalte dargestellt werden sollen, die größer sind als ihr umgebendes Element. Tatsächlich ist overflow die erste hier erwähnte Eigenschaft, bei der sich Blockelemente überschneiden können. So können Gestalter sich über die im Abschnitt »Darstellungsrollen« auf Seite 85 beschriebenen Regeln für Blockelemente hinwegsetzen. Die vier in Abbildung 6-3 gezeigten Werte für overflow lauten: visible (Standardwert)
Sämtlicher Inhalt wird – unabhängig von der Größe des Elements – dargestellt. Haben die Maßangaben des Elements und seines Inhalts einen anderen Wert als auto, läuft der Inhalt über die Grenzen des Elements hinaus und überschneidet sich
78
|
Kapitel 6: Lösungen für das CSS-Layout-Puzzle
möglicherweise mit dem Inhalt angrenzender Elemente. Dabei wird weder die Größe des enthaltenden Elements noch der Fluss der angrenzenden Elemente verändert. hidden
Ist das Element zu klein, um den gesamten Inhalt darzustellen, werden die »überlaufenden« Teile des Inhalts abgeschnitten; das Element behält seine Größe. scroll
Das Element erhält vertikale und horizontale Scrollbalken. Die Kontrollelemente (Schieber, Rollpfeile etc.) werden bei Bedarf eingeblendet. Das Element behält die angegebene Größe. auto (oftmals der Browser-Standardwert für html oder body)
Die angegebene Größe des Elements wird beibehalten. Das Element wird nur bei Bedarf mit horizontalen bzw. vertikalen Scrollbalken versehen. Die Scrollbalken vergrößern den Inhaltsbereich nicht, sondern werden innerhalb der angegebenen Dimensionen angezeigt. Der letzte Wert besitzt eine etwas versteckte, aber möglicherweise hilfreiche Fähigkeit: Wurde für ein Element mit dem overflow-Wert auto ein kleiner Prozentwert für die Eigenschaft height festgelegt (z.B. height: 1%;), so dehnt sich das Element, inklusive eventueller Außenabstände, bis zur berechneten Höhe des Inhalts aus. Dieses Verhalten funktioniert allerdings nur mit height, nicht mit width. Außerdem muss height für das umgebende Element (z.B. body oder div) als Prozentwert definiert werden oder den Standardwert auto haben. Seltener haben die Werte für overflow auch Auswirkungen auf die Breite von Blockelementen, weil der berechnete Wert für height: auto nur selten vorhersehbar ist. In manchen Fällen sind die Auswirkungen von overflow jedoch auch hier zu sehen, zum Beispiel: • bei unverhältnismäßig langen Textteilen, die von nicht-umbrechenden Leerzeichen ( ), einem umgebenden pre-Element oder einem entsprechenden Wert für die Eigenschaft white-space zusammengehalten werden • beim Einbinden ersetzter Elemente (siehe Kapitel 11), besonders von Bildern • beim unerwarteten Einfügen eines Kindelements, dessen berechneter oder tatsächlicher Wert für width größer ist als der des umgebenden Elements. Dieses Szenario kann besonders bei komplexen Webapplikationen oder schlecht geschriebenem CSS-Code öfter vorkommen, als man denkt.
Länge und Breite für Elemente anstelle expliziter Werte nur begrenzen Gelegentlich soll ein Element den gesamten verfügbaren Platz ausfüllen, aber nur bis zu einer bestimmten Obergrenze. In anderen Fällen soll eine bestimmte Höhe oder Breite verwendet werden, der gewünschte Inhalt soll aber auf jeden Fall darin Platz finden. Zum Beisepiel: .container_fuer_artikel { width: 80%; max-width: 50em; margin: auto; } .objekt_in_seitenleiste { float: right; width: 16.667%; min-width: 288px; }
auto-Werte
|
79
Die erste Regel gilt für ein Szenario, in dem links und rechts vom Element noch Platz bleiben soll. Gleichzeitig soll das Element nicht zu breit werden, damit der Inhalt leicht lesbar bleibt (siehe Kapitel 12). In der zweiten Regel wird ein Sechstel der Breite des umgebenden Elements reserviert. Hier kann auch ein Bild enthalten sein, das gemäß der hauseigenen Stilvorgaben bearbeitet wurde. Daher muss hier immer auch eine Minimalgröße angegeben werden, damit das Bild ganz dargestellt werden kann. Beachten Sie, dass in beiden Beispielen die beschränkende Eigenschaft (max-width bzw. min-width) nach der allgemeinen Regel definiert wurde. Schließlich besteht die Beziehung zwischen Quellcode-Reihenfolge und Priorität nicht nur im Dokument selbst, sondern auch innerhalb der Regeln.
Mit Unwägbarkeiten umgehen Normalerweise wird ein Gestalter die Eigenschaft overflow in mehrspaltigen Designs einsetzen, bei denen der Container für eine Spalte (im Abschnitt »Mehrspaltige Layouts implementieren« auf Seite 91) Eigenschaften einsetzt, die zur Steuerung der Darstellung von Hintergründen oder der Box dienen (im Abschnitt »Rahmen, Innen- und Außenabstände« auf Seite 81). Es gibt jedoch eine Reihe von Situationen, in denen die genaue Größe des Inhalts nicht vorhergesagt werden kann. Hier kann die Eigenschaft overflow nützlich sein. Verhindern von Pannen bei statischen Layouts Hat ein Layout eine feste Größe (i.d.R. durch Pixelwerte definiert, wie im Abschnitt »Medienübergreifende Längen- und Maßeinheiten« auf Seite 34 beschrieben), kann es zu Problemen kommen, wenn der Benutzer die Schriftgröße verändert. Zwar kommt das nicht sehr häufig vor, weil nur wenige Nutzer diese Option kennen und inzwischen die meisten Browser über eine Zoom-Funktion verfügen. Bei Problemen kann ein erfahrener Gestalter die Situation aber trotzdem schnell in den Griff bekommen. Am besten verwendet man dann ein Raster aus Hilfslinien für das Layout und keine absoluten Längen- und Höhenangaben. Ist das nicht möglich, kann die Regel overflow: hidden hier sehr hilfreich sein. Stark einengende Layouts von Content-Management-Systemen (CMS) mit zu freizügigen Inhaltsbegrenzungen Angenommen, Sie haben ein Objekt mit impliziten Größenbeschränkungen, beispielsweise einen Werbetext oder ein Feld in einer Seitenleiste. Der Inhalt benötigt mehr Platz, als im ursprünglichen Design vorgesehen war. Für diese Elemente kann die Verwendung von overflow: hidden dabei helfen, eine Missachtung der Inhaltsrichtlinien der Site zu vermeiden. (Diese Situationen sind normalerweise das Ergebnis mangelnder Disziplin beim Designprozess.) Layouts von Formularen vereinheitlichen Bei der Anordnung von Formularelementen und ihren Beschriftungen kann es leicht passieren, dass die Definitionen für das umgebende Element von den enthaltenen
80
|
Kapitel 6: Lösungen für das CSS-Layout-Puzzle
Kindelementen »überfahren« werden. Durch die weiter oben beschriebene auto/ 1%-Methode sorgen Sie dafür, dass die Formulare einer Site dem Hilfslinienraster der Site folgen. Den Platzbedarf von Ajax-basierten Applikationsschnittstellen beschränken Wenn Benutzer in einer Webapplikation Lese- und Aktualisierungsfunktionen durchführen, kann es passieren, dass die nutzergenerierten Daten (besonders Bilder) wim wahrsten Sinne des Wortes »den Rahmen sprengen«. In diesen Fällen kann die Definition von overflow: auto verhindern helfen, dass zu große Inhalte das Design durcheinanderbringen. Aktuelle Browser besitzen außerdem Unterstützung für die Eigenschaften overflow-x und overflow-y, die in CSS 3 spezifiziert werden. Diese ändern das Darstellungsverhalten nur für die genannte Achse. Die Definition unterschiedlicher Werte für overflow-x und overflow-y bringt aber nicht unbedingt die erwarteten Ergebnisse. Ein Testszenario für diese Eigenschaften finden Sie auf der Website zu diesem Buch. Die bei der Verwendung von scroll oder auto erzeugten Scrollbalken gehören übrigens zum Inhaltsbereich des Elements. Dieser wird also nicht vergrößert. Das kann zur Folge haben, dass zwei Scrollbalken dargestellt werden, wo eigentlich nur einer vorgesehen war.
Rahmen, Innen- und Außenabstände Die Entwürfe für Webapplikationen können sehr detailliert sein. Oft ist vertraglich eine pixelgenaue Reproduktion der geplanten Layouts festgelegt, oder zumindest eine pixelgenaue Konsistenz. Die Größenkontrolle von Elementen ist nur ein Teil der Lösung. Die Kontrolle von Leerraum und Rahmen (border) ist mindestens genauso wichtig. Bei der Benutzung der hierfür nötigen CSS-Eigenschaften gibt es einige Dinge zu beachten.
Negative Außenabstände Abgesehen von den Eigenschaftswerten, mit denen die Positionierung von Elementen gesteuert wird, können als einzige die Außenabstände (margin) auch negative Werte haben. Wird einem Element ein negativer Außenabstand zugewiesen, überschneidet sich dessen berechnete Box möglicherweise mit der eines benachbarten Elements. Wie der Name schon sagt, verringern negative Außenabstände den Leerraum in einem Layout, anstatt ihn zu vergrößern. Das ist wichtiger, als es auf den ersten Blick erscheint. Nehmen Sie beispielsweise eine Überschrift, der etwas Leerraum und eine horizontale Trennlinie folgt. Sollen neben der Überschrift zusätzliche Metadaten (z.B. ein Erstellungsdatum oder der Name des Autors in einem Blog) angezeigt werden, folgen die Metadaten im Markup vermutlich unmittelbar auf die Überschrift. Danach kommt meist der eigentliche Artikel, wie in Abbildung 6-4 gezeigt.
Rahmen, Innen- und Außenabstände
|
81
Abbildung 6-4: Eine Kombination aus Überschrift und Metadaten unter Verwendung negativer Außenabstände
Das geringste Markup benötigen Sie, wenn Sie für die Überschrift einen negativen Wert für margin-bottom oder einen negativen margin-top-Wert für die Metadaten festlegen. Auf diese Weise ist sichergestellt, dass die Metadaten unterhalb der Überschrift, aber oberhalb der Trennlinie erscheinen. Noch häufiger ist die Verwendung negativer Außenabstände bei den Fußteilen einer Site. Soll der Fußteil im Hauptteil eines zweispaltigen Layouts zentriert erscheinen und nicht als Teil des ganzen Darstellungsbereichs, so muss seine Definition am Ende des Dokument-Containers platziert werden. Um dies zu erreichen, muss für die Seitenleiste ein negativer Wert für margin-bottom definiert werden, damit die scheinbare Unterkante der Seitenleiste bündig mit der Oberkante der Fußzeile abschließt. Der Nutzen dieser Technik scheint begrenzt. Um die besten Ergebnisse aus der Kombination von Quellcode-Reihenfolge und dem Vertrauen auf das Gesamtkonzept zu erzielen, werden Sie negative Außenabstände vermutlich häufiger benutzen, als Sie sich jetzt denken.
Zusammengefasste Außenabstände HTML-Elemente besitzen standardmäßige Darstellungsrollen. So sind z.B. div, p und die verschiedenen Überschriften (h1, h2 usw.) sogenannte Blockelemente.
82
|
Kapitel 6: Lösungen für das CSS-Layout-Puzzle
Stehen zwei Blockelemente vom gleichen Typ (div, p, etc.) direkt übereinander, werden ihre einander zugewandten vertikalen Außenabstände zusammengefasst. Dieses Verhalten ist bei Absätzen (p) am deutlichsten sichtbar, wie das folgende Beispiel zeigt: p p:first-child p:last-child p + p
Die letze Regel soll das Beispiel nur untermauern. In der Praxis erkennt der Browser zwei aufeinanderfolgende Absätze als Blockelemente vom gleichen Typ und fast ihre Außenabstände standardmäßig zusammen. Bei den hier gezeigten, aufeinanderfolgenden Absätzen beträgt der berechnete Außenabstand 1,25 em-Einheiten (d.h. die übliche Höhe einer Zeile im Haupttext). Ohne die Zusammenfassung betrüge der Abstand nun 2,5 em-Einheiten. Das würde die Leser vermutlich verwirren und die Lesbarkeit des Textes verringern. Werden für den oberen und den unteren Außenabstand verschiedene Werte definiert, z.B. margin-top: 1.25em; und margin-bottom: 2em;, so wird der größere der beiden Werte verwendet. Der zusammengefasste Außenabstand beider Absätze wäre nun 2 em-Einheiten groß. Das umgekehrte Verhalten kann man testen, indem man verschiedene Blockelemente aufeinander folgen lässt, z.B. p – div – p. In diesem Fall bleiben die definierten oberen und unteren Außenabstände der Absätze erhalten, selbst wenn man die Elemente vertauscht und obwohl div-Elemente standardmäßig keinen Außenabstand besitzen. Die in der HTML 4-Spezifikation empfohlenen Darstellungsrollen finden Sie in den Referenztabellen auf der Website zu diesem Buch.
Rahmen Für die Beschreibung von Rahmen gibt es eine außergewöhnlich große Zahl an Eigenschaften (insgesamt 20). Rahmen lassen sich nur selten vermeiden und haben natürlich ihre eigenen Macken. Das bezieht sich weniger auf die mit Rahmen möglichen Darstellungseffekte, sondern vielmehr auf ihre Auswirkungen auf das Layout. Dies gilt besonders für proportionale (»flüssige«) Layouts. Zu Schwierigkeiten kommt es besonders dann, wenn Rahmen auf die Beschränkungen des sogenannten »strikten« Darstellungsmodus treffen. Hierbei müssen Trennlinien mit fester Breite für sichtbare Außenabstände von Elementen mit proportionalen Größen definiert werden. Stellen Sie sich drei Designelemente vor, die von links nach rechts angeordnet sind und jeweils ein Drittel der verfügbaren Fläche einnehmen: #werbung .promo { float: left; width: 32%; height: 11.417em; margin: 3.125%; }
Rahmen, Innen- und Außenabstände
|
83
Sofern es keine Darstellungsprobleme und Rundungsfehler gibt, verteilt die oben stehende Regel drei gleich breite Elemente von links nach rechts auf der Seite. Die Außenabstände betragen jeweils 1% der Breite von #werbung. Was passiert aber, wenn diese Elemente mit einem ein Pixel breiten Rahmen versehen werden sollen (z.B.: border: 1px solid #000)? Die zusätzlichen sechs Pixel für #werbung sorgen jetzt dafür, dass das letzte Element unter seine Vorgänger verschoben wird. Die Lösung für unser Layoutproblem wird dadurch noch schwerer. Würde die Breite von #werbung sich immer in Pixeln ausdrücken lassen, könnte man einfach die Werte für width und margin entsprechend in Pixeln neu formulieren und dann die Rahmen hinzufügen. Wurde #werbung dagegen proportional definiert und ist die Breite nicht statisch, hat der Gestalter zwei Optionen: Sich auf die inneren Elemente verlassen Hierbei enthalten die .promo-Elemente wahrscheinlich eine Überschrift und ein weiteres Element für den Haupttext. Wenn man die vertikalen Innen- und Außenabstände dieser beiden inneren Elemente entsprechend anpasst, haben ihre Inhaltsbereiche zusammen die gleiche Höhe (minus zwei Pixel) wie die sie umgebenden Elemente. Jetzt kann jedem Element ein seitlicher Rahmen von einem Pixel Breite zugewiesen werden. Hintergrundbilder verwenden Anstatt die Rahmen mit der CSS-Eigenschaft border zu definieren, können die Trennlinien auch als Hintergrundbilder definiert werden, die nach Bedarf in .promo und dessen Kindelementen platziert werden. Eine detaillierte Beschreibung dieser Technik finden Sie in Kapitel 9.
Innenabstände Der größte designerische Wert von Innenabständen (padding) besteht in der Möglichkeit, Leerraum zu schaffen – Bereiche, in denen nur der Hintergrund (falls vorhanden) eines Elements sichtbar ist. Abgesehen von Fällen mit gemischten Längeneinheiten, wie zuvor am Fall der Rahmen beschrieben, gibt es nur selten Probleme mit den Eigenschaften für Innenabstände. Innenabstände haben aber noch einen anderen Vorteil: Sie werden auch bei aneinandergrenzenden Elementboxen niemals zusammengefasst. Aus diesem Grund werden für Layoutobjekte, z.B. Spalten, Innenabstände definiert, obwohl die Verwendung von Außenabständen naheliegender wäre. Gerade bei komplexen Layouts kann man sich die Auswirkungen von Eigenschaften besser vorstellen, wenn diese nicht miteinander interagieren.
Das Box-Verhalten der Wurzelelemente des Dokuments Die Box-Eigenschaften für den Darstellungsbereich des Browsers und das body-Element verhalten sich anders als die übrigen Elemente, besonders, wenn die Dokumente als XML übergeben werden. 84
|
Kapitel 6: Lösungen für das CSS-Layout-Puzzle
Standardmäßig umgeben die Browser Dokumente, die als text/html ausgeliefert werden, mit einem Leerraum von 10 Pixeln Breite. Dieser wird in fast allen Fällen als Wert der Eigenschaft margin für das body-Element definiert. In aktuellen Browsern ist es außerdem möglich, Box-Eigenschaften nicht nur für body, sondern auch für das Wurzelelement html zu definieren. Oft setzen Gestalter diese Werte deshalb wie folgt zurück: html, body { margin: 0; padding: 0; }
Abgesehen von solchen »Resets«, sollte man bei der Definition von Werten für die Box von body und html sehr vorsichtig vorgehen bzw. sie aus folgenden Gründen möglichst ganz vermeiden: • Box-Werte für das html-Element werden vom Internet Explorer 6 komplett ignoriert. • Eine Änderung der Box-Eigenschaften für das body-Element hat keine Auswirkungen auf die Hintergrundfarben und -bilder des Dokuments. Diese werden immer im Kontext des gesamten Darstellungsbereichs angewandt. • Änderungen der Box-Eigenschaften für das html-Element verändern die Positionierung des body-Elements, was in der Folge auch die Platzierung der enthaltenen Elemente durcheinanderbringen kann.
Längenangaben für Box-Eigenschaften und Prozentwerte Wenn Sie für eine beliebige Box-Eigenschaft (außer height) einen Prozentwert verwenden, wird das Ergebnis proportional zur berechneten Breite des Elements ermittelt (oder des Elternelements, sofern es um width geht). Bei den Werten für height ist die Sache etwas schwieriger. In Prozent angegebene Werte beziehen sich auf die Höhe des umgebenden Blocks. Hierfür muss mindestens eines der Vorfahren-Elemente eine explizite Höhe aufweisen, ansonsten wird der Standardwert auto verwendet.
Darstellungsrollen Wie Sie in Abbildung 6-5 sehen, gibt es drei grundsätzliche Arten, ein Element im Fluss des Dokuments darzustellen (sowie eine Reihe von Sonderfällen, auf die wir an geeigneter Stelle eingehen werden). Diese in der jeweiligen HTML-Spezifikation für jedes Element definierte Darstellungsrolle wird über einen Wert der CSS-Eigenschaft display gesteuert. Die drei wichtigsten und häufigsten Werte sind: inline, block und inline-block.
Darstellungsrollen
|
85
Inline
Block
Inline-Block
Abbildung 6-5: Die drei grundsätzlichen Darstellungsrollen sind »inline«, »block« und »inline-block«.
Das Verhalten der Elemente im Fluss des Dokuments kann zudem über die Eigenschaften float und/oder position beeinflusst oder auch negiert werden.
Inline-Elemente Inline-Elemente, wie z.B. strong werden wie normaler Text dargestellt. Inline-Elemente haben die gleiche Grundlinie wie der sie umgebende Text, Zeilenumbrüche werden bei Bedarf automatisch eingefügt. In aktuellen Browsern ist es möglich, eigene Rahmen, Innen- und Außenabstände für Inline-Elemente zu definieren. Diese Werte haben aber keinen Einfluss auf die umliegenden Inhalte. Für Inline-Elemente können nicht alle CSS-Eigenschaften verwendet werden, die für Block-Elemente möglich sind. Sogenannter anonymer Text, der nicht in Inline-Elementen enthalten ist, verhält sich wie Inline-Inhalt, kann in einem Stylesheet aber nur über das Elternelement angesprochen werden.
Block-Elemente Für Standard-Block-Elemente gelten vier einfache Regeln: 1. Block-Elemente füllen den gesamten horizontalen Raum des umgebenden Elements. 2. Block-Elemente überschneiden sich nicht, außer durch Elemente, die sie selbst enthalten. 3. Der Inhalt eines Block-Elements darf nur aus anderen Block-Elementen, Text, Inlineund Inline-Block-Elementen bestehen. 4. Für Block-Elemente können alle CSS-Eigenschaften angewandt werden. Mit der vierten Regel ist es möglich, absichtlich die beiden ersten Regeln zu umgehen.
86
|
Kapitel 6: Lösungen für das CSS-Layout-Puzzle
In der dritten Regel sehen wir die Möglichkeit »anonymer« Inhaltsboxen, durch die Teile des Inhalts sich wie Block-Elemente verhalten können, ohne dabei für CSS zugänglich zu sein. Angenommen, Sie haben folgendes Quellcode-Fragment:
Lorem ipsum dolor sit amet,
Consectetur adipiscing elit.
In diesem Fall empfiehlt es sich, die Passage außerhalb des Absatzes zu »reparieren«, indem sie explizit in einem Block-Element platziert wird, wodurch man vollen Zugriff per CSS erhält. Für eingebettete Inhalte ist dieses Vorgehen nicht nötig, es sei denn, die Darstellung soll für vollkommen beliebige Stellen im Dokument angepasst werden.
Inline-Block-Elemente Viele Inline-Block-Elemente werden in den technischen Dokumenten des W3C auch als »ersetzte« Elemente bezeichnet. Dieser Begriff wurde gewählt, weil diese Elemente oft erst während der Darstellung ihren tatsächlichen Inhalt, z.B. Bilder, Formularelemente und andere Objekte erhalten, die normalerweise mithilfe des Betriebssystems dargestellt werden. Inline-Block-Elemente haben das gleiche Flussverhalten wie Inline-Elemente. Sie werden also nebeneinander auf einer gemeinsamen Grundlinie dargestellt. Leerraum um die und innerhalb der Elemente wird, Inline-Elementen entsprechend, im Darstellungsbereich des Browsers dargestellt. Trotz des Flussverhaltens kann die gesamte Bandbreite der CSSEigenschaften für Block-Elemente verwendet werden. Die Eigenarten beim Flussverhalten von Inline-Block-Elementen werden im folgenden Abschnitt zur Eigenschaft display besprochen.
Das Flussverhalten eines Elements mit »display« ändern Mithilfe der Werte für die CSS-Eigenschaft display können Sie die Standard-Darstellungsrolle eines Elements verändern und damit das Flussverhalten nach Bedarf anpassen. Hiermit lässt sich eine Reihe beliebter Effekte erzielen, wie auf der Website zu diesem Buch dokumentiert ist, z.B.: • Primäre Navigationslinks auf kommerziellen Websites werden oft horizontal angeordnet. Dies geschieht durch die Änderung der Darstellungsrolle für Listeneinträge in block und eine Reihe zusätzlicher Eigenschaften, speziell float. (Dies beseitigt außerdem eine Unklarheit in den HTML-Dokumenttyp-Definitionen.) Sollen die Navigationslinks die gleiche oder eine statische Größe haben, so ist diese Methode, zusammen mit der Definition display: block für Hyperlinks, der Schreibweise #navigation li { display: inline } vorzuziehen.
Das Flussverhalten eines Elements mit »display« ändern
|
87
• Sobald die Links als Block-Elemente definiert sind, können Sie die Breite und Höhe per width bzw. height beliebig anpassen, was die Darstelung innerhalb von WebApplikationen deutlich vereinfacht. Außerdem kann mit dieser Methode der anklickbare Bereich der Links erweitert werden. Dies entspricht der Anwendung eines Prinzips der Mensch-Computer-Interaktion (HCI), das als »Fitt’s Law« bekannt ist: Je größer ein Objekt der Schnittstelle ist, desto leichter lässt es sich mit einem Zeigegerät (Maus, Trackpad etc.) aktivieren. • Die Art, wie sich geordnete und ungeordnete Listen zu ihren Nachbarn verhalten, kann geändert werden. Dadurch können Listeneinträge auch in anderen Inhaltsbereichen aufeinander folgend dargestellt werden. • Ändert man den display-Wert für Formularelemente in block, ist es möglich, sie auf einem vorhersagbaren Raster anzuordnen. • In den seltenen Fällen, in denen ein Element nicht komplett aus der Seite entfernt werden kann, ohne dass die Lesbarkeit der Quellcode-Formatierung leidet, kann die Regel display: none; helfen, Schablonen zu vereinheitlichen. • Einer Reihe ähnlicher Textfragmente oder anderer Inline-Elemente, die entlang einer gemeinsamen Grundlinie angeordnet werden sollen, kann der display-Wert inlineblock zugewiesen werden. Dies hat gleich zwei Vorteile für den Gestalter: eine gemeinsame Grundlinie und Zugriff auf sämtliche CSS-Layout-Eigenschaften.
Die Eigenschaft »display« Die wichtigsten Details zur Eigenschaft display stehen im Zusammenhang mit dem Wert none: • Von grafischen Benutzerprogrammen werden Elemente mit der Definition display: none so behandelt, als existierten sie nicht. • Die durch die oben genannte Regel verursachte »Unsichtbarkeit« wird auch von Hilfsgeräten oder -programmen (Bildschirmleseprogrammen, Braille-Zeilen etc.) umgesetzt. Auch bei der Verwendung des Wertes inline-block können unerwartete Ergebnisse auftreten. Da Elemente mit dieser Darstellungsrolle im Dokumentenfluss wie Inline-Elemente behandelt werden, werden Leerzeichen literal behandelt. Das heißt, es gibt keine Möglichkeit, Elemente vom Typ inline-block bündig mit ihren inline-Nacharn anzuordnen, ohne Änderungen am Markup vorzunehmen. Solche Anpassungen würden aber die in den Kapiteln 2 und 3 besprochene Trennung von Markup und Präsentationsebene verletzen. Zusätzlich zur Darstellung von Leerzeichen im Quellcode kann das Inline-Verhalten von inline-block-Elementen im Dokumentenfluss dazu führen, dass »weiche« Zeilenumbrüche in den Inhalt eingefügt werden. Das kann passieren, wenn diese Elemente eine nicht festgelegte Breite haben oder die Textgröße eines statischen Layouts verändert wird. Außerdem wird display: inline-block von älteren Browsern nur uneinheitlich (oder auch gar nicht) unterstützt.
88
|
Kapitel 6: Lösungen für das CSS-Layout-Puzzle
Die Eigenschaften »float« und »clear« Der Haupteffekt der Eigenchaft float könnte nicht leichter zu erklären sein: Wird für ein Element die Definition float: left bzw. float: right verwendet, wird es an den linken bzw. rechten Rand des umgebenden Elements verschoben. Gleichzeitig wird sein ursprünglicher Platz freigegeben, und der folgende Inhalt umfließt das Element (den Float), anstatt darunter dargestellt zu werden. Die Eigenschaft clear verhindert dagegen das Umfließen eines Floats, wie in Abbildung 6-6 gezeigt.
1 2
3
Abbildung 6-6: Das Verhalten der Eigenschaften »float« und »clear«. (1): »float« hat den Wert »left«, (2): »float« hat den Wert »none«. (3): »clear« hat den Wert »left«
Das ist zumindest die Theorie. In der Praxis sieht das schon anders aus. Die Eigenschaft float bietet die einzige Möglichkeit, in CSS 2.1 Layouts mit unterschiedlich hohen Spalten zu erstellen. Daher ist die genaue Kenntnis von float und seiner Verwendung ein wichtiges Werkzeug für jeden Gestalter.
Das Verhalten von Floats Um das Verhalten von Floats vorherzusagen, müssen Sie wissen, nach welchen Regeln diese Elemente von den Browsern dargestellt werden. Die folgenden Punkte sind eine kurze Zusammenfassung der Regeln aus den Abschnitten 9 und 10 der CSS 2.1-Spezifikation.
Ein Element, für das float: left oder float: right definiert wurde, muss folgende Bedingungen erfüllen: • Es muss eine eigene (direkt definierte oder geerbte) Breite besitzen, damit der floatWert eine Auswirkung hat. Die Eigenschaften »float« und »clear«
|
89
• Ein Float muss sich vollständig innerhalb des Blocks seines umgebenden Elements befinden, es sei denn, es ist von sich aus breiter oder höher als das umgebende Element (dieser Zustand hat möglicherweise auch Auswirkungen auf andere Elemente des Dokuments). • Mögliche Überschneidungen mit Elementen, die in der Quellcode-Reihenfolge vorher auftreten und selbst keine Floats sind, dürfen höchsten eine Zeile betragen. Dies ist wichtig, wenn von zwei benachbarten Floats eines den Wert left und das andere den Wert right hat. • Ein links angeordnetes Float muss so weit links wie möglich stehen. Das Gleiche gilt entsprechend für rechts angeordnete Floats. Eine höhere Position hat Vorrang gegenüber einer weiter links oder rechts befindlichen Position. • Floats müssen bündig mit den Elementboxen der Elemente dargestellt werden, die ihnen im Quellcode vorangehen und keine Floats sind, nicht aber mit deren Inhalt. Dieses Verhalten ist wichtig, wenn es um die Erstellung mehrspaltiger Layouts geht. Umgebende Elemente, die selbst als Float definiert wurden, spielen bei diesen Regeln eine wichtige Rolle, wie im folgenden Abschnitt erklärt wird. Ein Grund für die Verwendung der Regel float: none; könnte darin bestehen, einen woanders im Stylesheet definierten Wert ausdrücklich zu überschreiben. Dadurch lässt sich das Layout-Chaos vermeiden, das auftritt, wenn der Inhalt von Floats deutlich größer oder kleiner ausfällt, als vom Designer der Website vorgesehen war. Weitere Informationen zu diesen Regeln finden Sie in Abbildung 11-7 in Kapitel 11 sowie auf der Website zu diesem Buch.
Das »float«-Verhalten mit der Eigenschaft »clear« steuern Die Eigenschaft clear sorgt dafür, dass ein Float nicht vom folgenden Inhalt umflossen wird. Stattdessen wird der Inhalt unter das Float verschoben. Am häufigsten wird clear verwendet, um die obere Außenkante eines Elements bündig mit der unteren Außenkante eines vorangehenden Elements darzustellen. Tabelle 6-1: Die Werte der Eigenschaft »clear« und ihre Auswirkungen Wert
Auswirkung
none
Betroffene Elemente umfließen vorangehende Floats gemäß der per float definieren Regel (Standardwert).
left
Betroffene Elemente, die ein Float mit der Definition float: left normalerweise umfließen, werden unter das Float verschoben.
right
Analog zu left; angewandt im Zusammenhang mit Vorgänger-Elementen mit der Definition float: right.
both
Betroffene Elemente, die normalerweise ein vorangehendes Float umfließen, werden prinzipiell unter das Float verschoben. Standard-Außenabstände werden entsprechend angepasst.
Am besten versteht man das Verhalten von float und clear, indem man ein mehrspaltiges Layout zu erstellt, wie gleich erklärt wird.
90
|
Kapitel 6: Lösungen für das CSS-Layout-Puzzle
»float«-Kontext Wie bei anderen Box- und Layouteigenschaften wird auch die Anwendung von clear und float durch die Präsenz von float-Werten weiter »oben« in der Kaskade beeinflusst. In der folgenden Diskussion dreispaltiger Layouts wird empfohlen, zwei Spalten in einem Float zusammenzufassen. Ein Effekt dieser Technik besteht darin, dass zwei der »verpackten« Spalten in einem Float-Kontext behandelt werden, der von ihrem Elternelement vorgegeben wird. Hierdurch verändert sich der Geltungsbereich der float- und clearRegeln. Wenn man im gleichen Szenario (drei Spalten, vier Container) einem Element innerhalb des Floats, das die zwei Spalten enthält, die Regel clear: both zuweist, so werden die Außenabstände des Inhalts an die Außenabstände des umgebenden Floats angepasst, nicht an die des Seiten-Containers.
Mehrspaltige Layouts implementieren Die so häufig anzutreffenden und auch in Abbildung 6-7 gezeigten zwei- und dreispaltigen Layouts sind das Ergebnis mühsamer Arbeit. Vor der allgemeinen Unterstützung von CSS konnte das Seitenlayout nur durch die Verwendung von ineinander verschachtelten Tabellen kontrolliert werden, mal ganz abgesehen vom Missbrauch von Flash oder Bildern mit Imagemap-Links. Einmal auf das Wesentliche reduziert, sah das Markup für ein typisches Tabellen-Layout ungefähr so aus:
Dies ist der Kopfteil der Seite.
Dies ist die Seitenleiste.
Hier steht der Haupttext.
Und ich bin der Fußteil.
In der wirklichen Welt waren die verwendeten Tabellen oft noch viel komplexer. So wurden oft zusätzliche Spalten und Zeilen mit »unsichtbaren« Inhalten angelegt, um die nötigen Leerräume im Layout zu erzeugen. Im Jahr 2002 erstellte ich beispielsweise für eine E-Mail-Kampagne eine Tabelle, die aus 40 Spalten bestand, obwohl kein Teil des Layouts mehr als vier Spalten mit Inhalt besaß. Der Rest wurde benötigt, um Regeln und Anpassungen der verschiedenen Abschnitte im Layout-Raster zu realisieren.
Mehrspaltige Layouts implementieren
|
91
Browserfenster
margin-right: …
#seitenleiste
#kopfteil
#haupttext
float: right;
#fussteil clear: both;
#hauptteil
Abbildung 6-7: Die Quellcode-Reihenfolge dieser Elemente ist: #hauptteil – #kopfteil – #haupttext – #seitenleiste – #fussteil; jeder Bereich wird zusammen mit den »float«- und »clear«-Werten für das betreffende Element dargestellt.
Erfahrene Markup-Experten verwenden solche Tabellen noch immer, da die Unterstützung für CSS selbst in aktuellen E-Mail-Programmen nur sehr spärlich ist (und ohne dass Besserung in Sicht wäre).
Ein zweispaltiges Tabellen-Layout nach CSS portieren Wenn Sie auch nur ein bisschen mit zweispaltigen Layouts experimentiert haben, wissen Sie, dass dabei viel schiefgehen kann, z.B.: • Auf den ersten Blick scheint die Anwesenheit von float- und width-Werten für alle Spalten eine Beziehung zwischen Quellcode-Reihenfolge und der Präsentationsschicht zu erzwingen. Bei diesem Ansatz gibt es einfach zu viele Fehlerquellen, speziell im Internet Explorer 6. • Die Verwendung der Regel position: absolute verringert das Risiko von Patzern. Um einen vernünftigen Fußteil zu definieren, müssen Sie jedoch vorher die relativen Spaltenhöhen kennen. Das ist kaum machbar. Das erste Problem lässt sich lösen, indem Sie nur für die Spalten float-Werte definieren, die tatsächlich als Float definiert werden müssen. Die übrigen Spalten kontrollieren Sie mithilfe der Eigenschaft margin. Die Verwendung der Eigenschaften für die Positionierung findet bei mehrspaltigen Layouts dagegen eher selten statt. Die Chancen stehen gut, dass Sie sie für Navigationslinks einsetzen, aber nicht für Spalten mit dem eigentlichen Inhalt.
92
|
Kapitel 6: Lösungen für das CSS-Layout-Puzzle
Die Migration zu CSS scheint in diesem einfachen Beispiel mehr Arbeit zu bedeuten. Die Namen der Elemente ändern sich. Zwar wird ihre Zahl geringer, aber dafür müssen Sie bergeweise CSS-Regeln schreiben. Hier ist der Markup-Code (den Sie auch auf der Website zu diesem Buch finden). Dies ist der Kopfteil. Hier steht der Haupttext. Dies ist die Seitenleiste. Und ich bin der Fußteil.
Und hier sind die dazugehörigen CSS-Regeln: #hauptteil #hauptteil, #kopfteil, #fussteil #haupttext #seitenleiste #fussteil
Abbildung 6-8 zeigt dieses Markup in einem Raster.
#bodycopy {float: right; width 23.3333em; }
#sidebar { margin-right: 23.833em; } #footer { clear: both; } #sidebar, #footer { height: 2.5em; } /* swallows up the bottom-margin of the h4 elements */ #main { height: 1%; overflow: auto; }
Abbildung 6-8: Die gesammelten Auswirkungen der Stilregeln für das zweispaltige Markup, eine Regel nach der anderen Mehrspaltige Layouts implementieren
|
93
Die Regeln für das zweispaltige Layout Wie die erste Regel zeigt, gehen die Beispiele für das Markup und die Stilregeln von einem Layout mit festen Breiten aus, entsprechend den meisten Tabellen-Layouts. Die Einstellung margin: auto für die drei Container-Elemente der Seite stellt sicher, dass sie im Darstellungsbereich des Browsers zentriert werden. Der Hauptteil erhält den id-Wert #haupttext. Da dies das erste Element im #hauptteil ist, benötigt es Werte für float und width. Außerdem verwenden wir hier die bereits beschriebene overflow: auto-Methode. Wirklich nötig ist sie allerdings nur, wenn Hintergrund-Eigenschaften direkt für den #hauptteil definiert werden. Der sekundäre Inhalt (sitespezifische Metadaten) kommt als Nächstes und erhält die ID #seitenleiste. Der Wert für diese Spalte behält den Standardwert auto, da kein floatWert definiert werden muss. Die Breite kontrollieren wir mit der Eigenschaft marginright. Dieser Ansatz zur Kontrolle der Breite wird aufgrund der Flexibilität, die zusammengefasste Außenabstände bieten, bevorzugt: Bei der Verwendung veränderlicher Längeneinheiten wie em ist das Risiko von Rundungsfehlern der berechneten Werte und damit auch die Gefahr von Darstellungsproblemen größer. Die Verwendung von marginright riskiert dagegen kleinere Variationen in der Breite des Inhalts, die zwar auch nicht erwünscht, aber deutlich weniger schmerzhaft sind. Durch die Definition von overflow: auto für den #hauptteil ist die Verwendung von clear: both für den #fussteil eigentlich unnötig. Das ändert sich, sobald der Wert für overflow aus dem Stylesheet entfernt wird. Hierdurch wird der Darstellungsbereich von #hauptteil von der Unterkante der #seitenleiste begrenzt. Durch die Regel clear: both für den #fussteil wird sichergestellt, dass dieser immer unterhalb der Spalten des #hauptteils dargestellt wird. Die Auswirkungen sehen Sie in Abbildung 6-8. Zwei Dinge haben wir bei den gezeigten Stilregeln nicht berücksichtigt: Dies ist einerseits die mit Sicherheit auf der Seite vorhandene Navigation. Sehr wahrscheinlich befinden sich die Links entweder im #kopfteil oder in der #seitenleiste. Etwas fortschrittlicher ist der Ansatz, die Navigation in der Quellcode-Reihenfolge zwischen #hauptteil und #fussteil zu platzieren, während sie im Layout relativ weit oben dargestellt wird. Hierfür sind allerdings sowohl die Eigenschaften zur Positionierung als auch Verwendung vertikaler Außenabstände nötig (oder ein entsprechender Wert von padding-top für #seitenleiste, falls sich die Navigation am Anfang dieser Spalte befinden soll). Der zweite vernachlässigte Punkt ist, dass es wahrscheinlich irgendwo in der Nähe von #fussteil negative Außenabstände gibt, besonders wenn sich die sekundäre Navigation außerhalb von #fussteil befinden soll. In der Praxis ist die Verwendung von Außenabständen, Rahmen und manchmal auch Innenabständen für die einander zugewandten Außenkanten von #kopfteil und #fussteil ziemlich kompliziert. Aufgrund der verschiedenen kombinierten Werte für diese Layoutbereiche müssen sehr feine Abstimmungen vorgenommen werden. Nicht selten wird mindestens ein negativer Außenabstand benötigt.
94
|
Kapitel 6: Lösungen für das CSS-Layout-Puzzle
Auch ist es möglich, die beiden Spalten per float: left und float: right zu definieren und gleichzeitig beim #haupttext der Eigenschaft overflow den Wert auto und height den Wert 1% zu geben. Wir haben diese Methode hier nur kurz angesprochen, weil sie die unangenehme Angewohnheit hat, Darstellungsfehler in Internet Explorer 6 auszulösen.
Vorteile der Beschränkung von Layout-Anweisungen auf Stylesheets Wenn Sie sich die gerade besprochenen unzähligen Verflechtungen und Vorbehalte ansehen, ist die Frage berechtigt, ob es sich wirklich lohnt, Layouts mit CSS zu erstellen. Die Antwort hat komplett mit Vereinfachung zu tun, auch wenn das auf den ersten Blick überhaupt nicht einleuchten mag. Der Aufwand für komplexere Stylesheets wird durch einfacheres Markup mehr als ausgeglichen. Einige Vorteile sind: Der Inhalt erscheint in logischer Reihenfolge Zwischen der Quellcode-Reihenfolge von Inhalten, deren Layout durch die Verwendung von table-Elementen erstellt wurde, und ihrer Position auf der Seite gibt es eine direkte Beziehung. Daher stehen hierbei die Definitionen für Seitenleiste und die Navigation (die oft im Kopfteil der Seite dargestellt wird) meist am Anfang des Markup-Codes. Der eigentliche Inhalt der Seite, der in den Ergebnissen der Suchmaschinen auftauchen sollte, wird im Quellcode unter diese Meta-Inhalte verschoben. Lange Zeit waren Layouts tabellenbasiert, und das hat selbst heute noch Auswirkungen. Benutzer von Hilfsgeräten erwarten etwa immer noch, dass die Seitennavigation sich in ihrer Wahrnehmung am »Anfang« der Seite befindet, weil ihre Werkzeuge ihnen die Inhalte in der Reihenfolge des Markup-Codes darstellen. Elemente werden body nur hinzugefügt oder aus body entfernt, wenn es auch Inhalte hinzuzufügen oder zu entfernen gibt Weniger häufige Änderungen bedeuten normalerweise auch weniger Änderungen insgesamt. Das heißt, es muss auch weniger Arbeit bestätigt und dokumentiert werden. Je größer die daraus resultierende Vereinfachung ist, desto geringer ist auch der langfristige Wartungsaufwand. Das vereinfachte Markup verbessert Portabilität und Zugänglichkeit Die offensichtlichste Folge dieser Tatsache hat mit dem Ausdrucken zu tun: Wenn Sie einen »Diese Seite drucken«-Link benötigen, kann das Dokument am anderen Ende des Links exakt das gleiche Markup-Template verwenden wie die Bildschirmdarstellung. Elemente, die nicht mit ausgedruckt werden sollen (z.B. die Navigation), lassen sich leicht per display: none; verstecken. (Besser ist es allerdings, diese Teile mit einer Markup-Struktur zu umgeben, die ein- und ausgeschaltet werden kann.) Sonderfälle lassen sich leichter handhaben, wenn ein ausreichender Vorrat an class- und id-Attributen im Markup-Code vorhanden ist Im Austausch für die erhöhte Zahl von class- und id-Attributen müssen die Entwickler für eine Site weniger Templates (oder Template-Fragmente) erstellen und warten.
Mehrspaltige Layouts implementieren
|
95
Die von dem Template getrennten Präsentationsanweisungen bieten große Erleichterungen für Entwicklung, Einsatz, Verbesserungen und Redesigns einer Website Benötigt Ihre Website einen neuen Abschnitt, kann dieser zum Template hinzugefügt werden. Die meisten Darstellungsdetails lassen sich durch Änderungen am Stylesheet vornehmen. Mit sauberen Stylesheet-Regeln sollte es möglich sein, Abschnitte durch einfaches Auskommentieren im Template-Markup aus dem Layout zu entfernen. Vergleichen Sie diesen »kurzen Prozess« mit den umfangreichen Änderungen, die beim tabellenbasierten Layout nötig wären. Welcher Ansatz ist also der bessere? Neben diesen Vorteilen wird oft behauptet, dass mehr Inhalt und weniger Markup auch der Suchmaschinenoptimierung (SEO) gut tut. Dies steht in direktem Zusammenhang mit gut geschriebenem CSS-Code, wie er in den zuvor gezeigten Beispielen zu sehen war. Ohne die Möglichkeit, ansonsten gleiche Dokumente vergleichen zu können, fällt es mir schwer, diese Meinung ohne Skepsis zu teilen. Andererseits scheint die Bereitschaft so vieler Leute, an die Vorteile von SEO zu glauben, ja irgendeinen Grund zu haben, oder?
Zwei Spalten auf drei Spalten erweitern Zweispaltige Layouts sind einfach: Solange Sie keine komplizierten Hintergründe verwenden, reicht ein float-Wert hier und ein margin-Wert dort, und der Fußteil kann trotzdem problemlos am Seitenende platziert werden. Es gibt aber auch noch eine andere Möglichkeit, zweispaltige Layouts zu erstellen: Manche Leute bevorzugen beispielsweise float-Werte für beide Spalten. Diese Technik basiert auf einer Kombination aus »Faux Columns« (»falschen« Spalten) und der Zuweisung von clear: both für den Fußteil. Wenn Sie sich entscheiden, ein dreispaltiges Layout zu erstellen, erhöht sich die Anzahl von Kombinationen aus float und margin bereits auf sechs. Außerdem müssen zwei dieser Spalten mit einem Container-Element umgeben werden, um ihre Breite kontrollieren zu können. Normalerweise wollen Sie den Container für die ersten beiden im Quellcode definierten Spalten verwenden. Allerdings gibt es bei zwei der sechs möglichen Kombinationen Schwierigkeiten, weil diese Spalten im Layout nicht aneinandergrenzen. Wie gesagt, es gibt insgesamt sechs Möglichkeiten, die Spalten eines dreispaltigen Layouts anzuordnen. Die Optionen sehen Sie in Abbildung 6-9. Die dazu nötigen Werte für float und margin sind in Tabelle 6-2 aufgelistet.
96
|
Kapitel 6: Lösungen für das CSS-Layout-Puzzle
2
1
3
3
1
2
1
2
3
none
right
none
none
left
none
left
none
none
left
right
left
1
3
2
2
3
1
3
2
1
left
none
right
left
none
right
none
none
right
none
none
right
Abbildung 6-9: Quellcode-Reihenfolge und dazugehörige »float«-Werte für die sechs Möglichkeiten dreispaltiger Layouts Tabelle 6-2: Spaltenreihenfolge (von links nach rechts) und entsprechende Eigenschaftswerte für »float«/ »margin«1; Spalten sind entsprechend ihrer Quellcode-Reihenfolge gekennzeichnet; eckige Klammern stehen für Container-Elemente. Darstellungsreihenfolge
Container-Layout
Quellcode-Layout der Spalten Spalte 1
Spalte 2
Spalte 3 2
[ [2, 1], 3]
float: left;
float: right;
margin-right: x;
[3, [1, 2] ]
float: right;
float: left;
margin-left: x;
margin-left: x;
[ [1, 2], 3]
float: left;
float: left;
margin-left: x;
margin-left: x;
[1, [3, 2] ]
margin-left: x;
float: left;
float: right;
margin-right: x;
[ [2, 3], 1]
margin-right: x;
float: right;
float: left;
margin-left: x;
[3, [2, 1] ]
float: right;
float: right;
margin-right: x;
margin-right: x;
margin-right: x;
1 Floats benötigen einen passenden Wert für »width«, während für Elemente mit einem »margin«-*-Wert ein »width«-Wert nicht unbedingt nötig ist. 2 x steht hier für eine variable Breite, nicht für eine Längenangabe, die in einem gegebenen Layout konstant bleibt.
Mehrspaltige Layouts implementieren
|
97
Soll in den zwei »Sonderfällen« der Bereich des Containers für die »inneren« Spalten an die anderen vier Fälle angepasst werden, wie in Abbildung 6-9 zu sehen ist, so können Sie dies mit den folgenden vier Schritten erreichen: 1. Verschieben Sie den inneren Container, so dass er die ersten beiden Spalten im Quellcode umgibt. 2. Entfernen Sie die Eigenschaft width für den inneren Container. 3. Weisen Sie den ersten beiden Spalten passende Werte für float und width zu. 4. Geben Sie der dritten Spalte einen passenden Wert für margin. Die margin-Werte müssen hierbei größer oder gleich der Summe der width-Werte aus Schritt 3 sein. Die beiden Ansätze zur Vermeidung von Kollisionen zwischen Hauptinhalt und Fußteil – overflow: auto und height: 1% für das Element, das die Spalten enthält, und die Definition von clear: both für den Fußteil – lassen sich unabhängig von der Zahl der Spalten in
Ihrem Layout verwenden. Stylesheets und Templates für die sechs in Tabelle 6-2 beschriebenen Layouts finden Sie auf der Website zu diesem Buch.
Mehr als drei Spalten Je mehr Spalten Sie in einem Layout verwenden, desto attraktiver wird die Verwendung von overflow: auto für einen oder mehrere der Container. Selbst die Verwendung mehrerer float-Werte in Folge – und damit das Risiko von Darstellungsproblemen durch Rundungsfehler in Internet Explorer – ist hier praktikabel, denn jede erfolgreiche Lösung für ein Layoutproblem ist in diesem Fall gut genug.
Semantisch leere Container für mehrspaltige Layouts Bei der genauen Betrachtung der Ergebnisse fällt auf, dass viele der hier gezeigten mehrspaltigen Layouts auch ohne zusätzliche Container für »innere« Spalten auskommen. (Falls Sie diesen Teil überspringen möchten, können Sie auch einfach auf der Website zu diesem Buch nachsehen.) Die Verwendung leerer Container-Elemente wird oft als überflüssiges Markup angesehen, was per Definition keine gute Ergänzung wäre. Das stimmt auch, sofern Sie eines der hier gezeigten dreispaltigen Templates verwenden. Sollen Inhalte aber beispielsweise von der Seitenleiste in die mittlere Spalte verschoben werden, sind möglicherweise mehrere Suchläufe über die Templates nötig. Dieser Schritt sollte nach den Regeln des CSS-Zen eigentlich vollkommen unnötig sein. Der innere Container bietet jedoch den besten Schutz gegen Fehler und bietet gleichzeitig die größte Flexibilität, wenn alle Spalten über die gesamte Höhe einen eigenen Hintergrund haben sollen.
98
|
Kapitel 6: Lösungen für das CSS-Layout-Puzzle
Fortgeschrittenes Layout mit CSS 3 Die aktuellen Entwürfe der CSS 3-Module spezifizieren die Unterstützung für mehrspaltige Layouts und Eigenschaften, mit denen Gestalter ein tabellenähnliches LayoutVerhalten definieren können. Das Modul für mehrspaltiges Layout (css3-multicol) enthält CSS-Eigenschaften, mit denen ein einzelnes Element in mehrere Spalten aufgeteilt werden kann. Höhe, Inhaltslänge und der Abstand zwischen den Spalten kann für jede Spalte einzeln festgelegt werden. Außerdem gibt es die Eigeschaft column-span, mit der festgelegt werden kann, dass ein Element sich über mehrere Spalten erstrecken kann. Der übrige (Inline-)Inhalt wird ober- und unterhalb des Elements fortgesetzt. Das Modul spezifiziert nach dem momentanen Stand Erweiterungen für die Eigenschaften display und position, mit denen Layout-Raster definiert werden können, die sich an das
Verhalten der Layout-Tabellen anlehnen, die im Abschnitt »Mehrspaltige Layouts implementieren« auf Seite 91 beschrieben wurden. Die Werte für die Erweiterung von display können entweder als Buchstaben (ASCII) oder als eine von zwei Konstanten angegeben werden. Die erste Konstante ist das @-Zeichen. Hiermit wird definiert, wo der Inhalt angezeigt werden soll, wenn keine ausdrückliche Position im definierten Raster angegeben wurde. Die zweite Konstante ist ein Punkt (.), mit dem die Zwischenräume eines Layouts definiert werden. Das JavaScript-Framework jQuery enthält ein Modul, mit dem das Verhalten des CSS 3-Template-Moduls emuliert werden kann. Dies geschieht, indem Gestalter eigene display- und position-Eigenschaften definieren (z.B. -mein-raster-display) und den Namen der CSS-Datei mit dem Template-Layout angeben.
CSS-Eigenschaften für die Positionierung Die Eigenschaft position übernimmt einen von vier möglichen Werten (Standard: static). Zusammen mit Eigenschaften wie top, left etc. können Elemente an beliebiger Stelle im Layout positioniert werden. Wird für position ein anderer Wert als static definiert, verändert sich der Positionierungskontext der Elemente, wie kurz in Kapitel 3 beschrieben wird.
Wie die Positionierung funktioniert Nehmen wir beispielsweise die folgenden Werte: #meinDiv { ... left: 160px; top: 96px; }
Gehen wir weiter davon aus, dass diese Werte auf das folgende Markup angewendet werden: ... ... Der Rhabarber pokert leise im Mohnfeld. ...
CSS-Eigenschaften für die Positionierung
|
99
Dann haben die vier möglichen position-Werte für #meinDiv die folgenden Auswirkungen: static
Die Werte für left und top werden nicht verwendet. Das Element behält seine erwartete Position im Dokumentenfluss. absolute
Die linke obere Ecke von #meinDiv wird 96 Pixel unter und 160 Pixel rechts von der linken oberen Ecke des Ansichtsbereichs dargestellt. Eventuell für body angegebene Außen- und Innenabstände werden hierbei nicht berücksichtigt. Das Element wird aus dem normalen Fluss der Elemente im Dokument ausgenommen; der Platz wird für die folgenden Elemente freigegeben. fixed fixed hat die gleichen Auswirkungen position: absolute. Allerdings behält das
Element seine Position im Ansichtsbereich des Browsers auch dann, wenn der Inhalt gescrollt wird. Das Element wird aus dem normalen Fluss der Elemente im Dokument ausgenommen, der Platz wird für die folgenden Elemente freigegeben. relative
Hierbei wird der Abstand nicht von der linken oberen Ecke des Ansichtsbereichs berechnet, sondern von der linken oberen Ecke seiner ursprünglichen Position im Layout des Dokuments. Das Element behält also seine Platzierung im Dokumentenfluss, wird aber um die mit top, left etc. angegebenen Werte verschoben. Der ursprüngliche Platz bleibt leer. Für das nächste Beispiel erweitern wir das Stylesheet um folgende Regel: #hauptteil { position: relative; margin: 20px; }
Standardmäßig haben die Eigenschaften top, right, bottom und left den Wert 0 (Null). Allerdings verändert die Zuweisung von position: relative den Positionierungskontext für #meinDiv. Anstatt an der linken oberen Ecke des Ansichtsbereichs wird #meinDiv nun an der linken oberen Ecke von #hauptteil ausgerichtet. Durch diese Definition bezieht sich die Position von #meinDiv nun auf die linke obere Ecke von #hauptteil. Durch die Angabe von margin: 20px wird auch der Inhalt von #hauptteil und damit auch von #meinDiv verschoben (siehe Abbildung 6-10). Die Abbildungen basieren auf dem Markup und den Stilregeln für das zweispaltige Layout (siehe im Abschnitt »Ein zweispaltiges Tabellen-Layout nach CSS portieren« auf Seite 92). Noch ein paar Details zur Positionierung von Elementen im Fluss der umgebenden Elemente im Dokument: Wird ein Element aus dem Fluss entfernt, hat dies den gleichen Effekt wie die Definition von display: none, wobei das Element jedoch an den vom Gestalter festgelegten Koordinaten sichtbar bleibt. Wird ein Element relativ positioniert, behält es seine ursprüngliche Position im Dokumentenfluss mit sämtlichen Konsequenzen für die benachbarten Elemente. Es verschiebt sich also nur seine Darstellung gemäß der angegebenen Koordinaten.
100
|
Kapitel 6: Lösungen für das CSS-Layout-Puzzle
#seitenleiste p { position: static; }
#seitenleiste p { position: relative; }
#seitenleiste p { position: absolute; }
#hauptteil { position: relative; }
/* Dieser Wert entfernt das Element aus dem "normalen" Fluss. Es nimmt die gesamte Breite des Hauptteils ein, da für sein Elternelement die Standardwerte für position und width verwendet wurden. */
/* Ändert den Positionierungskontext aller Nachfahrenelemente von #hauptteil. */ #seitenleiste p { position: absolute; } /* Der Ursprung für die Positionierung dieses Elements ist jetzt die linke obere Ecke des Elements #hauptteil. */
Abbildung 6-10: Eine Darstellung des Verhaltens der in diesem Abschnitt beschriebenen Elemente und Stile
Und noch ein Hinweis: Internet Explorer 6 und 7 stellen Außenabstände anders dar als andere Browser, wenn position: relative verwendet wurde, um einen anderen Positionierungskontext zu schaffen, wie in der später gezeigten Erstellung eines Navigationslayouts gezeigt wird. In der Praxis sollten Sie man diese Werte in einem per Conditional Comments (siehe Kapitel 3) eingebundenen Stylesheet ggf. zurücksetzen.
Positionierte Elemente begrenzen Die Eigenschaften top und left finden ihre »Gegenspieler« in den Eigenschaften right und bottom. Es können die gleichen Längeneinheiten wie für die Box-Eigenschaften verwendet werden. Die letzen beiden Eigenschaften werden allerdings deutlich seltener verwendet, weil sich die Größe des Browser-Ansichtsbereichs nur sehr schwer voraussagen lässt.
CSS-Eigenschaften für die Positionierung
|
101
Trotzdem können in allen modernen Browsern einander ergänzende Werte anstelle von width (oder height, wenn auch deutlich seltener) angegeben werden. Die Regel #meinDiv { position: absolute; left: 25%; right: 25%; }
Diese Technik zur Begrenzung kann bei der Erstellung von Layouts mit variablen Breiten hilfreich sein, wenn die Außenabstände in Längeneinheiten anstelle von Prozentwerten definiert werden müssen. Wie top und left verschieben auch \}right\{ und \}bottom\{ die Außenabstände ihres Elements möglicherweise über die Ränder des Elements hinaus, das den Positionierungskontext definiert, wie in Abbildung 6-11 dargestellt.
Abbildung 6-11: Negative Werte für right und bottom verschieben das betroffene Element in die entgegengesetzte Richtung.
102
|
Kapitel 6: Lösungen für das CSS-Layout-Puzzle
»width: auto« und nicht-standardmäßige Werte für »position« und »float« Hat position für ein Element den Wert absolute oder static, aber keinen speziellen Wert für width, wird wie bei normalen Elementen standardmäßig die gesamte Breite des umgebenden Elements ausgenutzt. Wurde also ein Wert für left oder right definiert, hat sein »Gegenstück« standardmäßig den Wert 0 (Null). Noch interessanter werden die Dinge, wenn ein absolutes oder als Float definiertes Element nur Inhalte mit einer eigenen Breite besitzt (z.B. Bilder oder Formularelemente). Hat width für das äußere Element den Wert auto, wird seine Breite wie bei einer Schrumpfverpackung an die Breite des Inhalts angepasst. In Abschnitt 10.3 der CSS 2.1-Spezifikation wird äußerst detailliert beschrieben, wie die Breite von Elementen bestimmt wird.
Die Eigenschaften »visibility« und »z-index« Die bisher besprochenen Eigenschaften für die Positionierung und Darstellung der Elementboxen wirken sich auf die Breite und Höhe der Elemente aus. Zudem gibt es zwei Eigenschaften, mit denen beeinflusst werden kann, ob ein Element vor oder hinter einem anderen dargestellt werden soll.
Ändern der Sichtbarkeit ohne Auswirkungen auf den Dokumentenfluss Die Regel display: none ist extrem nützlich. Allerdings verändert sie den Fluss der Elemente im Dokument. Anders funktioniert dagegen die Eigenschaft visibility. Neben dem Standardwert visible gibt es noch einen weiteren, recht gut unterstützten Wert: hidden. Hiermit ist es möglich, Inhalte von der Darstellung auszunehmen, ohne den Fluss der Elemente im Layout des Dokuments zu verändern. Während display: none dafür sorgt, dass das Element in der Darstellung ignoriert wird, entfernt visibility: hidden den Inhalt des Elements, seinen Hintergrund und eventuell definierte Rahmen. Stattdessen ist eine (scheinbar leere) Elementbox zu sehen. Die Anweisungen visibility: hidden und opacity: 0 haben die gleichen Auswirkungen. Der Hauptunterschied besteht in der Unterstützung durch die Browser. Während visibility Teil einer Ergänzung der ursprünglich 1996 entworfenen CSS-Spezifikation war, wird opacity nur von einigen Browsern unterstützt. Gleichzeitig taucht opacity als Teil der CSS 3-Eigenschaften wieder auf.
Stapelung Überlagern sich zwei Elemente – im einfachsten Fall, weil ein Element in einem anderen enthalten ist –, wird das in der Quellcode-Reihenfolge spätere Element über dem voranDie Eigenschaften »visibility« und »z-index«
|
103
gehenden dargestellt. Das ist an sich auch gut so. Durch Positionierung und die Tatsache, dass jedes Element allein schon zwei »Ebenen« besitzt, wird die Sache etwas komplizierter. Bei einem normalen Block-Element werden die Bestandteile in der folgenden Reihenfolge (von hinten nach vorne) gestapelt: 1. Hintergrundfarbe 2. Hintergrundbild 3. Rahmen 4. Inline-Inhalte 5. Als Float definierte Inhalte Inline-Elemente und Floats haben wiederum ihre eigenen Hintergründe, Rahmen und Inhalte und besitzen daher noch einmal eine eigene Stapelungsreihenfolge. Von dieser Liste sind alle Elemente ausgenommen, die für position einen anderen Wert haben als static. Jedes dieser Elemente besitzt seinen eigenen Stapelungskontext, der auf die gleiche Weise weitergegeben wird wie der Positionierungskontext. Befinden sich zwei Elemente im gleichen Stapelungskontext, hängt die Reihenfolge ihrer Stapelung davon ab, wo sie sich in der Quellcode-Reihenfolge befinden. Die Aufgabe der Eigenschaft z-index ist es, die standardmäßige Stapelungsreihenfolge für positionierte Elemente zu verändern. Angenommen, Sie haben eine Reihe positionierter Elemente im gleichen Positionierungskontext. Kommt es hierbei zu Überlagerungen in der Darstellung, werden Elemente, die später in der Quellcode-Reihenfolge stehen, in der Darstellung standardmäßig vor den anderen dargestellt. Soll ein bestimmtes Element unabhängig von seiner Position im Quellcode vor oder hinter einem anderen angezeigt werden, können Sie dies über einen entsprechenden Wert (abgesehen vom Standardwert auto) für z-index steuern. Hierbei treten folgende Änderungen auf: • Elemente mit einem negativen Wert für z-index werden entsprechend dieses Wertes im Stapel nach hinten, d.h. vom Betrachter weg, verschoben (Weiteres siehe unten). • Elemente mit dem z-index Wert Null oder auto werden gemäß ihrer Position im Quellcode angezeigt (Weiteres siehe unten). • Elemente mit einem positiven Wert für z-index werden entsprechend dieses Wertes im Stapel nach vorne verschoben. Allgemein werden Elemente mit dem gleichen Positionierungskontext und einem identischen Wert für z-index entsprechend ihrer Position im Quellcode angezeigt. Zuletzt definierte Elemente scheinen dem Betrachter am nächsten zu sein. Die wichtigste Einschränkung besteht darin, dass Elemente sich im gleichen Positionierungskontext befinden müssen, damit sie per z-index entlang der gedachten z-Achse verschoben werden können.
104
|
Kapitel 6: Lösungen für das CSS-Layout-Puzzle
Sollten Sie einmal ein Element vor einen benachbarten Float verschieben müssen, können Sie ihm eine höhere Position in der Stapelungsreihenfolge verschaffen, indem Sie es mit der Regel position: relative versehen.
Quellcode-Reihenfolge und präzises Layout für die Navigation Im Abschnitt »Stile für Navigationselemente« auf Seite 124 wird das Markup und die Gestaltung von Listen beschrieben. In mehreren Schritten wird gezeigt, wie Sie die primären Navigationselemente einer Site darstellen können. Details werden in Schritt 5 allerdings vermieden. Es wird nur gesagt, dass für das Layout von Navigationselementen ein Haufen Box- und Layouteigenschaften nötig ist. Alle Selektoren in diesem Abschnitt wurden absichtlich so allgemein wie möglich benannt.
Im Folgenden gehen wir davon aus, dass Sie die ersten vier Arbeitsschritte bereits ausgeführt haben. Die Liste sollte bereits angepasst sein, und die Listeneinträge sollten die Definition display: block besitzen. Kapitel 13 enthält ebenfalls eine detaillierte Betrachtung komplexer Seitenlayouts.
Die Liste ausrichten Drei Dinge haben Einfluss auf die Ausrichtung der Navigationsliste: • die allgemeine horizontale oder vertikale Orientierung • die An- oder Abwesenheit von Untereinträgen • die allgemeine Ausrichtung eventuell vorhandener Untereinträge Üblicherweise wird die primäre Navigation auf kommerziellen Websites horizontal ausgerichtet. Dies geht am besten mit Stylesheet-Regeln wie den folgenden, wobei Längenangaben nach Bedarf angepasst werden: #nav { display: block; height: 1.5em; overflow: hidden; } #nav li { width: 8.333em; float: left; overflow: hidden; }
Beachten Sie, dass #nav seinen Positionierungskontext von #hauptteil erhält, wodurch die Navigation im Quelltext nach dem Hauptinhalt stehen kann. Der Platz für #nav wird dadurch geschaffen, dass #hauptteil mit einem entsprechenden Innenabstand (padding)
Quellcode-Reihenfolge und präzises Layout für die Navigation
|
105
versehen wird. Dies wird durch den hellgrauen Leerraum verdeutlicht, der auf beiden Seiten zu sehen ist. Er wird gebraucht, um Rundungsunterschiede der verschiedenen Browser auszugleichen. Bringt die Verwendung von float aufgrund von Rundungsunterschieden oder Darstellungsfehlern im Internet Explorer nicht die gewünschten Ergebnisse, gibt es noch eine weitere Methode: Verwenden Sie für die umgebende Liste die Regel ul { position: relative; }, und steuern Sie dann die Positionierung der einzelnen Einträge mit der Regel li { position: absolute; } und den passenden Layout-Koordinaten. (Dies funktioniert nicht, wenn position: absolute bereits verwendet wurde, um die Platzierung in der Quellcode-Reihenfolge auszugleichen.) Die Bevorzugung von float: left gegenüber position: absolute für die Platzierung der Einträge in der Navigationsliste hat mit dem zuvor behandelten Stapelungskontext zu tun. Elemente mit ungewöhnlichen Stapelungseigenschaften können ungewollte Auswirkungen auf die Werte von position und z-index in anderen Teilen des Dokuments haben, was in der Testphase des Projekts zu Problemen führen kann. Bei Werbeeinblendungen von Drittanbietern oder von Inhalten, die ungeschulte Benutzer einem CMS hinzugefügt haben, können diese Schwierigkeiten sogar noch größer werden. Eine vertikal orientierte Navigation ist dagegen deutlich einfacher zu gestalten. Die größte Schwierigkeit liegt in der Behandlung von Listeneinträgen, die sich über mehrere Zeilen erstrecken. Die Anforderungen lassen sich allerdings verringern, wenn jedem Listeneintrag der primären Navigation möglichst ein eigenes id-Attribut zugewiesen wird. Während die horizontale Navigation durch die mögliche Höhe (height) beschränkt wird, findet eine vertikal orientierte Navigation ihre Grenzen in der Breite (width). Hier kann die Verwendung von float helfen, was zu einfacheren Regeln führt, wie hier gezeigt: #nav { display: block; width: 10em; overflow: hidden; } #nav li { height: 1.5em; overflow: hidden; }
Navigationslisten genau platzieren Typischerweise befindet sich die Liste mit den Navigationslinks an einer von zwei möglichen Stellen im Quellcode des Templates und an einer von zwei möglichen Positionen im Layout. Zudem ist wichtig, wie tief die Liste im Dokumentenbaum verschachtelt ist. Die ersten zwei hier gezeigten Szenarien gehen von folgender Seitenstruktur aus: 1. Wurzelelement des Dokuments A. Container für den Inhalt I. Kopfteil II. Primäre Navigation i. Einzelne Links a. Untereinträge III. Spalten für Inhalt 106
|
Kapitel 6: Lösungen für das CSS-Layout-Puzzle
IV. Fußteil i. Sekundäre Navigation a. Einzelne Links ii. Copyright-Vermerke etc. Die letzten beiden Szenarien gehen davon aus, dass 1.A.II und 1.A.III (die Spalten für die primäre Navigation und den Hauptinhalt) in der gerade gezeigten Quellcode-Reihenfolge vertauscht sind. Die sichtbare Position der primären Navigationslinks (im Layout) liegt bis auf ganz wenige Ausnahmen innerhalb oder in der Nähe des Kopfteils. Die Hauptfrage ist nur: Befinden sie sich in einer Spalte links vom Hauptinhalt (und wahrscheinlich über weiterem Inhalt) oder horizontal unterhalb des Kopfteils (und erstrecken sie sich dabei über mehrere Spalten)? Die Feinheiten des Layouts von Navigationslinks innerhalb der sie umgebenden Liste wurde im vorigen Abschnitt und in Kapitel 7 bereits behandelt. Hier geht es um die Frage, wie die Links auf der sichtbaren Seite platziert werden. Wie bei den übrigen in diesem Kapitel benutzten Beispielen gehen wir in Abbildung 6-12 davon aus, dass die Navigationsliste sich am Ende von #hauptteil befindet. Dieser Ansatz hat nicht nur Vorteile, aber er führt zu einer logischeren Quellcode-Reihenfolge der Inhalte gemäß ihrer Wichtigkeit. 1
2
3
4
Abbildung 6-12: Das schrittweise Layout einer vertikal orientierten Navigationsliste Quellcode-Reihenfolge und präzises Layout für die Navigation
|
107
Die Dinge werden komplizierter, wenn die Links wie in Abbildung 6-12 vertikal orientiert sind und an die linke Layout-Spalte angrenzen. Nehmen Sie Abbildung 6-12 als Orientierungshilfe, und stellen Sie sich die Standarddarstellung einer vertikal orientierten Liste an dieser Position im Quellcode vor. Dann gehen Sie im Kopf die folgenden Schritte durch: 1. Zurücksetzen der Liste durch list-style-type: none für die Liste und padding-left: 0 für die Listeneinträge 2. Setzen der gewünschten Box-Eigenschaften für die Listeneinträge und die Liste selbst. In unserem Beispiel erhält jeder Listeneintrag an allen vier Seiten etwas Innenabstand sowie an zwei Seiten eine Begrenzungslinie. Die Liste selbst bekommt ebenfalls an zwei Seiten eine Begrenzungslinie (entsprechend Abbildung 10-3, zu sehen in Kapitel 10). 3. Unter Verwendung des Positionierungskontextes von #hauptteil wird die Navigationsliste oberhalb der linken Spalte platziert. 4. Die linke Spalte erhält einen entsprechenden Wert für padding-top.
Layouttypen und Hilfslinien-Raster Bei der Erstellung eines Layouts sind zwei Dinge wichtig: die Breite des Layouts im Verhältnis zum Ansichtsbereich und zu den im Layout verwendeten Hilfslinien. Für die Verbindung der Layoutbreite und der Breite des Ansichtsbereichs gibt es drei gängige Methoden und zwei Ebenen, auf denen Layoutraster angewandt werden. Ihnen werden Warnungen über das Mischen von festen Längeneinheiten und Prozentwerten begegnen. Am häufigsten geht es dabei um Rahmen und abgerundete Ecken. Beides funktioniert deutlich besser, wenn statische Längeneinheiten verwendet werden. Das gilt auch, wenn Sie für Elemente die proportionalen Längenangaben besitzen.
Feste, proportionale und flexible Layouts Obwohl Webbrowser ständig weiterentwickelt werden, muss sich der Designer einer Website drei Fragen stellen, bevor er mit einem Layoutraster (wireframe) oder möglicherweise mit einem zusammengesetzten Layout arbeitet: • Wie viel Platz wird gebraucht, um die »Message« der Site zu kommunzieren? • Wie viel Platz bietet der Ansichtsbereich im Browser eines typischen Besuchers? • Ist es im Sinne des Besuchers, den gesamten Ansichtsbereich zu verwenden? Teilweise müssen diese Fragen im Kontext der einzelnen Bestandteile eines Site-Designs beantwortet werden: »Wie viel Platz brauche ich in x, und warum?« Da sich die Antworten je nach Projekt und Designer unterscheiden, gibt es keine allgemeingültigen Antworten. Es gibt allerdings eine Reihe von Designkonzepten, die die horizontale Anordnung in einem Layout beeinflussen: 108
|
Kapitel 6: Lösungen für das CSS-Layout-Puzzle
Schriftgrößen Da es eine ideale Anzahl von Wörtern pro Zeile gibt und die häufigsten Wörter einer Sprache bekannt sind, lässt sich folgern, dass schmalere Layouts sich besser mit kleinen Schriftgrößen vertragen; soll die Schrift größer sein, muss das Layout entsprechend breiter sein. Bildgrößen Besteht der Inhalt einer Site zu einem großen Teil aus Fotografien oder anderen Illustrationen, haben ihr Seitenverhältnis und ihre Größe einen großen Einfluss auf das Gesamtdesign der Site. Dies gilt besonders, weil diese Elemente in proportionalen Layouts aufgrund ihrer festen Größe nicht skalierbar sind. Leerraum und Kontrast Leerraum entsteht, wenn ein verhältnismäßig schmales Layout in einem breiten Browserfenster dargestellt wird. Davon abgesehen, wird Leerraum an verschiedenen Stellen im Layout benötigt (z.B. zwischen Textzeilen, vor und nach Absätzen etc.). Bereiche mit hohem Kontrast profitieren ebenfalls davon, wenn der Inhalt einen ausreichend hohen Innenabstand besitzt. Browserbeschränkungen Unerfahrenen Gestaltern werden bei der Implementierung proportionaler und flexibler Layouts erhebliche Darstellungsfehler begegnen. Die Drittelregel, der Goldene Schnitt und die Fibonacci-Folge Wenn Sie überlegen, wie groß der Platz »über dem Knick« für Ihre Startseite oder den Abschnitt einer Seite sein muss, können Sie sich auf diese allgegenwärtigen Zahlenfolgen verlassen, um die Breiten für Spalten und andere Elemente festzulegen. Die Eigenheiten, Vor- und Nachteile der drei grundsätzlichen Layouttypen finden Sie in Tabelle 6-3. Tabelle 6-3: Layouttypen mit ihren Eigenheiten, Vor- und Nachteilen Layouttyp
Eigenheiten
Fest (»fixed«)
Sämtliche Layoutelemente, möglicherweise auch die Spalten, werden in Pixeln (px) definiert.
Vorteile
Nachteile
•
Einfachste Handhabung für Zwischenräume, Begrenzungslinien und detaillierte Hervorhebungen
•
Geringste Anfälligkeit für Darstellungsfehler von Browsern
•
Am besten geeignet für Sites mit vielen Bildern
•
Am schlechtesten zugänglich für Benutzer mit Sehproblemen
•
Am empfindlichsten für das »Überlaufen« von Text in andere Elemente
Layouttypen und Hilfslinien-Raster
|
109
Tabelle 6-3: Layouttypen mit ihren Eigenheiten, Vor- und Nachteilen (Fortsetzung) Layouttyp
Eigenheiten
Proportional
Die meisten oder alle Layoutelemente werden mit Prozentwerten definiert.
Flexibel
Die meisten oder alle Layoutelemente werden mit em-Einheiten definiert.
Vorteile •
Das Layout bleibt unabhängig von der Größe des Ansichtsbereichs konsistent.
•
Am zugänglichsten für Benutzer mit Sehproblemen
•
Bietet den besten Kompromiss zwischen Zugänglichkeit und Lesbarkeit; geringe Probleme bei veränderten Textgrößen.
•
Essenziell für eine erfolgreiche Nutzung von Layoutrastern
•
Wenig oder kein Bedarf für das Mischen von Längeneinheiten; alle Angaben können in em-Einheiten gemacht werden, ohne dass der Inhalt in andere Elemente »überläuft«.
Nachteile •
Floats sind schwer zu handhaben, wenn für Zwischenräume und Rahmen feste Längeneinheiten verwendet werden.
•
Einschränkungen der Lesbarkeit durch zu lange Zeilen in breiten Browserfenstern
•
Der Gestalter muss viele Umrechnungen von Brüchen zu Dezimalwerten und multiplikative Berechnungen von Schriftgrößen vornehmen.
•
Die Darstellung leidet bei schmalem Ansichtsbereich und Schriftgrößen, die mit mehr als 12 Pixeln (oder einem entsprechenden Wert) berechnet werden.
In der Praxis wird Ihre Entscheidung über Layoutbreite und Schriftgröße davon abhängen, mit welcher Größe des Ansichtsbereichs und welcher Bildschirmauflösung die meisten Besucher Ihre Site betrachten. Beim Schreiben dieses Buches lag der kleinste gemeinsame Nenner ungefähr bei 1024 × 768 Pixeln in der Vollbilddarstellung. Der kleinste mögliche Ansichtsbereich hat dabei etwa eine Größe von 1000 × 600 Pixeln (im Internet Explorer 7 mit diversen Tabs und zusätzlichen Werkzeugleisten). Die meisten Layouts werden außerdem zentriert, um auch größeren Browserfenstern auf größeren Bildschirmen zu genügen, wie das 1280 × 800 Pixel große Fenster, das ich bei einer Bildschirmauflösung von 1680 × 1050 Pixeln benutze. Hat Ihre Site besonders weit gesteckte Ziele (und das passende Publikum), wollen Sie vielleicht auch eine Auflösung von 800 × 600 berücksichtigen. Dafür gibt es zwei Möglichkeiten: • Verringern Sie die Breite Ihres Layouts, so dass es auf einen Bildschirm mit der Auflösung von 800 × 600 passt, aber vergessen Sie nicht die Anpassungen für eine ideale Zeilenlänge. • Bleiben Sie bei 1024 × 768 als kleinstem gemeinsamen Nenner für die Größe des Browserfensters. Passen Sie aber die Spaltenbreiten so an, dass der Hauptinhalt der Seite auch bei einer Auflösung von 800 × 600 Pixeln noch ohne horizontales Scrollen zu lesen ist.
110
|
Kapitel 6: Lösungen für das CSS-Layout-Puzzle
Die beste »Arme-Leute-Lösung« zum Testen von Layouts in verschiedenen Fenstergrößen bietet die Web Developer Toolbar, eine Firefox-Erweiterung. Über einen Dialog können Sie verschiedene eigene Fenstergrößen definieren, zwischen denen Sie dann über ein Menü wechseln können. Experten für Accessibility und Usability empfehlen allerdings, die Bildschirmauflösungen direkt am Monitor umzustellen. Die Unterschiede zwischen verschiedenen Monitoren und Auflösungen sind einfach zu zahlreich (siehe dazu Tabelle 3-3 in Kapitel 3).
Hilfslinien definieren Konsistenz wird oft als die höchste Tugend im Grafikdesign betrachtet, und das Web bietet wenig Ausreden, dem nicht zu folgen. Tatsächlich fördert die Natur der Kaskade an sich (siehe im Abschnitt »Taxonomie auf die Kaskade anwenden« auf Seite 70) Konsistenz in hohem Maße. Umkehrt sind Raster zum Erreichen der Konsistenz eine große Hilfe. Raster werden auf allen Ebenen des Designs einer Website verwendet, besonders bei den Details, aber auch auf Seiten- und Template-Ebene. Ein feines Netz aus Hilfslinien bildet ein Raster kleiner, gleich großer Rechtecke, manchmal sind es auch Quadrate. Viele Designprogramme, insbesondere Photoshop, bieten Unterstützung für diese Hilfslinien. In Photoshop können Sie die Hilfslinien durch den Menübefehl Ansicht → Einblenden → Hilfslinien (bzw. per Strg/Befehlstaste-Komma) aktivieren. Diese Hilfslinien können und sollten beispielsweise die Entfernung zwischen Text und Spaltengrenzen anzeigen. Hilfslinien für die gesamte Seite haben untereinander größere Unterschiede, sind aber nicht weniger konsistent. Das Layoutraster für eine Seite definiert beispielsweise die Spaltenbreiten, legt eine bevorzugte Höhe für Inhaltsblöcke fest und definiert, unter welchen Umständen die Eigenschaft clear benutzt werden sollte. Die Alternative zu einem Raster – den Inhalt in eine oder mehrere Spalten zu stopfen, ohne auf die benötigte Höhe zu achten, die Seitenabschnitte mit unterschiedlichen Spaltenbreiten zu versehen und die Konsistenz bezüglich der Bestandteile wie Bilder oder Überschriften zu vermeiden – ergibt einen visuellen Flickenteppich (siehe Abbildung 6-13). Hier sehen Sie die Website von Weather Channel und Weather Underground etwa zur gleichen Zeit. (Beachten Sie das Durcheinander zwischen den Hilfslinien in der Darstellung bei Weather Underground oben in der Abbildung). Keines der beiden Layouts würde einen großen Blumentopf gewinnen. Immerhin ist auf der Website des Weather Channel selbst für den einfachen Besucher zu erkennen, dass zumindest jemand versucht hat, sich an den Hilfslinien zu orientieren. Nicht so bei Weather Underground. Der Inhalt der Site wird auch hier auf drei Spalten verteilt, allerdings mit deutlich weniger Rücksicht auf die y-Achse des Seitenlayouts. Auf beiden Seiten gibt es bergeweise Werbung im Seiteninhalt und dem Fußteil. Der Unterschied ist auch hier deutlich sichtbar: Beim Weather Channel wird die Hauptspalte
Layouttypen und Hilfslinien-Raster
|
111
unterteilt, um die Textanzeigen zu positionieren, während bei Weather Underground aus dem gleichen Grund der gesamte Inhaltsbereich unterteilt wird.
Abbildung 6-13: Zwei ähnliche Websites mit überlagerten Hilfslinien
Die größten sichtbaren Probleme haben offenbar mit Werbeanzeigen zu tun, denen zu viel Platz eingeräumt wird. Daher gilt: Wenn Sie auf Ihrer Site Werbung schalten wollen, sollten Sie dies von Anfang an im Design berücksichtigen.
Da es schwierig ist, die Höhe eines Inhaltsblocks vorherzusagen, muss besonders die vertikale Aufteilung mit besonderer Disziplin und Planung durchgeführt werden. Sind für ein Seitenlayout genaue Höhenangaben unabdingbar, sollten Sie überlegen, ggf. die Regel overflow: hidden zu verwenden.
112
|
Kapitel 6: Lösungen für das CSS-Layout-Puzzle
Die Drittelregel, der Goldene Schnitt und die Fibonacci-Folge Die einander ähnlichen Konzepte der Drittelregel, des Goldenen Schnitts und der Fibonacci-Folge sind für das Seitenlayout besonders wichtig. Hierbei ist die Drittelregel am einfachsten zu verstehen und zu berechnen. Der Ansichtsbereich wird horizontal und vertikal in jeweils drei gleich große Bereiche unterteilt. Der Betrachter konzentriert seine Aufmerksamkeit i.d.R. auf die vier Schnittpunkte der gedachten Hilfslinien. Der Goldene Schnitt, oder mathematisch o|, ist eine Konstante mit dem ungefähren Wert 1,618034. Die Berechnungsregel lautet: b verhält sich zu a wie a zur Gesamtlänge a + b. Die Fibonacci-Zahlenfolge erhält man, indem man den aktuellen Wert zu dem vorangehenden addiert. Mathematisch heißt das: xn + x(n + 1) = x(n + 2), sofern man davon ausgeht, dass der niedrigste mögliche Wert von x(n + 2) 1 ist. Beginnt man mit der zweiten Instanz von 1, lauten die ersten Zahlen der Sequenz 1, 2, 3, 5, 8, 13, 21, 34, 55 und 89. Die Drittelregel ergibt ein Verhältnis von 3:3, was eine sehr grobe Annäherung an den Goldenen Schnitt ist. Gleichzeitig ist dies das Verhältnis, zu dem die aufeinander folgenden Fibonacci-Zahlen tendieren. In Abbildung 6-14 sehen Sie eine grafische Darstellung der Drittelregel und der FibonacciFolge. Die hierdurch entstehenden Hilfslinien sind ein ausgezeichneter Startpunkt für eigene Layoutraster. Dies gilt besonders für die Ermittlung von Spaltenbreiten und der Höhe für den Kopf- und den Fußteil im Verhältnis zum Ansichtsbereich.
Abbildung 6-14: Von der Fibonacci-Folge und der Drittelregel inspirierte Layoutraster
Layouttypen und Hilfslinien-Raster
|
113
Implementierung eines flexiblen Layoutrasters Ein Teil der für CSS 3 geplanten Standards besteht in der Definition von kleinsten Einheiten für ein Layoutraster. Einen Link zum Entwurf für die entsprechende Spezifikation finden Sie auf der Website zu diesem Buch.
Die meisten »Feinraster« für Seitenlayouts folgen einer einfachen Regel: Die Zeilenhöhe im Raster entspricht einer Textzeile inklusive dem »Durchschuss« (Zeilenabstand). Zum Beispiel: body { ... font-size: 14px; line-height: 1.714em; ... }
Hierbei gehe ich davon aus, dass die Zeilen (Text + Durchschuss) jeweils eine Höhe von 24 Pixeln haben, es sei denn, die Seite wird irgendwie gezoomt. Selbst wenn der Benutzer den Textzoom verwendet, bleibt der Zeilendurchschuss im Verhältnis zur Textgröße konstant. Der Textzoom wird hier erwähnt, weil er die Zugänglichkeit deutlich erhöhen kann und weil er Layouts, die sich nicht streng an em-Einheiten und einem Raster orientieren, komplett zerschießen kann. Einen Überblick über die Browserunterstützung für das Zoomen finden Sie in Tabelle 6-4. Tabelle 6-4: Überblick über die Unterstützung des Zoomens der verschiedenen Browser Zoom-Typ
IE 8
IE 7
IE 63
Firefox 3
Firefox 2
Safari 4
Safari 3
Textzoom
✓
✓
✓
✓
✓
✓
✓
Seitenzoom
✓
✓
nicht anwendbar
✓
nicht anwendbar
✓
nicht anwendbar
Für die »atomare« Spaltenbreite kann ein beliebiger Wert verwendet werden. Spaltenbreiten, die Quadrate ergeben, scheinen logisch, ergeben aber nicht immer eine angenehme Breite für die Spaltenzwischenräume. Weitere Kandidaten sind: • die Zeilenhöhe, geteilt durch (oder multipliziert mit) o| • 1em oder ein Vielfaches davon • die Breite eines »normalen« Worts in der Standardschrift der Website Auch bei der Implementierung des Feinrasters ist Konsistenz die Hauptsache. Die Spaltenbreiten und andere Linien des Layoutrasters für die Seite sollten sich an den Linien des Feinrasters orientieren. Wollen Sie ein flexibles Layout erstellen, sollten alle Werte in em-Einheiten angegeben werden. Angenommen, ich verwende die Fibonacci-Folge als Grundlage für ein zweispaltiges Layout auf einem quadratischen Raster. Dann erhalte ich vor dem Einfügen von Zwischenräumen und Außenabständen die folgenden Proportionen:
3 Nicht unterstützt für Text, der seinen Wert für font-size von einem in Pixeln (px) angegebenen Wert erbt.
114
|
Kapitel 6: Lösungen für das CSS-Layout-Puzzle
Höhe von Kopf- und Fußteil
8x
Breite der Seitenleiste
13x
Breite für den Hauptinhalt
21x
Wahrscheinliche Breite für eingebettete Fotos
8x
Wahrscheinliche Größe für Überschriften (inkl. Durchschuss)
3x und/oder 5x
Die Aufgabe besteht hierbei darin, den Wert für x zu ermitteln. Als Ausgangspunkt kann man beispielsweise das Verhältnis der Breite für den Haupttext zur Breite der Seitenleiste nehmen. Die Zeilenlänge soll möglichst am unteren Ende des optimalen Bereichs liegen, sagen wir: 12 Wörter. Das entspricht in vielen Schriften ungefähr 36 em. Daraus ergibt sich ein Wert für x von 0,618 em-Einheiten (.618em). Da eine Zeilenhöhe von 0,618 em-Einheiten nicht besonders praktikabel ist, verdopple ich diesen Faktor und erhalte so einen line-height-Wert von 1.235em (was dem Standardwert für viele Schriften ziemlich nahe kommt). Verwende ich den folgenden Wert in der Fibonacci-Folge,komme ich auf 1.853em, was aber wahrscheinlich schon zu groß ist. Alternativ dazu kann ich auch die Verhältnisse meines Layouts betrachten und dieses durch die Breite des Ansichtsbereichs dividieren (ein Verhältnis von 13:21 von der Seitenleiste zum Haupttext ergibt einen Gesamtwert von 34 Einheiten). Das Ergebnis dieser Berechnung entspricht dem Abstand zweier Linien in meinem Feinraster. Er liegt irgendwo zwischen 28 und 30 Pixeln, was eine größere Schrift auf kürzeren Zeilen nahelegt. Unabhängig vom gewählten Wert kann ich das Ergebnis leicht in meinem Stylesheet festlegen. Hierfür verwende ich eine bestimmte Rasterweite und weise jeder wichtigen Klasse für den Site-Inhalt mithilfe der entsprechenden Selektoren die entsprechenden Werte zu.
Layouttypen und Hilfslinien-Raster
|
115
KAPITEL 7
Listen
Listen gibt es überall: Checklisten, Einkaufslisten, To-do-Listen, Besten- und Letztenlisten und einfachen Rangfolgen begegnet man jeden Tag. Auch im Web-Markup lassen sich Listen relativ einfach finden. Sie werden für alle mögliche Dinge verwendet, oft auch für die Navigation. HTML unterstützt drei Arten von Listen: geordnete Listen (ol), ungeordnete Listen (ul) und Definitionslisten (dl).
Geordnete und ungeordnete Listen Der Hauptunterschied zwischen geordneten und ungeordneten Listen besteht in ihrer Semantik: Gelegentlich haben die Listeneinträge eine gewisse Rangfolge (z.B. Wichtigkeit, Abfolge der Ausführung, Zeitpunkt der Hinzufügung, alphabetische Reihenfolge etc.), und manchmal enthält eine Liste einfach nur Daten, die irgendetwas gemeinsam haben.
Browser-Standarddarstellung für geordnete und ungeordnete Listen Auf den ersten Blick sehen Listen ohne Stildefinitionen aus wie einfache Blockelemente (was sie auch sind), die eine Reihe weiterer Blockelemente enthalten. Tatsächlich haben die Listeneinträge aber eine eigene Darstellungsrolle: list-item. Sie wird ein Stück nach rechts von der linken Außenkante der Liste verschoben dargestellt. Aktuelle Benutzerprogramme verwenden teilweise andere Stilregeln für die Standarddarstellung von Listen als ihre Vorgängerversionen, wie Sie in Tabelle 7-1 sehen. Beachten Sie die 40px-Werte. Sie haben zur Folge, dass Listenmarker bei besonders großer Schrift in einer langen geordneten Liste teilweise am linken Rand verborgen werden. Das lässt sich durch Erhöhen der Werte für margin-left und padding-left und die Verwendung von em-Einheiten anstelle von Pixelwerten (px) vermeiden. Eine Testsuite zum Ermitteln des Layoutverhaltens von Listen finden Sie auf der Website zu diesem Buch (www.htmlcssgoodparts.net).
|
117
Tabelle 7-1: Browser-Stilregeln für die Standarddarstellung von geordneten (ol), ungeordneten (ul) und Definitionslisten Benutzerprogramm •
Firefox 2+
•
Internet Explorer 7+
•
Safari 3+
•
Firefox 1.0.x–1.4.x
•
Internet Explorer 6
•
»Quirks«-Darstellungsmodus
Standard-Stilregeln margin: 1em auto 1em 0; padding-left: 40px;
margin: 1em auto 1em 40px;
Gültige geordnete und ungeordnete Listen erstellen Die Erstellung gültiger Listen ist nicht einfach. Daher haben wir hier eine Reihe von Regeln zusammengestellt, die Ihnen dabei helfen sollen: • Eine Liste muss mindestens einen Eintrag enthalten. • Eine Liste kann nur Listeneinträge (li) enthalten. • Das Elternelement eines Listeneintrags muss immer eine Liste sein. • Sämtliche erlaubten Kindelemente von div-Elementen können auch als Kindelemente von Listeneinträgen verwendet werden. • HTML 4.01 erlaubt die Definition von Listeneinträgen ohne schließende Tags. • Die Attribute start (für ol) und value (für li-Elemente innerhalb von ol) sowie type (für beide) sind nur für Dokumente vom Typ Transitional erlaubt, nicht aber für Dokumente vom Typ Strict. • Der Zähler wird für ol-Listeneinträge mit dem display-Wert none nicht inkrementiert.
Die Eigenschaft »list-style-type« und das Attribut »type« Für die Aufzählungszeichen einer geordneten Liste steht eine große Zahl von Zeichen zur Auswahl. Standardmäßig werden Dezimalzahlen verwendet; Buchstaben und römische Zahlen (beide in Groß- und Kleinschreibung) sind aber ebenfalls möglich. Für ungeordnete Listen gibt es drei Arten von Aufzählungszeichen: Punkte, Kreise und Quadrate. Gut unterstützte Werte für die Eigenschaft list-style-type finden Sie in der unten stehenden Liste. Da das Attribut type offiziell als veraltet gilt, werden die entsprechenden Werte hier nur der Vollständigkeit halber angegeben. • circle (type="circle") • disc (type="disc") [Standard für nicht verschachtelte ungeordnete Listen]
118
|
Kapitel 7: Listen
• square (type="square") • decimal (type="1") [Standard für geordnete Listen] • upper-alpha (type="A") [A,B,C,D,…] • lower-alpha (type="a") [a,b,c,d,…] • upper-roman (type="I") [I,II,III,IV,V,…] • lower-roman (type="i") [i,ii,iii, iv,v,…] • none Der Wert none taucht häufig auf, weil für die Navigation einer Website nur selten Listenmarker verwendet werden – besonders wenn eine Technik zur Bildersetzung (siehe im Abschnitt »Grafische Schriften und das Fahrner Image Replacement« auf Seite 162) verwendet wird. Begrenzte Unterstützung gibt es außerdem für die Eigenschaft list-style-image. Hiermit kann anstelle des vom Browser erzeugten Aufzählungszeichens eine eigene Grafik verwendet werden. Allerdings sind die Resultate bei der Verwendung dieser Eigenschaft so gut wie immer enttäuschend. Eigene Aufzählungszeichen lassen sich deutlich besser durch die Verwendung von background-image und background-repeat definieren, wie in Kapitel 9 besprochen wird. Weitere in CSS 2.1 definierte Werte für list-style-type sind lower-latin, upper-latin, lower-greek und upper-greek. Diese werden aber nicht von allen Browsern unterstützt.
Das »nav«-Element (HTML 5) In HTML 5 gibt es eine Reihe neuer Elemente, mit denen die Struktur von HTMLDokumenten verfeinert werden kann. Das wichtigste dieser Elemente ist mit Sicherheit nav. Andere vorgeschlagene Elemente wie z.B. section können für Seitenautoren sehr nützlich sein, haben aber nur geringe Auswirkungen auf den Benutzer. Das nav-Element ist da schon etwas anderes. Hiermit können Sie Inhalte als »Navigation« kennzeichnen, die vom Benutzerprogramm erkannt und ggf. entsprechend behandelt werden. Browser können das nav-Element also dazu verwenden, die Benutzerfreundlichkeit deutlich zu erhöhen. Navigationsinhalte – sprich: die Listen mit Hyperlinks zu den einzelnen Seiten einer Website oder -applikation – können an verschiedenen Stellen einer Seite oder Applikation auftauchen. Sie werden verwendet, um zu verschiedenen Teilen einer Website, Webapplikation oder zu Abschnitten innerhalb einer Seite zu springen. In einem mehrspaltigen Layout könnten Sie die primäre Navigation beispielsweise in der am weitesten links gelegenen Spalte platzieren, während die sekundäre Navigation sich ganz rechts befindet. Bei einem anderen Design befindet sich die primäre Navigation vielleicht als Menü mit aufklappbaren Untereinträgen am Anfang der Seite, während die sekundäre Navigation vielleicht im Fußteil der Seite zu finden ist. Ohne das nav-Element würden Sie die Navigationselemente sehr wahrscheinlich mit einem div-Element umgeben, das ein passendes class-Attribut trägt. Tatsächlich ist nav Geordnete und ungeordnete Listen
|
119
einer der 20 am häufigsten im Web verwendeten Werte für class überhaupt. Manche Sites verwenden außerdem Werte wie nav1 (primäre Navigation) oder nav2 (sekundäre Navigation), um die verschiedenen Arten von Navigationsinhalten genauer zu unterscheiden. Das Problem bei der ausschließlichen Verwendung von class-Werten für die Kennzeichnung von Navigationsinhalten besteht darin, dass es keine standardisierte, Websiteübergreifende Benennung für diese Elemente gibt. Das nav-Element löst dieses Problem, indem es ein Standardelement bereitstellt, das alle Webautoren für den gleichen Zweck verwenden können. Zudem trägt das nav-Element zur Lösung eines weiteren Dilemmas vieler Autoren bei: Es nimmt ihnen die Entscheidung darüber ab, an welcher Position in der Quellcode-Reihenfolge des Dokuments die Navigationsinhalte platziert werden sollen, ohne dass die Zugänglichkeit negativ beeinflusst wird oder die Benutzbarkeit auf Mobilgeräten mit sehr kleinem Bildschirm eingeschränkt wird.
Überlegungen zu Zugänglichkeit und Usability Bei der Platzierung der Navigationsinhalte in der Quellcode-Reihenfolge sollten Sie einige Punkte bezüglich der Zugänglichkeit bedenken. Zum Beispiel: 1. Es ist eine häufige Sorge, dass die Zugänglichkeit einer Site für Benutzer von Hilfsgeräten (Bildschirmlesegeräten, Braille-Zeilen etc.) leidet, wenn die primäre Navigation am Anfang der Quellcode-Reihenfolge eines Dokuments definiert wird. Es wird befürchtet, dass Benutzer, die die primäre Navigation am Anfang des Dokuments erwarten, sie an anderer Stelle nur schwer finden können. 2. Paradoxerweise gibt es eine gegensätzliche Sorge, dass der Inhalt weniger zugänglich wird, wenn Sie die primäre Navigation am Anfang der Quellcode-Reihenfolge des Dokuments definieren. Das Grund ist, dass sich die Benutzer von Hilfstechnologien auf jeder Seite erst durch die gleiche lange Liste mit Navigationslinks graben müssen, um an den eigentlichen Inhalt zu kommen. Das kann frustrierend und sehr zeitaufwendig sein. 3. Eng verwandt mit dem zweiten Anliegen ist die Frage der Usability in Browsern auf den kleinen Bildschirmen von Mobilgeräten. Eine Reihe mobiler Browser besitzt eigene Möglichkeiten, um die Inhalte in einer einzigen Spalte darzustellen und so auf kleinen Bildschirmen leichter lesbar zu machen. Diese Reformatierung basiert oft auf der Quellcode-Reihenfolge des Inhalts. Befindet sich die primäre Navigation im Quellcode am Anfang des Dokuments, haben diese Browser das gleiche Problem wie die Benutzer von Hilfsgeräten. Die Besucher müssen sich auf jeder Seite zuerst durch eine lange Navigationsliste scrollen, um an den Hauptinhalt zu kommen. In der Praxis umgehen Autoren das zweite und dritte Problem oft, indem sie einen »Direkt zum Hauptinhalt«-Link vor der primären Navigation einfügen. Das hilft zwar, ist aber eigentlich nur ein Hack, weil es vor HTML 5 keine Standardmethode gab, mit der Bildschirmleseprogramme oder Mobilbrowser (ohne heuristische Methoden) die Navigation vom Hauptinhalt unterscheiden konnten.
120
|
Kapitel 7: Listen
Browsern ermöglichen, die Navigation auf andere Weise anzuzeigen Durch das nav-Element in HTML 5 verfügen Browser nun über ein Standardelement, das Navigationselemente eindeutig kennzeichnet. Hierdurch ist es möglich, die Navigation für den Benutzer mit einer eigenen Darstellung zu versehen. Im aktuellen Entwurf der HTML 5-Spezifikation heißt es dazu: Benutzerprogramme (z.B. Bildschirmleseprogramme) für Benutzer, für die das Weglassen von Navigationsinformationen vorteilhaft ist oder denen es hilft, wenn Navigationsinformationen sofort zur Verfügung stehen, können dieses Element verwenden, um zu ermitteln, welche Inhalte einer Seite übersprungen oder nur auf Anforderung dargestellt werden sollen.
Dabei ist das nav-Element nicht nur für Bildschirmleseprogramme vorteilhaft. Auch Browser auf kleinen Mobilgeräten profitieren davon. Solche Geräte können den Inhalt von nav-Elementen beispielsweise durch ein spezielles Softkey-Menü zugänglich machen, anstatt ihn innerhalb des Hauptinhalts einer Seite darzustellen. Natürlich ist die ganze Nützlichkeit des nav-Elements nur ein frommer Wunsch, solange Hilfsgeräte und -programme, Browser auf Mobilgeräten und andere Benutzerprogramme mit diesem Element noch gar nichts anfangen können.
Die Zählweise in geordneten Listen anpassen Angenommen, wir haben die folgende geordnete Liste:
Kürzere Wellenlängen 1. Blau 2. Indigo 3. Violett Der Quellcode für diese Listen sieht wie folgt aus: La ¨ngere Wellenla ¨ngen
Rot
Orange
Gelb
Gru¨n
Ku ¨ngen ¨rzere Wellenla
Blau
Geordnete und ungeordnete Listen
|
121
Indigo
Violett
Die Beziehung beider Listen sollte klar sein, genau wie ihr Layout. Allerdings sollten Sie das Attribut start im Quellcode-Beispiel nicht übersehen. Die hier gezeigte Implementierung validiert nur bei Verwendung eines Transitional-Dokumenttyps. Leider besteht die einzige verlässliche Methode, um die Zählung einer Liste zu unterbrechen und in einer folgenden Liste fortzuführen, in der Verwendung der veralteten HTML 4-Attribute start und value. Mit dem Attribut start können Sie einen Startwert für die Zählung festlegen, während value (definiert für li) dem Aufzählungszeichen einen Wert zuweist, ab dem die folgenden Listeneinträge weitergezählt werden. Eine Zählfunktion wird auch durch CSS 2.1 implementiert. Allerdings ist sie schwer zu verstehen und kann nur über das Pseudoelement :before aktiviert werden. Hierdurch wird leider verhindert, dass Inhalt und Aufzählungszeichen an einem gemeinsamen Rand ausgerichtet werden können. Außerdem wird diese Zähler-Implementierung vom Internet Explorer noch nicht unterstützt. Um die Folge der Aufzählungszeichen an einer beliebigen Stelle zu beginnen, weisen Sie entweder der Liste das Attribut start oder dem ersten Listeneintrag das Attribut value zu. Unabhängig vom Wert für list-style-type (dieser wird beibehalten) muss für start bzw. value ein numerischer Wert (1,2,3 etc.) angegeben werden.
Andere Verwendungen für Listen Für Listen gibt zwei offensichtliche Anwendungen: Gliederungen und Aufzählungen.
Gliederungen In ihrer einfachsten Form ist eine HTML-Gliederung nichts weiter als eine Folge korrekt verschachtelter geordneter Listen, z.B. mit folgenden Stildefinitionen: ol ol ol ol ol ol ol ol ol ol
Die Gliederungsebenen 6 bis 10 wiederholen diese Folge bei Bedarf, wobei die Schrift neben der Standardeinrückung vermutlich weniger betont werden sollte (z.B., indem sie kleiner oder heller dargestellt wird).
Aufzählungen Selten, aber nicht unbekannt ist die Verwendung von Kommas, um mehrere Listeneinträge voneinander zu trennen. Für diese Methode gibt es in Webdokumenten mehrere
122
|
Kapitel 7: Listen
Gründe. Meistens geht um Platzersparnis. Ebenso wahrscheinlich ist es, dass Ihr Chef darauf besteht, die Liste in dieser Form darzustellen. Um eine solche Liste zu implementieren, umgeben Sie den betreffenden Absatz mit einem div-Element, das ein class-Attribut Ihrer Wahl trägt. Dann teilen Sie den Absatz an der Stelle auf, an der die Liste stehen soll. Sie erhalten zwei Absätze, die von einer Liste getrennt werden. Dann verwenden Sie folgende Stilregeln: .liste p, .liste ul, .liste li { display: inline; } .liste ul { list-style-type: none; padding-left:0; }
Endet der Inhalt jedes Listeneintrags korrekt mit einem Komma (oder mit dem abschließenden »und«), sollte das Ergebnis strengen redaktionellen wie auch semantischen Anforderungen genügen. Das scheinbar überflüssige div ist beabsichtigt. Schließlich handelt es sich ja eigentlich immer noch um einen Absatz.
Das Layout für Links im Fußteil anpassen Das Verhalten von inline-block haben wir bereits in Kapitel 6 besprochen. Es kann besonders bei der Arbeit mit Links im Fußteil hilfreich sein. Anstatt mit float-basierten Lösungen zu experimentieren, können Sie das Ziel mit den folgenden Regeln viel einfacher erreichen: #fussteil ul { list-style-type: none; text-align: center; } #fussteil li { display: inline-block; }
Wollen Sie eigene Aufzählungszeichen für die Links im Fußteil verwenden, können Sie den Wert für padding-left für die Listeneinträge entsprechend anpassen und bei Bedarf ein eigenes Hintergrundbild definieren.
Aufzählungszeichen als Hintergrundbild? Sie haben richtig gelesen. Um eigene Aufzählungszeichen zu definieren, wird die CSSEigenschaft list-style-image einfach ignoriert. Eigentlich ist sie gerade für die Definition eigener Aufzählungszeichen gedacht, sie hat aber eine Reihe von Nachteilen. Das erste Problem besteht darin, dass das Bild für list-style-image prinzipiell auf der Grundlinie dargestellt wird. Der Gestalter muss die Grafik in seinem Bildbearbeitungsprogramm also pixelgenau erstellen – eine Anforderung, die das Ziel der Trennung von Inhalt und Darstellung rundheraus übergeht. Der zweite Nachteil ist eine Folge des ersten: Wenn der Besucher nur den Text der Seite zoomt, behalten die Aufzählungszeichen ihre ursprüngliche Größe. Der dritte Nachteil besteht darin, dass der Gestalter bei der Verwendung von list-styleimage keine Sprites verwenden kann, wie es mit den background-Eigenschaften möglich wäre, wenn auch nicht ohne gewisse Gefahren.
Andere Verwendungen für Listen
|
123
Stile für Navigationselemente In diesem Abschnitt verwenden wir den Begriff »nav« sowohl für die Liste, die die Listeneinträge mit den primären Navigationslinks enthält, als auch für das entsprechende Designelement, das letztendlich auf der fertigen Website zu sehen ist. Die primäre Navigation kann entweder vertikal oder horizontal gestaltet werden. Im zweiten Fall werden die Elemente mithilfe von float von links nach rechts angeordnet, während sie im ersten Fall in einer Spalte übereinander erscheinen. Die übrigen Schritte bei der Gestaltung des Navigationsbereichs sind in beiden Fällen recht ähnlich.
Platzierung der primären Navigation in der Quellcode-Reihenfolge Die erste Frage, die man sich stellen muss, lautet: An welcher Stelle soll die Navigation im Quellcode des Templates stehen? Bei der Beantwortung dieser Frage gibt es einige Dinge zu bedenken: Benutzer von Hilfsgeräten und -programmen erwarten, dass die Navigation möglichst früh in der Quellcode-Reihenfolge erscheint. Diese Erwartungshaltung ist ein Relikt der Designtrends und -werkzeuge aus den Neunzigerjahren. In dieser Zeit stand die Navigation fast immer an zweiter Stelle in der Quellcode-Reihenfolge (nach dem Kopfteil der Seite). Gleichzeitig gehen Sie etwas respektvoller mit der Zeit von Benutzern von Hilfstechnologien um, wenn der Hauptinhalt möglichst früh im Quelltext auftaucht. Der Bedarf an diesem Vorgehen wird durch Funktionen zum Überspringen von Listen und Erwartungen seitens der Benutzer abgeschwächt. Er sollte aber nicht ignoriert werden. Die spätere Platzierung der Navigationselemente kann außerdem gewisse Vorteile für die Suchmaschinenoptimierung (SEO) haben. Die Platzierung der Navigation am Seitenanfang ermöglicht die Verwendung einfacherer Stildefinitionen (in gewissem Maße). Wenn Sie die Navigation erst gegen Ende der Quellcode-Reihenfolge einer Seite definieren, müssen Sie sich mit ziemlicher Sicherheit auf den Positionierungskontext verlassen, damit die Navigation an der gewünschten Stelle dargestellt wird. Die Komplexität des Stylesheets nimmt zu. Die Navigation lässt sich leichter warten, wenn sie aus einer eigenen Datei eingebunden wird. Außerdem muss bei einem gut erstellten Template eine Datei weniger inkludiert werden. Das ist bei den meisten Websites keine große Sache. Bei Websites mit vielen Besuchern kann aber selbst eine eingesparte Include-Datei schon die Performance erhöhen.
124
|
Kapitel 7: Listen
Rezept für die primäre Navigation Sobald Sie die Darstellung für Ihre primäre Navigation definiert und sich für einen Platz in der Quellcode-Reihenfolge entschieden haben, können Sie sie in das Layout Ihrer Site integrieren: 1. Versehen Sie die Navigation und ihre Bestandteile mit id-Attributen. Hinweise zur Benennung der id-Attribute finden Sie im Abschnitt »Taxonomie auf die Kaskade anwenden« auf Seite 70. 2. Setzen Sie vom Benutzerprogramm definierte Stile für die Navigation und ihre Bestandteile zurück. Hierfür reicht es meistens schon, etwas wie { margin: 0; padding: 0; list-style-type: none; } in Ihr Stylesheet einzufügen. 3. Platzieren Sie die Navigationsliste im Layout. Die hierfür nötigen Schritte sind davon abhängig, ob es sich um eine horizontale oder vertikale Navigation handelt, wo im Quellcode sie definiert wurde und welche Position sie im Layout einnehmen soll. Am geringsten ist die Gefahr von Fehlern, wenn Sie die Navigation innerhalb des Hauptinhalts definieren. Dieser wird relativ positioniert. Die Navigation selbst kann nun innerhalb der Grenzen des Hauptinhalts absolut positioniert werden. 4. Versehen Sie die Listeneinträge für die Navigationslinks ggf. mit den nötigen Werten für display und box. Auf den meisten Sites werden die Links in gleicher Größe und horizontal ausgerichtet dargestellt. Viele der Stile für die einzelnen Links werden Sie also über den Selektor #nav li ansprechen. 5. Platzieren Sie die Listeneinträge mit den Navigationslinks. Bei horizontal ausgerichteten Navigationselementen geht das per float: left oder position: relative. Beim zweiten Ansatz sind Änderungen am Design komplizierter. Dafür kann die erste Methode zu Problemen mit dem Internet Explorer führen. Vertikal ausgerichtete Navigationselemente werden in diesem Schritt vermutlich per display: block definiert. Die Wahrscheinlichkeit mehrerer Verschachtelungsebenen ist hier größer als bei horizontaler Ausrichtung. Die Listen für verschachtelte Navigationselemente sollten jeweils einen eigenen id-Wert bekommen (z.B. #navSubUeberUns). Weitere Details zu diesem Schritt finden Sie im Abschnitt »Quellcode-Reihenfolge und präzises Layout für die Navigation« auf Seite 105. 6. Vergrößern Sie Navigationslinks auf die volle Höhe und Breite der enthaltenen Listeneinträge. Hierfür definieren Sie die Darstellungsrolle der Links (a) als display: block. Die Vorteile dieser Methode werden in Kapitel 8 beschrieben. Um die richtigen Werte für width, height und padding zu finden, ist vermutlich etwas Rechenarbeit nötig. Außerdem kann es hilfreich sein, overflow: hidden für die enthaltenen Listeneinträge zu verwenden. 7. Verwenden Sie bei Bedarf die »Fahrner Image Replacement«-Methode für Ihre Listeneinträge und Links. Die »Fahrner Image Replacement«-Methode (FIR, eine Methode zur Ersetzung von Text durch Bilder) wird in Kapitel 9 beschrieben. Hierbei ist es möglich, dass sowohl die Navigationselemente (li) als auch die Links mit Hintergrundbildern versehen werden. Befindet sich der Mauszeiger über einem Link (»hover«), wird ggf. ein anderes Hintergrundbild dargestellt als für die übrigen Links. Stile für Navigationselemente
|
125
Rezept für die Navigation im Fußteil Die Stile für die sekundäre Navigation sind normalerweise einfacher zu definieren als für die primäre Navigation – einerseits, weil ihre Position in der Quellcode-Reihenfolge meistens klar ist (am Ende, vor den Copyright-Hinweis), andererseits, weil die Links selten konstante Größenangaben besitzen. Sehr wahrscheinlich wird für die sekundäre Navigation eine der drei folgenden Layoutmethoden verwendet: Zentriert, umgeben mit genügend Leerraum, wodurch mögliche Zeilenumbrüche nicht zu Kollisionen mit dem darunter stehenden Inhalt führen Ein Beispiel für dieses Layout finden Sie auf den öffentlichen Seiten von PayPal. Bei dieser Methode wird die Darstellungsrolle der Listeneinträge als display: inline definiert, die seitlichen Begrenzungslinien mit entsprechenden Werten für border. Mehr oder weniger bündig mit einer der unteren Ecken des Seitenlayouts Dieser Ansatz ist auf den Facebook-Benutzerseiten zu sehen. Der Hauptunterschied zwischen dieser Methode und der zuvor beschriebenen Zentrierung besteht in der Textausrichtung (text-align: right anstelle von text-align: center) und der vertikalen Ausdehnung (auf eine Zeile beschränkt, keine Umbrüche). Als Liste mit minimalen Stildefinitionen am Ende der dritten Spalte der Site Dieser Ansatz wird bei Weblogs immer beliebter. Hierbei befindet sich die sekundäre Navigation sowohl im Quellcode als auch in der Darstellung innerhalb der dritten Spalte. Das letzte beschriebene Layout ist völlig unproblematisch. Hierbei gibt es nur zwei Kleinigkeiten mit Trennlinien und Leerraum zu beachten. Hier sind die nötigen Schritte: 1. Versehen Sie die Liste oder ihre Einträge mit der Definition list-style-type: none. 2. Soll die Liste zentriert werden, definieren Sie die nötigen Werte für width, margin-left und margin-right. 3. Legen Sie für die Navigationsliste den gewünschten Wert für text-align fest und definieren Sie display-inline für die einzelnen Einträge. 4. Geben Sie sowohl der Liste als auch ihren Einträgen die passenden Werte für padding und line-height, es sei denn, Sie haben für die Links display: inline-block festgelegt. In diesem Fall sollten die fraglichen Box- und Texteigenschaften zugewiesen werden. Auf lange Sicht ist es einfacher, für die linke und rechte Seite jedes Eintrags den gleichen Wert für padding zu verwenden, auch wenn das auf den ersten Blick nicht so scheint. 5. Fügen Sie die Trennzeichen für die einzelnen Listeneinträge ein. Sollen hierfür eigene Aufzählungszeichen verwendet werden, definieren Sie diese am besten als Hintergrundbilder. 6. Kennzeichnen Sie das erste und letzte Element der Liste mit passenden class- oder id-Werten, und umbrechen Sie die Liste für die gewünschte Zeilenzahl. Oft hilft hier
126
|
Kapitel 7: Listen
die Verwendung der Eigenschaft white-space. Besitzen die Elemente einer Zeile die gleichen erkennbaren semantischen Eigenschaften, können Sie diese auch bedenkenlos auf mehrere Listen verteilen. 7. Passen Sie die Stilregeln nach Bedarf an die Anforderungen des Gesamtkonzepts an.
Definitionslisten Während geordnete und ungeordnete Listen einfache Datensammlungen sind, deren Elemente vage Gemeinsamkeiten haben, besteht bei Definitionslisten eine wesentlich engere Beziehung zwischen dem Definitionsbegriff (dt) und der Definition für diesen Begriff (dd). Auf jeden Begriff folgen eine oder mehrere Definitionen, die sich direkt auf den Begriff beziehen müssen. Um gültig zu sein, muss eine Definitionsliste mindestens ein dt- oder dd-Element enthalten. Um semantisch nützlich zu sein, muss die Liste jedoch mindestens je eines dieser Elemente besitzen. dt-Elemente dürfen nur Text und Inline-Elemente enthalten, während dd-Elemente die gleichen Elemente enthalten können wie li. Weder die Anzahl noch die Anordnung der dd- und dt-Elemente in einer Definitionsliste sind festgelegt. Es liegt beim Autor, die Elemente sinnvoll zu verwenden.
Stile für Definitionslisten Für Definitionslisten verwenden Benutzerprogramme nur minimale Stildefinitionen, die sich wie folgt beschreiben lassen: • dt-Elemente werden so ähnlich dargestellt wie Absätze ohne Außenabstände. • dd-Elemente werden per margin-left eingerückt, besitzen aber prinzipiell keine Aufzählungszeichen. • dd-Elemente besitzen genauso wenige Einschränkungen für die möglichen Inhalte wie li-Elemente. • Text innerhalb von Definitionslisten besitzt standardmäßig keine besondere Formatierung. Am häufigsten werden Definitionslisten für Lexika (Glossare, Wörterbücher) und transkribierte Dialoge verwendet. Das erste Szenario ist relativ einfach, und die Browser-Standardstile sind für diesen Zweck meistens ausreichend. Besonders typografiebewusste Designer wollen den Inhalt von dt möglicherweise fettgedruckt darstellen. Für die Gestaltung von Dialogen werden dagegen andere Werte benötigt. Hierfür sind folgende Änderungen nötig: • Die Breite für dt-Elemente sollte mit einem eigenen und konstanten Wert für width und der Deklaration clear: left versehen werden. • Der margin-left-Wert für dd-Elemente sollte etwas größer sein als die Breite für dt-Elemente.
Definitionslisten
|
127
• Der Inhalt von dt-Elementen sollte eine eigene typografische Gestaltung erhalten (z.B. per font-weight: bold oder text-transform: uppercase). Da die hier beschriebenen Formen direkt von Druckerzeugnissen inspiriert sind, gibt es reichlich gute Gründe, sie im folgenden Abschnitt zu übernehmen.
Wörterbuch-Beispiel Die folgenden Zeilen stammen aus dem American Heritage® Dictionary of the English Language, vierte Auflage: economy n. Inflected forms: pl. economies 1. a. Careful, thrifty management of resources, such as money, materials, or labor: learned to practice economy in making out the household budget. b. An example or result of such management; a saving. 2. a. The system or range of economic activity in a country, region, or community: Effects of inflation were felt at every level of the economy. b. A specific type of economic system: an industrial economy; a planned economy. 3. An orderly, functional arrangement of parts; an organized system: »the sense that there is a moral economy in the world, that good is rewarded and evil is punished« (George F. Will). 4. Efficient, sparing, or conservative use: wrote with an economy of language. 5. The least expensive class of accommodations, especially on an airplane. 6. Theology The method of God’s government of and activity within the world. adj. Economical or inexpensive to buy or use: an economy car; an economy motel.
Hier ist der Quelltext für die oben gezeigte Passage: e·con·o·my <span >n. <span >Inflected forms: <span >pl. e·con·o·mies
Careful, thrifty management of resources, such as money, materials, or labor: <span >learned to practice economy in making out the household budget.
An example or result of such management; a saving.
The system or range of economic activity in a country, region, or community: <span >Effects of inflation were felt at every level of the economy.
A specific type of economic system: <span >an industrial economy; a planned economy.
An orderly, functional arrangement of parts; an organized system: <span >the sense that there is a moral economy in the world, that good is rewarded and evil is punished (George F. Will).
128
|
Kapitel 7: Listen
Efficient, sparing, or conservative use: <span >wrote with an economy of language.
The least expensive class of accommodations, especially on an airplane.
<span >Theology The method of God’s government of and activity within the world.
<span >adj. Economical or inexpensive to buy or use: <span >an economy car; an economy motel.
Die für die Darstellung verwendeten Stildefinitionen finden Sie auf der Website zu diesem Buch. Das oben stehende Markup hat ein paar interessante Eigenheiten: Die verschiedenen Definitionen werden im Quelltext nicht als aufeinanderfolgende dd-Elemente, sondern als Elemente einer geordneten Liste markiert Der Grund hierfür ist, dass der Gestalter – in diesem Falle ich – entschieden hat, dass es besser ist, die Nummerierung beizubehalten, als sich an einer sehr geringfügigen semantischen Angelegenheit aufzureiben. Würde der Internet Explorer so wie seine Mitbewerber automatisch erzeugte Nummerierungen unterstützen, wäre ich nicht zu dieser Entscheidung gezwungen. Entscheidungen dieser Art sind bei mangelnder Browserunterstützung nicht selten. Benutzern anderer Browser als Internet Explorer werden die verschiedenen Definitionen als Inline-Elemente angezeigt Die Verwendung von display: inline sorgt dafür, dass die Aufzählungszeichen für die Listeneinträge nicht mehr angezeigt werden. Sie müssten die Listenmarker also über die Funktion counter() (ein möglicher Wert der Eigenschaft content) selbst wieder einfügen. Setzt der Gestalter die Darstellung in einem per Conditional Comments eingebundenen Stylesheet für den Internet Explorer zurück, sehen dessen Benutzer hier einfache geordnete Listen. Der Quellcode wird mit diversen Vorkommen von span und class zugemüllt. Die Fülle an Inline-Markup beleuchtet die Situation der Befürworter von Mikroformaten. Sie sind der Meinung, dass man Dinge, die man semantisch kennzeichnen kann, auch kennzeichnen sollte. Aus der Sicht des Gestalters bietet das zusätzliche Markup die Möglichkeit, die Kennzeichnungen entsprechend unterschiedlich darzustellen. Lässt man die Nummerierung und kleinere Details weg, kann eine allgemeine dt/ddStruktur verwendet werden: economy Careful, thrifty management of resources, such as money, materials, or labor: <span >learned to practice economy in making out the household budget. An example or result of such management; a saving. The system or range of economic activity in a country, region, or community: <span >
Definitionslisten
|
129
Effects of inflation were felt at every level of the economy. A specific type of economic system: an industrial economy; a planned economy. An orderly, functional arrangement of parts; an organized system: <span >“the sense that there is a moral economy in the world, that good is rewarded and evil is punished” (George F. Will). Efficient, sparing, or conservative use: <span >wrote with an economy of language. The least expensive class of accommodations, especially on an airplane. The method of God’s government of and activity within the world. Economical or inexpensive to buy or use: an economy car; an economy motel. ...
Beispiel für einen Dialog Ein Dialog ist dagegen etwas völlig anderes als eine Definitionsliste, aber die Teile passen gut zusammen. Hier eine Passage aus Pygmalion, Akt 4, von George Bernard Shaw: HIGGINS: [In despairing wrath outside] What the devil have I done with my slippers? [He appears at the door] LIZA: [Snatching up the slippers, and hurling them at him one after the other with all her force] There are your slippers. And there. Take your slippers; and may you never have a day’s luck with them! HIGGINS: [Astounded] What on earth –! [He comes to her] What’s the matter? Get up. [He pulls her up] Anything wrong? LIZA: [Breathless] Nothing wrong – with you. I’ve won your bet for you, haven’t I? That’s enough for you. I don’t matter, I suppose. HIGGINS: You won my bet! You! Presumptuous insect! I won it. What did you throw those slippers at me for? LIZA: Because I wanted to smash your face. I’d like to kill you, you selfish brute. Why didn’t you leave me where you picked me out of – in the gutter? You thank God it’s all over, and that now you can throw me back again there, do you? [She crisps her fingers frantically]
Hier ist der dazugehörige Quelltext: Higgins <span >In despairing wrath outside What the devil have I done with my slippers? <span >He appears at the door Liza <span >Snatching up the slippers, and hurling them at him one after the other with all her force There are your slippers. And there. Take your slippers; and may you never have a day’s luck with them! Higgins <span >Astounded What on earth—! <span > He comes to her What’s the matter? Get up. <span > He pulls her up Anything wrong? Liza <span >Breathless Nothing wrong — with <em>you.
130
|
Kapitel 7: Listen
I’ve won your bet for you, hav’n’t I? That’s enough for you. Idon’t matter, I suppose. Higgins <em>You won my bet! You! Presumptuous insect! I won it. What did you throw those slippers at me for? Liza Because I wanted to smash your face. I’d like to kill you, you selfish brute. Why didn’t you leave me where you picked me out of — in the gutter? You thank God it’s all over, and that now you can throw me back again there, do you? <span >She crisps her fingers frantically
Wie beim Wörterbuch-Beispiel werden auch hier span-Elemente und class-Attribute genutzt, um zusätzliche Informationen bereitzustellen, in diesem Fall die Bühnenanweisungen (stageDir). Was die Stylesheet-Regeln angeht, entspricht der allgemeine Ansatz dem zuvor beschriebenen, außer dass für das Element dt die Regel clear: left verwendet wurde. Der letzte deutliche Unterschied zwischen der Darstellung und dem Quelltext besteht darin, dass die Namen der Rollen in Großbuchstaben dargestellt werden. Wie in Kapitel 12 beschrieben, wird hierfür die Eigenschaft text-transform eingesetzt. Die genauen Stylesheet-Regeln für das Dialog-Beispiel finden Sie auf der Website zu diesem Buch. Irgendwann gab es einmal den Vorschlag, in HTML 5 ein dialog-Element einzuführen. Inzwischen wurde dieses Element aber wieder aus der Spezifikation entfernt.
Aufmerksame Webentwickler werden feststellen, dass sie ständig mit Listen zu tun haben. Der Nutzen und die Allgegenwart von Listen werden nur von der Herausforderung übertroffen, sie auch angemessen darzustellen.
Definitionslisten
|
131
KAPITEL 8
Überschriften, Hyperlinks, Inline-Elemente und Zitate
Der Bedarf nach leistungsfähigen Stildefinitionen für eine Site beginnt sicherlich beim Layout und endet mit Akzenten. Für Hervorhebungen bieten HTML und CSS vielseitige Möglichkeiten, insbesondere bei Überschriften und Hyperlinks. HTML definiert außerdem eine Reihe von Inline-Elementen, die es ermöglichen, verschiedene Inhalte sehr detailliert zu unterscheiden.
Überschriften und gutes Schreiben HTML definiert sechs Abstufungen für Überschriften: von h1 (am wichtigsten) bis h6 (am unwichtigsten), wie in Abbildung 8-1 zu sehen ist. (Die Schriftgrößen und Außenabstände sind die vom Browser definierten Stile für den Internet Explorer 8.) Für Uneingeweihte sind Überschriften nicht immer einfach zu handhaben: Standardmäßig werden die drei wichtigsten Überschriften für den Normalbenutzer irritierend groß dargestellt. Die Anpassung der oberen und unteren Außenabstände kann ebenfalls schnell zu einem Großprojekt werden.
Abbildung 8-1: Die sechs Abstufungen für Überschriften in der Darstellung durch den Internet Explorer 8 |
133
HTML und CSS besitzen absichtlich alle nötigen Mittel, um sämtliche Probleme zu meistern, die einem Entwickler bei der Arbeit mit Überschriften begegnen können. Werden Überschriften korrekt mit den Elementen für den eigentlichen Inhalt verbunden, heben sie möglicherweise wichtige Details der Dokumentenstruktur hervor. Gleichzeitig geben sie dem Gestalter die Möglichkeit, bei Bedarf auf bestimmte Überschriftengruppen gesondert einzugehen.
Gedruckte Überschriften Selbst wenn wir uns nicht damit befassen, wie Überschriften gestaltet werden sollen, bleiben einige Fragen offen. Hierzu gehört ihre Verwendung zur Kennzeichnung bestimmter Inhalte. Außerdem könnte man sich fragen, warum man die Überschriftenelemente überhaupt verwenden soll. Hierfür gibt es eine gute Erklärung aus dem Printbereich. Selbst der kürzeste gedruckte Text lässt sich meist in kleinere Abschnitte unterteilen, die einzeln und gemeinsam mit Überschriften versehen werden können. Im Falle eines Sachbuches – wie diesem – erhält jeder größere Bereich (der ein oder mehrere Kapitel enthält) eine Überschrift der Kategorie A (entsprechend h1). Der Buchtitel hat seinen eigenen Kontext und wird separat gestaltet. Überschriften der Kategorie B (h2) sind für Kapitelüberschriften reserviert, C-Überschriften (h3) für die wichtigsten Abschnitte eines Kapitels und so weiter. In anderen Büchern werden die Abschnitte selbst wie kleine Bücher behandelt, d.h., jeder Bereich erhält seine eigene Titelseite, während die einzelnen Kapitel mit A-Überschriften gekennzeichnet werden. Abgesehen davon, dass es ohnehin eine gute Idee ist, dem Leser bei der Orientierung im Dokument zu helfen und Änderungen im Kontext anzuzeigen, helfen Überschriften, den Inhalt in leicht verdauliche Happen zu unterteilen. Sämtliche Zuweisungen von Überschriften für bestimmte Teile beziehen sich auf das Buch als Ganzes. Dinge wie Datentabellen und Illustrationen haben zwar auch Beschriftungen, diese zählen aber nicht als Überschriften, sondern nur als Markierung für untergeordnetes (aber trotzdem wertvolles) Material. In HTML entspricht die Hierarchie von h1–h6 den Überschriften in gedruckten Büchern und Artikeln. Allerdings gibt es noch zwei weitere Dinge zu bedenken: Der einzige Ort, an dem das title-Element zuverlässig dargestellt wird, ist die Titelzeile des Browsers Das zwingt gewissenhafte Entwickler dazu, diese Information in einem h1- (oder vielleicht in einem h2-) Element am Anfang der Quellcode-Reihenfolge des Dokuments zu wiederholen. Das gilt auch, wenn der Dokumententitel einen größeren Zusammenhang herstellt, wie im folgenden Abschnitt besprochen wird. Ist der Firmenname besonders wertvoll, z.B. weil viele Besucher ihn in eine Suchmaschine eingeben, kann es vorteilhaft sein, ihn in einem h1-Element zu nennen Dieser Punkt basiert auf der Annahme, dass jede Seite jeweils nur ein h1-Element enthält, das am Anfang der Quellcode-Reihenfolge platziert wird. 134
|
Kapitel 8: Überschriften, Hyperlinks, Inline-Elemente und Zitate
Optimale Platzierung für Überschriften Traditionell gilt: Je höher die Gewichtung der Überschrift ist, desto größer ist der Umfang des vorgestellten Inhalts. Die Verwendung von Überschriften ist das Gegenteil der Benutzung von »Container-Elementen«, die in den Quellcodebeispielen im Abschnitt »Mit Dokumentenbäumen arbeiten« auf Seite 18 und im Abschnitt »Angewohnheit 4: Auf Kurs bleiben« auf Seite 58 zu sehen sind. Jeder korrekt zugewiesene Container verweist auf den Kontext einer Passage oder verstärkt so die Modularität des Inhalts. Im Web besteht der Hauptzweck von Überschriften darin, diese modularen Einheiten für Menschen lesbar anzuzeigen. Bei gewissenhafter Verwendung der Überschriftenelemente versieht ein Gestalter oder Entwickler jedes div-Element auch mit einer Überschrift der entsprechenden Gewichtung. Da alle diese Markup-Elemente einen mehr oder weniger breiten Geltungsbereich anzeigen sollen, wird normalerweise davon ausgegangen, dass die erste Überschrift ein h1-Element sein sollte. Hierauf folgen h2, h3 usw., wobei der Geltungsbereich immer enger wird. Die Gewichtung der Überschriften sollte immer ihrer jeweiligen Rolle entsprechen. Gleichzeitig sollte das Überspringen einer Überschriftenebene nach Möglichkeit vermieden werden. Normalerweise verpacke ich den Titel der Website und einen Link auf die Homepage in einem h1-Element (außer in der Druckversion). Für die Überschrift bzw. den Titel der Seite verwende ich ein h2-Element; die verschiedenen Abschnittsüberschriften erhalten je nach Bedarf eine der übrigen vier Überschriftsebenen. Auch ohne div-Elemente für die Markierung des Kontexts kann Software aus der Platzierung der Überschriften den Zusammenhang des dazwischenliegenden Inhalts zumindest so gut ableiten, um daraus bei Bedarf ein Inhaltsverzeichnis zu erstellen. Außerdem hat der Inhalt der Überschriftenelemente, insbesondere h1 und h2, einen übermäßigen Einfluss auf die Suchmaschinenrangfolge. Die tatsächlichen Auswirkungen unterscheiden sich von Anbieter zu Anbieter.
Stile für Überschriften Ein häufiger Grund für Kopfschmerzen bei Gestaltern ist die Tatsache, dass Außenabstände von Überschriften anders funktionieren als bei den meisten anderen Blockelementen.
Größe und Schriftart Die meisten guten Designs verwenden anstelle der Browser-Standarddarstellung eigene Stildefinitionen für Überschriften. Das liegt nicht zuletzt daran, dass die meisten Browser Überschriften einfach zu groß und hässlich darstellen.
Stile für Überschriften
|
135
Der erste Schritt zu attraktiven Überschriften besteht in der typografischen Gestaltung. Hierzu gehören Angaben zu Größe, Zeilenhöhe (line-height), Schriftart, Farbe und Boxverhalten für den gesamten auf der Site verwendeten Text. Zumindest sollten Überschriften eigene Größenangaben erhalten, die auf die verschiedenen Inhaltsebenen und die Absicht des Designers abgestimmt sind. Eine ausführliche Diskussion der Typografie finden Sie in Kapitel 12.
Die Größen von Überschriften anpassen Die erste Aktion, die Gestalter vor der Arbeit an Überschriften durchführen sollten, besteht darin, die Standardstile des Browsers für die Boxeigenschaften und die Werte für font-size zurücksetzen. Hier ist meine Empfehlung: h2 { margin: 0 0 1.5em 0; padding: 0; border: 0; ... }
Damit sind aber noch nicht alle gestalterischen Probleme gelöst. Auch line-height braucht etwas Aufmerksamkeit. Wichtiger sind aber die Positionen der Überschriften innerhalb der Seitenstruktur. Wird die Überschrift mit eigenen Boxwerten an den dazuhörigen Abschnittscontainer angepasst, ist der Aufwand beim Zurücksetzen nicht ganz so groß. Ansonsten sind für die Beziehung zwischen Überschriften und den folgenden Blockelementen ebenfalls Anpassungen nötig. Je nach Designvorgaben kann der Gestalter die Änderungen auch mit dem Selektor für benachbarte Geschwisterelemente (+) vornehmen, sofern dies von den erwarteten Browsern unterstützt wird. Schwieriger wird die Kontrolle der Überschriftenhöhe, wenn man sich strikt an das Designraster halten muss oder andere Platzbeschränkungen eine Rolle spielen. Am einfachsten definiert man für Überschriften eine feste Größe und beschränkt diese mit overflow: hidden. Allerdings ist dieser Ansatz so unflexibel, dass er für die meisten Sites nicht verwendbar ist. Ein weiterer Ansatz, die Höhe von Überschriften in einem Raster zu steuern, besteht darin, hohe line-height-Werte für den Haupttext zu verwenden, so dass alle Schriftgrößen auf einer Zeile mit verschiedenen Werten für line-height untergebracht werden können. Allerdings ist dieser Ansatz keine gute Idee für Sites, auf denen möglichst wenig gescrollt werden soll. Eine weitere Lösung ist eine Kombination aus Anpassungen von Größe und Kontrast, um so den Bedarf an unterschiedlichen Schriftgrößen (und damit Zeilenhöhen) zu verringern. Die beste Methode zur Steuerung der Überschriftenhöhen unterscheidet sich von Projekt zu Projekt und von Designer zu Designer. Jedenfalls ist das Ziel, die Überschriftenhöhen zu kontrollieren, ein gutes Beispiel für die Zusammenarbeit zwischen Gestaltern, Designern und Inhaltsautoren.
136
|
Kapitel 8: Überschriften, Hyperlinks, Inline-Elemente und Zitate
Überschriften hervorheben Die Überschriften einer Site können außerdem Begrenzungslinien enthalten. Diese können eine beliebige Länge, Farbe und beliebige Stile besitzen. Sie werden für einen Blocktext entlang einer der Außenkanten oder im Falle von Überschriften manchmal auch auf der Grundlinie platziert. Im Falle einfacher durchgehender Linien entlang der Außenkanten können Begrenzungslinien einfach mit der Eigenschaft border-bottom (oder auch border-top) definiert werden, z.B. mit h3 {border-bottom: 1px solid rgb(85,170,255); }. Die meisten anderen Akzente für Überschriften werden normalerweise über Hintergrundbilder realisiert, die in Kapitel 9 besprochen werden.
Markup für Links Die HTML-Inline-Elemente werden benutzt, um Wörter, Sätze oder kurze Passagen innerhalb größerer Inhaltsblöcke gemäß ihrer Bedeutung zu markieren. Am bekanntesten sind neben Hyperlinks – dem eigentlichen Grund des ganzen Unternehmens – und Formularelementen die Elemente, mit denen Hervorhebungen realisiert werden. Mit dem Begriff »Link« meinen wir in diesem Abschnitt alle Arten von mit dem a-Element erstellten Hyperlinks. Informationen zum Element link finden Sie in Kapitel 3 und auf der Website zu diesem Buch (www.htmlcssgoodparts.net).
Formularelemente werden in Kapitel 13 besprochen, während die semantisch orientierten Inline-Elemente am Ende dieses Kapitels behandelt werden. Es gibt eine Reihe von Gründen, bei der Implementierung von Links sehr aufmerksam zu sein: • Links sind prinzipiell interaktiv; wenn der Benutzer einen Link aktiviert, sorgt er dafür, dass etwas Neues passiert. Schon aus diesem Grund sollten Links immer gut vom umgebenden Inhalt zu unterscheiden sein. • Die Gestaltung von Links kann sich auf bestimmte Besucherinteressen beziehen. • Die Standard-Browserstile für Links basieren auf veralteten Annahmen über die Benutzerumgebung, die auf aktuellen Websites nur noch äußerst selten anzutreffen ist.
Link-Attribute Für Links (a-Elemente) können die folgenden Attribute definiert werden: href
Dieses Attribut ist das Herz der Applikationsschicht des Webs. Es definiert das Linkziel und erspart dem Benutzer die Eingabe oder das Einfügen von URIs in das Adressfeld des Browsers.
Markup für Links
|
137
target
Dieses Attribut übernimmt den Namen eines Fensters, Tabs oder Frames, in dem das Linkziel angezeigt werden soll. In den DTDs vom Typ Strict ist es nicht erlaubt. Die dazugehörige Funktionalität wird in diesem Fall in der Verhaltensschicht der Site definiert. Weitere Informationen zu target im Zusammenhang mit Frames finden Sie in Kapitel 14. rel
Wie bei link-Elementen kann dieses Attribut verwendet werden, um die Beziehung zwischen dem aktuellen Dokument und dem Linkziel zu beschreiben. Am häufigsten wird hierfür der Wert nofollow verwendet. Damit werden die Crawler-Programme der Suchmaschinen angewiesen, das Linkziel nicht in ihren Index aufzunehmen. Die nofollow-Funktion wurde von Google erfunden, damit Spam-Links in benutzererzeugten Inhalten bei der Berechnung der Rangfolge kein Gewicht zukommt. Abgesehen von nofollow gibt es für rel keine allgemein definierten Werte. Außerdem gibt es eine Reihe universeller Attribute, von denen title für Links wohl am wichtigsten ist.
Virtuose Verwendung des »href«-Attributs Bei href-Attributen sieht man manchmal den Wald vor lauter Bäumen nicht. Sie geben den Wert an und machen dann mit anderen Dingen weiter. Trotzdem gibt es vier Prinzipien, denen Sie bei der Erstellung von Links folgen sollten: Genauigkeit Zwischen Eingabefehlern und Links besteht eine lange, kranke und ziemlich verkorkste Beziehung. Daher ist es absolut wichtig, Links in der fertigen Version der Website durch Aktivieren zu überprüfen, und zwar bevor die Website veröffentlicht wird. Gültigkeit Die Struktur von URIs folgt einer detaillierten Spezifikation (IETF RFC 2396, http://www.ietf.org/rfc/rfc2396.txt), die festlegt, wie der Inhalt von Links aufgebaut ist. Bestimmte Zeichen müssen in URIs geschützt (escapt) werden, damit das Dokument validiert. Die Kodierung von URIs wird im Kasten »URL-Kodierung im Detail: ASCII-Entities« auf Seite 255 behandelt. Aktualität Mit der Zeit entwickeln Webdokumente den Hang, zu verschwinden oder verschoben zu werden. Das Ergebnis sind die berüchtigten »toten Links«. Es gehört zum guten Ton im Web, dass die Betreiber von Websites Weiterleitungen oder andere Ausfallsicherungen für verschobene oder anderweitig außer Reichweite bewegte Dokumente einrichten. Das passiert aber leider nicht immer. Auf jeden Fall muss irgendjemand überprüfen, ob die Links noch aktuell sind. Ich empfehle, sämtliche Links nach Möglichkeit vierteljährlich zu überprüfen. Einen Überblick über die Probleme und Lösungen im Zusammenhang mit der Aktualität von Links, zum
138
|
Kapitel 8: Überschriften, Hyperlinks, Inline-Elemente und Zitate
Beispiel über die Bequemlichkeit automatischer Link-Überprüfungen, finden Sie auf der Website zu diesem Buch. Kürze Solange die Suchmaschinenoptimierung (SEO) nicht so wichtig ist, sollten die Werte für href so kurz wie möglich sein, ohne dabei allerdings die enthaltenen Hinweise auf den Inhalt des Ziels zu verwässern. Kürzere href-Werte sorgen für eine bessere Lesbarkeit des Quellcodes und verringern die Gefahr von Eingabefehlern.
Links auf bestimmte Teile eines Dokuments Leser, deren HTML-Wissen bereits etwas angestaubt ist, werden das Attribut name kennen, das ausführlich in Kapitel 14 behandelt wird. Heutzutage wird stattdessen das Attribut id mit entsprechenden Werten verwendet, was Links im gleichen Dokument vereinfacht und mehr Bedeutung verleiht. Gegeben sei folgender Link: ...
Klickt der Benutzer auf diesen Link, gelangt er nicht nur auf die Seite schwalbe.html, sondern direkt nach dem Laden der Seite zu dem Element mit dem id-Wert europaeisch. Manchmal müssen die Benutzer wissen, dass ein solches Linkziel existiert (z.B. bei »Permalinks«). Eine beliebte Methode, die in den meisten aktuellen Browsern funktioniert, besteht darin, einen »Selbstlink« am Ende seines Elternelements einzufügen, diesen mit einem konsistent verwendeten Symbol zu kennzeichnen und Stile wie die folgenden zu definieren: p.enthaeltSelbstLink a { color: #fff; } /* entspricht der Hintergrundfarbe */ p.enthaeltSelbstLink:hover a { color: #999; } /* etwas Kontrast, aber nicht so viel wie fu ¨r den Haupttext */ ...
U¨ber die Geschwindigkeit von europa ¨ischen Schwalben wird viel spekuliert, besonders auf ironische Weise. →
Dies gibt Besuchern, die sich mit der Website auskennen, die Möglichkeit, den Wert von href zu kopieren und in ihren eigenen Webinhalten weiterzuverwenden.
Effektiver Inhalt für Links und Werte für das »title«-Attribut Nicht immer haben Links auch einen idealen Inhalt. Das kann verschiedene Gründe haben: • Viele Links sind nicht als Teil des Seiteninhalts, sondern ihrer Schnittstelle angelegt. Das verleitet Designer dazu, die Links mit ideografischen Inhalten oder nur den kürzesten Stichwörtern zu füllen. • Auf Seiten, auf denen es um Einkäufe oder um die Erstellung von Benutzerkonten geht, enthalten viele Links aus gutem Grund eine entsprechende Aufforderung (z.B. »Hier klicken«) anstelle einer aussagekräftigen Beschreibung. Markup für Links
|
139
• Manchmal wird bei der Erstellung einer Site (oder eines Teils davon) davon ausgegangen, dass der Benutzer den Inhalt in einem bestimmten Kontext betrachtet. • Vielleicht hat sich der Designer entschieden, ein Logo oder ein anderes Bild als Inhalt für den Link zu verwenden. Wenn sich die oben beschriebenen Umstände vermeiden lassen, sollten Links drei der vier für href-Attribute beschriebenen »Tugenden« in der hier beschriebenen Reihenfolge aufweisen: Kürze, Genauigkeit und Aktualität. Die häufigsten Gründe, die beschreibende Links verhindern, führen direkt zum Attribut title, das besonders Benutzern von Hilfstechnologien dienlich sein kann.
Gehen wir von den gerade beschriebenen Situationen aus, wären die folgenden Werte für title, jeweils der Situation entsprechend, angemessen: Schlüsselwörter der Schnittstelle Kontakt
Handlungsaufforderung Klicken Sie hier, um sich fu ¨r unsere E-Mail-Liste anzumelden.
Einzelner Kontext
Logografik als Inhalt eines Links Dieser Artikel ist erha¨ltlich bei:
...
Beachten Sie besonders das Beispiel »Handlungsaufforderung«. Hier erhält der Link seinen Kontext erst durch den Inhalt des title-Attributs. Der Inhalt des Links dient als Beispiel für Dinge, die vermieden werden sollten. Trotzdem sind knappe Handlungsaufforderungen auf Startseiten notwendig. Nach Möglichkeit sollte der Autor etwas Verständlicheres verwenden als einfach nur »Hier klicken«. Wird das title-Attribut gewissenhaft eingesetzt, erleichtert dies die automatische Erfassung des Dokumenteninhalts und der ausgehenden Links. So wie Überschriften die größere Struktur des Dokuments beschreiben, können title-Attribute den Inhalt im Detail beschreiben. Neben den hier beschriebenen Vorteilen besitzt das title-Attribut aber auch gewisse Einschränkungen. Dies gilt besonders für die Zugänglichkeit für Benutzer, die für die Navigation auf der Seite die Tastatur verwenden, was sich (beispielsweise) mit speziellem
140
|
Kapitel 8: Überschriften, Hyperlinks, Inline-Elemente und Zitate
JavaScript-Code reparieren lässt. Aus diesem und anderen Gründen sollten für das Verständnis wichtige Inhalte immer sofort sichtbar sein.
Stildefinitionen für Links Links sind auch ohne zusätzliche Skripte schon interaktiv. Daher ist die Aufmerksamkeit des Gestalters hier besonders gefragt. Verlässt man sich auf die Standarddarstellung des Browsers, haben Links zwei ernsthafte Mängel: • Die Standardschriftfarben für Links sind schlimmstenfalls unattraktiv und im besten Falle für die meisten Farbpaletten nicht verwendbar. • Da Links Inline-Elemente sind, beanspruchen sie nur den Platz, der gerade für ihre Darstellung nötig ist. Wenn es nicht möglich ist, wichtige Links mit einer angemessenen Menge an Inhalt zu füllen, sind sie entweder schwer zu finden und zu benutzen oder einfach nur groß und hässlich. Aufgrund ihrer Interaktivität ist die Definition von Stilen für Links aufwendiger als für andere Elemente.
Pseudoklassen für Links Links können verschiedene Zustände haben (z.B. aktiv, besucht etc.). Daher ist es zwar logisch, aber nicht besonders praktikabel, Stildefinitionen für Links nur über den Elementselektor zuzuweisen. Deshalb definiert CSS vier Pseudoklassen, entsprechend den vier möglichen Linkzuständen: :link (der Link wurde noch nicht angeklickt), :visited (der Link wurde bereits angeklickt), :hover (der Mauszeiger befindet sich über dem Link) und :active (der Link wird momentan angeklickt). In einem allgemeinen Stylesheet sollten die Pseudoklassen in folgender Reihenfolge definiert werden: :link, :visited, :hover, :active. Zuvor definieren Sie eine Regel für das allgemeine Element a ohne Pseudoklassen. Als Eselsbrücke kann man die englischen Wörter LoVe HAte verwenden. Der Grund für diese Reihenfolge besteht in der bereits besprochenen Spezifität. In diesem Fall greift die Regel, nach der Selektoren mit gleicher Spezifität gemäß ihrer Reihenfolge im Quellcode gewichtet werden (der letzte Selektor hat Vorrang vor dem ersten). Links sind zu Beginn unbesucht, aber das ändert sich. In beiden Fällen muss sich der Mauszeiger nicht über dem Link befinden. Sehr wahrscheinlich wollen Sie die anderen beiden Zustände (Mauszeiger über dem Link, Link wird angeklickt) mit eigenen Stilen versehen, um sie von den anderen unterscheiden zu können. Außerdem kann ein Link natürlich nur dann aktiviert werden, wenn sich der Mauszeiger bereits darüber befindet.
Stildefinitionen für Links
|
141
Wäre die Reihenfolge der Pseudoklassen-Regeln umgekehrt, würden die Stile :hover und :active vom Browser ignoriert werden, da in diesem Fall die »allgemeine« Regel für benutzbare Links aufgrund ihrer Position im Quellcode Vorrang vor den spezielleren Regeln bekäme, auch wenn sich der Mauszeiger über einem Link befände. Für die Selektoren mit Pseudoklassen gibt es keine besonderen Einschränkungen, welche Paare aus Eigenschaft und Wert Sie hier verwenden. Bei der Priorität der Selektoren gibt es eine wichtige Ausnahme: Wird eine Eigenschaft in einer Regel definiert, die auf das Element a ohne weitere Pseudoklassen zutrifft, werden Regeln mit Pseudoklassen im Falle eines Konflikts in Firefox und Internet Explorer nicht angewendet. Anders gesagt: Enthält Ihr Stylesheet die Regel a { color: #00f; }, so wird die Regel a:visited { color: #808; } ignoriert. Wurde dagegen a:link { color: #00f; } definiert, so wird a:visited { color: #808; } beachtet. Außerdem enthält die CSS-Spezifikation noch die Pseudoklasse :focus. Hiermit lassen sich gezielt Stile für Elemente definieren, die gerade den Eingabefokus haben, aber nicht aktiviert sind. Diese Pseudoklasse wird vom Internet Explorer aber erst ab der Version 8 unterstützt. Sie kommt beispielsweise zum Einsatz, wenn der Benutzer die Tastatur zur Navigation zwischen den Elementen verwendet oder den Mauszeiger während eines Klicks vom Element wegbewegt. Wird :focus für Links verwendet, sollte die Eigenschaft nach :hover, aber vor :active definiert werden.
Mit »display: block« den anklickbaren Bereich von Links vergrößern Gehört ein Link zur Benutzerschnittstelle einer Site (z.B. als Teil der Navigation) oder soll er als Handlungsaufforderung verwendet werden, kann es praktisch sein, ihn wie einen Button benutzen zu können. Hierbei ist nicht nur der Linktext, sondern die gesamte Box des Links anklickbar. Die Beziehung zwischen der Interaktivität eines Links und dem Cursor wurde bereits im Abschnitt »Links auf das aktuelle Element deaktivieren« auf Seite 67 kurz besprochen. Zuerst müssen Sie für den Link die Regel display: block definieren. Durch den veränderten display-Wert können Sie die Größe des anklickbaren Bereichs mit den Eigenschaften width und height steuern. Dieses lässt sich durch passende Werte für padding und die verschiedenen Eigenschaften für Hintergründe (ggf. zusammen mit Bildersetzungsmethoden wie dem Fahrner Image Replacement) noch verfeinern (siehe im Abschnitt »Grafische Schriften und das Fahrner Image Replacement« auf Seite 162). Bei der Definition von Stilen für Links der Benutzerschnittstelle muss der Gestalter folgende Dinge beachten: Den Wert von display für Container-Elemente Damit Links das gewünschte Verhalten zeigen, müssen sie sich innerhalb von Elementen finden, deren Wert für display entweder block oder inline-block ist.
142
|
Kapitel 8: Überschriften, Hyperlinks, Inline-Elemente und Zitate
Statische oder flexible Layouts? Die Positionierung von Hintergrundbildern (sei es für Hintergründe oder als Teil des Fahrner Image Replacements) ist in statischen Layouts meistens kein großes Thema. In proportionalen oder auf Hilfslinien basierenden Layouts werden sie dagegen am besten innerhalb des sie umgebenden Links zentriert. Die Höhe und Breite von Links berechnen Im einfachsten Fall reicht es, für Links einen height-Wert von 100% festzulegen. Ist eine detaillierte Zuweisung nötig, können Höhe, Breite, Rahmen (falls vorhanden) und Innenabstände separat berechnet und zugewiesen werden. Formatierungstechniken für Links werden auch im Kontext der Navigation in den Kapiteln 5 und 7 beschrieben. Das Verhalten der Eigenschaft cursor wird auf der Website zu diesem Buch gezeigt.
Stildefinitionen für die Pseudoklassen »:hover« und »:active« CSS-Anfänger erliegen oft der Versuchung, Schriftgewicht, Schriftgröße oder die Dimensionen von Links während der Interaktion zu verändern. Machen Sie das nicht! Stildefinitionen, die die Größe eines Elements ohne Vorwarnung ändern, können das gesamte Seitenlayout gefährden. Die Frustration der Benutzer, die mit der Seite interagieren müssen, ist Ihnen gewiss. Diese Regel kann weniger streng genommen werden, wenn der umgebende Inhalt zuverlässig an festen Punkten im Layout verankert ist. Um ausgezeichnete Ergebnisse zu erzielen, müssen allerdings Designer wie Entwickler ein hohes Maß an Training und Erfahrung besitzen.
Die Eigenschaft »text-decoration« Manchmal ist es nützlich, kurze Textpassagen mit Unter-, Über- oder Durchstreichungen zu versehen. Zu diesem Zweck gibt es die Eigenschaft text-decoration mit den folgenden möglichen Werten: underline
Unterstreichung. Der Standardwert für die Elemente a und ins. line-through
Durchstreichung. Der Standardwert für das Element del. overline
Überstreichung. Das Gegenstück zu underline. Wird nur selten benutzt. Der Wert blink wird in der CSS 2.1-Spezifikation ebenfalls erwähnt. Er wird heutzutage aber nur noch von Firefox unterstützt, und das auch nur, wenn er ausdrücklich in den about: config-Einstellungen des Browsers aktiviert wird. Stildefinitionen für Links
|
143
Die Eigenschaft »cursor« CSS stellt eine Schnittstelle zu der Systembibliothek der Mauszeiger-Objekte des Betriebssystems zur Verfügung. Diese lässt sich über die Eigenschaft cursor nutzen. Der Standardwert ist auto. Weitere mögliche Werte sind: • default (meist ein Pfeil) • pointer (Der Standardwert für Links) • crosshair (»Fadenkreuz«, verwendet z.B. für Elemente, die per Drag and Drop verschoben werden können) • text (der Standardzeiger für reine Textinhalte, oft eine Einfügemarke) • help • progress • wait Von diesen Werten wird help am häufigsten verwendet, z.B. um dem Benutzer zu signalisieren, dass für das betreffende Element ein »Tool Tip« zur Verfügung steht. Der Wert kann auch benutzt werden, um Links hervorzuheben, die auf eine Liste mit häufig gestellten Fragen (FAQ) oder andere Hilfe-Ressourcen verweisen. Eine Verwendung der anderen Werte sollte auf Webapplikationen beschränkt bleiben. Es empfiehlt sich, die Wirksamkeit eigener Werte durch Benutzertests zu bestätigen.
Semantische Bedeutung durch Inline-Elemente Neben Links gibt es eine Anzahl weiterer Inline-Elemente, mit denen auch feine Bedeutungsunterschiede des Inhalts verdeutlicht werden können. Eine Zusammenfassung dieser Elemente sehen Sie in Tabelle 8-1. Tabelle 8-1: Inline-Elemente in HTML 4 Element
Beschreibung
entsprechendes »Präsentationselement«
em
Hervorhebung
i, u
strong
starke Hervorhebung
b
cite
Quellenangabe
i
Verwendet für Titel von Büchern, Zeitschriften, Fernsehprogramme und die lange Namensform von audiovisuellen Medien, aber nicht für andere Eigennamen.
code
Programmiercode
tt
siehe kbd, samp
kbd
Benutzereingaben
tt
samp
Beispiel f. Ausgabe von tt Programmen
abbr
Abkürzung
144
|
Erklärungen
Laut HTML 4.01-Spezifikation unterschiedlich zu code. code impliziert die Ausführbarkeit, während samp die Ausgabe von Programmen kennzeichnet.
[keine]
Kapitel 8: Überschriften, Hyperlinks, Inline-Elemente und Zitate
Tabelle 8-1: Inline-Elemente in HTML 4 (Fortsetzung) Element
Beschreibung
entsprechendes »Präsentationselement«
Erklärungen
acronym
Akronym
[keine]
Akronyme und Abkürzungen werden auf unterschiedliche Weise gebildet. Ihre Formatierung ist länderabhängig.
sup
hochgestellt
[keine]
Erhält am besten einen möglichst kleinen Wert für lineheight.
sub
tiefgestellt
[keine]
ins
Einfügung
[keine]
Standardmäßig unterstrichen dargestellt.
del
Löschung
strike
Kennzeichnet obsolete Textpassagen, z.B. in Gesetzestexten. Oft gefolgt von ins, um eine Aktualisierung zu kennzeichnen.
q
Kurzzitat (Inline)
[keine]
Das Verhalten ist browserabhängig. Für längere Zitate sollte blockquote verwendet werden.
var
Variable, irrationale Zahl
i
z.B. 2pr, (sin2θ + cos2θ) = 1
dfn
Definition
i und em (im Kontext)
Kennzeichnet Begriffe, die im Lauftext als Definitionsbegriff verwendet werden, z.B. als Ergänzung zu Definitionslisten (siehe im Abschnitt »Definitionslisten« auf Seite 127); besonders effektiv bei Zuweisung eines id-Werts, um als Linkziel für sich selbst zu dienen.
Die meisten in Tabelle 8-1 gezeigten Elemente sind bezüglich ihrer Standarddarstellung im Browser relativ leicht verständlich. Zwei Inline-Elemente haben dagegen keine Standardstile und müssen gesondert betrachtet werden: abbr and acronym. Wie bereits im Abschnitt »Effektiver Inhalt für Links und Werte für das ›title‹-Attribut« auf Seite 139 erwähnt wurde, betrachten Webbenutzer bestimmte Inhalte außerhalb ihres vorgesehenen Kontexts. Dies ist besonders bei Akronymen und Abkürzungen der Fall, die oftmals Fachbegriffe oder Umgangssprache enthalten. Besucher, die den Kontext nicht kennen, kann dies leicht so sehr verwirren, dass für sie die gesamte Website unverständlich wird. Wenn Sie andererseits mithilfe des title-Attributs Hinweise auf die Bedeutung von Akronymen und Abkürzungen einbauen, wird Ihr Text insgesamt zugänglicher. In aktuellen Versionen von Firefox wird für die Standarddarstellung die folgende Regel Errata: rules are -> rule is verwendet: acronym, abbr { border-bottom: 1px dotted; }
Sie können Regeln wie diese auch um die Definition cursor: help erweitern. Das wird zwar akzeptiert, aber nur selten verwendet. Die Vorteile dieser Methode werden im Abschnitt »Die Eigenschaft ›cursor‹« auf Seite 144 erklärt. Wie weit abbr und acronym von den aktuellen Browsern unterstützt werden, sehen Sie in Tabelle 8-2.
Semantische Bedeutung durch Inline-Elemente
|
145
Tabelle 8-2: Unterstützung für »abbr« und »acronym« (Stand: Mitte 2009) Element
Benutzbar in
abbr
DOM
acronym
IE 6
IE 7 ✓
✓
Stylesheets
✓
✓
✓
DOM
✓
✓
✓
✓
✓
✓
✓
✓
✓
Stylesheets
IE 8
FF 2
FF 3
Safari 3
✓
✓
✓
✓
✓
Safari 4 ✓ ✓
✓
✓ ✓
Zitate Für Kurzzitate bietet HTML das Inline-Element q. Längere Zitate werden normalerweise mit dem Blockelement blockquote markiert. Nach der HTML 4.01-Spezifikation sollen diese Elemente das Attribut cite unterstützen. Hiermit kann ein URI angegeben werden, unter dem die Quelle des Zitats gefunden werden kann. In der Praxis wird cite jedoch von allen Browsern außer dem Internet Explorer 8 ignoriert. Das Resultat sind Zitate, die in cite- und a-Elemente gequetscht werden. Damit keine Metadaten verlorengehen, sollten für das cite-Attribut aber trotzdem gültige URI-Werte angegeben werden. Das blockquote-Element hat drei hervorstechende Eigenschaften: In der Standarddarstellung der Browser wird es mit einem unübersehbaren Wert für margin-left angezeigt. Anführungszeichen müssen bei Bedarf selbst eingefügt werden. Außerdem verlangen DTDs vom Typ Strict, dass blockquote-Elemente selbst mindestens ein Blockelement (normalerweise einen Absatz) enthalten. Das Markup für Zitate bietet nur eingeschränkt Unterstützung für die Pseudoelemente :before und :after, die vom Internet Explorer erst ab der Version 8 unterstützt werden. In Browsern, die :before und :after unterstützen, werden öffnende und schließende Anführungszeichen im Browser-Stylesheet für die Standarddarstellung für den Inhalt von q-Elementen definiert. Das Element blockqouote geht dagegen in allen aktuellen Browsern leer aus. Um blockquote trotzdem mit typografisch korrekten Anführungszeichen zu versehen,
können Sie zum Beispiel die folgenden Regeln in Ihrem Stylesheet definieren: blockquote:before { content: open-quote; } blockquote:after { content: close-quote; }
Die Pseudoelemente :before und :after werden selbstverständlich genauso verwendet wie für das q-Element; ohne die Eigenschaft content wären sie wertlos. Interessanterweise kann content auch nur für diese Selektoren verwendet werden. Die Werte für content können auch dafür sorgen, die Standardstile des Browsers zu überschreiben, wodurch Autoren bei Bedarf eigene Zeichen verwenden können. Diese Methode ist zwar etwas arbeitsintensiver, erhöht aber die Kompatibilität mit Hilfstechnologien. Üblicherweise werden als Werte für content meist open-quote, close-quote oder eine andere, mit Anführungszeichen umgebene ASCII-Zeichenkette verwendet. Zeichen außerhalb des ASCII-Zeichensatzes, literale Anführungszeichen und kodierte Zeilenumbrüche müssen, wie in Kapitel 14 beschrieben wird, mit einem vorangestellten Escape-Zeichen geschützt werden. 146
|
Kapitel 8: Überschriften, Hyperlinks, Inline-Elemente und Zitate
KAPITEL 9
Farben und Hintergründe
Für die meisten von uns sind Farben im Web völlig normal. Für Web-Profis bedeuten sie dagegen eine Menge Arbeit. Erfahrene Entwickler müssen beispielsweise wissen, welche Farbcodes einer tatsächlichen Farbe entsprechen. Und das ist erst der Anfang. Bei Webfarben geht es nicht nur um Zahlen, sondern auch um Kunst. Daher ist es sicher von Vorteil, sich in beiden Bereichen auszukennen. Hintergründe haben ebenfalls ihre eigenen Tücken. Die Zuweisung einer schlichten Hintergrundfarbe für ein Element ist nicht schwer. Sobald aber Bilder ins Spiel kommen, vervielfachen sich die Fragen der Implementierung. Da in diesem Buch Webfarben und -grafiken nicht bis ins letzte Detail behandelt werden, möchte ich Sie zumindest auf die bereits vorhandenen Ressourcen verweisen. Eine Reihe von Informationen ist über die Website zu diesem Buch (http://www.htmlcssgoodparts.net) verlinkt. Außerdem empfehle ich die folgenden Bücher: • Web Style Guide, 3. Auflage, von Sarah Horton und Patrick Lynch (Yale University Press) • Painting the Web (http://oreilly.com/catalog/9780596515096/) von Shelley Powers (O’Reilly)
Farbenlehre und Webfarben Zu den CSS 2.1-Eigenschaften, für die Farbwerte definiert werden können, gehören die verschiedenen Hintergrund-(background-*)- und Rahmen-(border-*)-Eigenschaften. Außerdem gibt es noch die Eigenschaft color, mit der die Farbe für Text, Über-, Unter- und Durchstreichungen festgelegt werden kann.
|
147
Usability, Zugänglichkeit und Farbe Wenn Sie zwei Elementen Text- und Hintergrundfarben zuweisen, sollten Sie die folgenden Dinge beachten: • Enthält ein Stylesheet eine Definition für background oder background-color, sollte unbedingt auch eine Definition von color folgen. Anders herum sollte einer Definition von color unbedingt auch eine Definition der Hintergrundfarbe vorangestellt werden. Dies verhindert, dass Definitionen in Browser- oder Benutzer-Stylesheets Ihren Text unlesbar machen. • Werden Hintergrundbilder verwendet, sollte auf jeden Fall auch eine passende Hintergrundfarbe definiert werden. Auch hier ist die Lesbarkeit der Grund. • Die Zugänglichkeit wird erleichtert, wenn es zwischen Text- und Hintergrundfarbe einen deutlichen Kontrast gibt. Dies gilt besonders in Bezug auf die Farbhelligkeit. Auch die Sehschärfe älterer Besucher spielt eine Rolle. Mit dem Alter nimmt die Anpassungsfähigkeit der Strukturen im Auge ab, wodurch Details und Farben schwerer zu unterscheiden sind. Dieser Verlust tritt besonders im Nahbereich auf und ist allgemein als Altersweitsichtigkeit bekannt. Designs mit hohem Kontrast können auch bei Farbenblindheit helfen. Hierzu ein paar Informationen: • Die bei Weitem häufigste Form der Farbenblindheit ist die Rot-Grün-Blindheit, die bei ungefähr 5 % der Bevölkerung (überwiegend bei Männern) auftritt. • Farbenblindheit äußert sich darin, dass bestimmte Wellenlängen des Lichts vollkommen dunkel wahrgenommen werden. Ähnlich wie infrarote oder ultraviolette Wellenlängen vom menschlichen Auge nicht erkannt werden, nehmen farbenblinde Menschen bestimmte Bereiche des normalerweise sichtbaren Lichtspektrums nicht wahr. • Website-Besuchern mit einer Rotschwäche erscheinen rote Farbschattierungen stark grün oder blau eingefärbt, während Besucher mit einer Grünschwäche grüne Farbschattierungen mit einer starken Rot- oder Blaufärbung wahrnehmen. Besuchern mit einer vollkommenen Farbschwäche fehlt jegliche Farbinformation, was sich auf die Helligkeitswahrnehmung aller Farben auswirken kann. • Die verbleibenden für Farbenblinde sichtbaren Wellenlängen können trotzdem als weißes Licht empfunden werden. Der so wahrgenomme Bereich erscheint Farbenblinden größer als Besuchern mit normaler Farbwahrnehmung. Der umgekehrte Satz gilt für Schwarz. Links zu Farbblindheitssimulatoren und anderen Ressourcen für die Kontrast-Analyse finden Sie auf der Website zu diesem Buch.
148
|
Kapitel 9: Farben und Hintergründe
Das additive Farbmodell Das additive Farbmodell ist benannt nach der Art, wie Farben durch Hinzufügen gemischt werden. Dieses Modell wird beispielsweise im Kunstunterricht gelehrt, da es sich auf Farben und andere Pigmente bezieht. Wird es auf einen weißen Untergrund (Papier, Leinwand etc.) angewandt, entstehen aus blauen, roten und gelben Pigmenten die folgenden Farbschattierungen: • Blau + Rot = Violett • Blau + Gelb = Grün • Rot + Gelb = Orange Durch Hinzufügen schwarzer oder weißer Pigmente (typischerweise Kohle bzw. Bleiweiß) kann sofort die gewünschte Farbe hergestellt werden. Im Farbdruck hängt die Helligkeit einer Farbe vom verwendeten Pigment (Tinte, Toner etc.), der Deckkraft der Farbe und ihrer Sättigung ab.
Das HSB-Farbmodell Um Farben auch ohne Erfahrung mit Pigmenten schnell identifizieren zu können, ist das HSB-Farbmodell (Hue, Saturation, Brightness – Farbton, Sättigung und Helligkeit) am einfachsten zu verstehen. Es ordnet alle sichtbaren Farbtöne nach absteigender Wellenlänge (von Rot nach Violett). Basierend auf den drei Grundfarben werden die Farbabstufungen meist auf einer runden 360-Grad-Skala angeordnet. In der HSB-Notation entspricht 0 der Farbe Rot, 120 entspricht Grün, und 240 steht für Blau. Die Zuordnung der Farben zu ihren HSB-Werten geschieht nach folgenden Regeln: • Die Werte für den Farbton folgen den Farben des Regenbogens, wobei Rot den niedrigsten und Violett den höchsten Wert besitzt. • Die Werte für die Sättigung bewegen sich auf dem Farbrad von neutral bis zum intensivsten Wert. Um Weiß oder eine Grauschattierung zu erzeugen, muss der Sättigungswert Null sein. • Die Werte für die Helligkeit bewegen sich von Null bis 100 %. Der Helligkeitswert Null ergibt immer Schwarz. Der Helligkeitswert 100 % kann für jede beliebige Farbe gelten.
Das subtraktive Farbmodell In den USA. wird das additive Farbmodell in der Grundschule gelehrt, während das subtraktive Modell erst in der Highschool behandelt wird. Allein schon diese Tatsache verdeutlicht, wie komplex das subtraktive Modell offenbar ist. In der physischen Welt wird alles sichtbare Licht reflektiert. Ist ein Pigment vorhanden (unabhängig davon, ob es absichtlich auf eine Oberfläche aufgebracht wurde, naturgemäß dort vorhanden ist, oder durch einen natürlichen Prozess erzeugt wurde) absorbiert es
Farbenlehre und Webfarben
|
149
sämtliche Wellenlängen des Lichts, die nicht seiner Farbe entsprechen. Je dunkler oder gesättigter eine Farbe ist, desto weniger Licht reflektiert sie, was zu dem Begriff subtraktiv führt. Moderne Anzeigegeräte (sprich: Monitore) funktionieren jedoch, indem sie Licht aussenden, anstatt es zu reflektieren. Ältere Röhrenmonitore (CRT) und die aktuellen LCD-Bildschirme projizieren ein Pixel mit einer engen roten, grünen oder blauen Wellenlänge unterschiedlicher Intensität. Haben alle drei Farbkanäle die maximale Intensität, strahlt der Monitor weißes Licht ab. Schwarz wird dagegen erzeugt, wenn alle drei Kanäle die geringstmögliche Intensität haben. Sind nur zwei Kanäle aktiv und haben diese die größtmögliche Intensität, entstehen die folgenden sekundären Farben: • Rot + Grün = Gelb • Grün + Blau = Cyan • Blau + Rot = Magenta Farben, die weder primäre noch sekundäre Farben sind, werden erzeugt, indem alle drei Farbkanäle mit unterschiedlicher Intensität gemischt werden. Der aktuell von CSS unterstützte 24-Bit-Farbraum ermöglicht eine Auswahl aus mehr als 16 Millionen verschiedenen Farben. Diese basieren auf 256 Intensitätsabstufungen (8 Bit) für jeden Kanal. Je näher der erzeugte Farbwert dem Wert Null ist (z.B. bei der Angabe rbg(0,0,0)), desto dunkler erscheint die Farbe. Die Farbwerte für die 256 möglichen Graustufen sind leicht zu erkennen, denn die Werte ihrer Einzelfarben sind immer gleich (z.B. rbg(100,100,100)). Weitere Informationen zum subtraktiven Farbmodell finden Sie auf der Website zu diesem Buch.
Design, Kontrast und Komplementärfarben Eine gut gestaltete Website basiert normalerweise auf Designrichtlinien und Anforderungsdokumenten. Sie fassen sämtliche verfügbaren Informationen und Meinungen zu den erwarteten Besucher- und Geschäftszielen zusammen. Der Gestaltungsprozess wird stark von der Funktion des Designs beeinflusst. Im Gegensatz zur Kunst will effektives Grafikdesign Ideen verständlich vermitteln und dem Nutzer beim Erreichen (oder Finden) bestimmter Ziele helfen. Ästhetik spielt im Design natürlich auch eine wesentliche Rolle. Sie wird allerdings davon bestimmt, welche Ideen mit dem Design transportiert werden sollen. Idealerweise werden Motive und Designrichtlinien festgelegt, sobald klar ist, wie eine Website erstellt werden soll. Hierbei sind die Erwartungen von Kunden und Händlern genau so wichtig wie die Besucher- und Geschäftsziele. Ein wichtiger visueller Bestandteil jedes Sitedesigns (und der zugrunde liegenden Motive) ist die Farbpalette, die im Design für die Kommunikation der Ideen verwendet wird. Paletten bestehen fast immer aus mindestens drei Farben oder Graustufen für Vorder-
150
|
Kapitel 9: Farben und Hintergründe
grund (Text), Hintergrund und hergehobene Akzente. Paletten mit sechs und mehr Farben sind nicht ungewöhnlich. Wir haben bereits gesagt, dass Kontrast Menschen mit Sehproblemen helfen kann. Dies gilt aber auch für Besucher, die die volle Sehfähigkeit haben. Oftmals verwenden Designer Komplementärfarben für Vorder- und Hintergrund, um einen möglichst hohen Kontrast zu erreichen. Komplementärfarben sind »gegensätzliche« Farbtöne; eine genaue Beschreibung bietet das HSB-Modell: Die Komplementärfarbe liegt auf dem HSB-Farbrad genau gegenüber der gegebenen Farbe. So ist Gelb beispielsweise die Komplementärfarbe zu Blau. Komplementärfarben finden sich auch bezogen auf Sättigung und Helligkeit. Im substraktiven Farbmodell können Komplementärfarben gefunden werden, indem die Werte eines Farbkanals so umgekehrt werden, wie in Tabelle 9-1 beschrieben. Tabelle 9-1: Beispiele für Komplementärfarben im subtraktiven/RGB-Modell Grundfarbe
Komplementärfarbe
Rot
Grün
Blau
Rot
Grün
Blau
255
255
255
0
0
0
255
255
0
0
0
255
51
102
153
204
153
102
43
61
21
212
194
234
143
34
69
112
221
186
192
114
12
63
141
243
Der Begriff »umgekehrt« bezieht sich auf den Wert, den man erhält, wenn der erste Wert von 255 (der höchste mögliche Dezimalwert für einen einzelnen Farbkanal in 24-BitFarbe) subtrahiert wird. Wenn Sie sich die zwei Farben eines Kanals in einer bestimmten Zeile ansehen, werden Sie feststellen, dass sie addiert wiederum 255 ergeben.
Farben identifizieren, Kurzfassung Man kann lernen, Farben sowohl auf dem Bildschirm und in Stylesheet-Regeln auf den ersten Blick zu erkennen. Hierfür ist allerdings beständiges Üben nötig. Wir können Ihnen hier nur die richtige Richtung zeigen: • Mit genug Erfahrung reicht ein Blick auf den sechsstelligen Hexadezimalcode (z.B. #00009C), um darin die Werte der einzelnen Kanäle zu erkennen. • Die Fähigkeit, hexadezimale Zahlen im Kopf in Dezimalzahlen umzurechnen, ist zwar ganz nett, aber selten wirklich nötig. Wenn Sie sich damit abfinden können, A, B, C, D, E und F als Zahlen zu betrachten, sind Sie schon gut dabei. Der amerikanische Satiriker und Mathematiker Tom Lehrer brachte es so auf den Punkt: »Keine Panik – hexadezimal ist eigentlich das Gleiche wie dezimal … nur mit sechzehn Fingern.« • Je höher der Wert einer Farbe in allen drei Kanälen ist, desto heller ist sie.
Farbenlehre und Webfarben
|
151
• Je größer die zusammengefassten anteiligen Unterschiede zwischen den Kanalwerten sind, desto höher ist die Sättigung der Farbe. • Die Identifizierung der Farben wird einfacher, wenn Sie das Farbrad im Kopf in primäre und sekundäre Farbbereiche unterteilen. Der Rest ist Arithmetik. • Wenn nichts mehr geht, verwenden Sie ein Pipettenwerkzeug zum Kopieren und Einfügen der gewünschten Farbe.
Abbildung 9-1: ColorZilla stellt ein Pipettenwerkzeug zur Verfügung, mit dem Farbwerte gemessen und kopiert werden können.
Die in Abbildung 9-1 gezeigte Firefox-Erweiterung ColorZilla (https://addons.mozilla.org/ en-US/firefox/addon/271) ist eine Möglichkeit. Nach der Installation kann ColorZilla über einen kleinen Button in der Statusleiste des Browsers aktiviert werden. Nach dem An-
152
|
Kapitel 9: Farben und Hintergründe
klicken verwandelt sich der Mauszeiger in ein Pipettenwerkzeug. Für Mac-User gibt es außerdem das (etwas kompliziertere) Programm DigitalColor Meter aus dem Ordner Dienstprogramme.
Monitore und die »websichere« Farbpalette Im Abschnitt zu CSS-Längeneinheiten (siehe im Abschnitt »CSS-Maßeinheiten« auf Seite 34) haben wir bereits über die Vielfalt möglicher Bildschirmauflösungen gesprochen und erklärt, wie Farbwerte in einem Stylesheet definiert werden. Auf die möglichen Ergebnisse kommen wir jetzt zu sprechen. Die Farbdarstellung aller existierenden Anzeigetechnologien basiert auf Annahmen über die Umgebung, in der sie benutzt werden. Das Vertrauen auf die Farbwiedergabe eines Monitors hängt von dessen Herstellungsdatum, der Qualität der Bauteile und der Herstellungsqualität ab. Aufgrund dieser Unterschiede sehen die meisten Menschen nur selten die gleichen Farben. Nur ein verschwindend kleiner Teil der möglichen hexadezimalen Farbwerte wird als websicher betrachtet. Einen Überblick sehen Sie in Tabelle 9-2. Tabelle 9-2: »Websichere« Farben Hexadezimal
8-Bit-dezimal
Prozentwert1
00
0
0%
33
51
20 %
66
102
40 %
99
153
60 %
cc
204
80 %
ff
255
100 %
Die websichere Farbpalette bekam ihren Namen, weil die hiermit definierbaren 216 Farben auch mit der schwachen Grafikhardware der 1990-Jahre recht genau wiedergegeben werden konnten. Auch heute hat die websichere Palette noch Bedeutung, allerdings aus einem anderen Grund: Ältere Standard-LCD-Monitore sind nicht in der Lage, einen 24-Bit-Farbverlauf in voller Farbtiefe wiederzugeben, wie in Abbildung 9-2 zu sehen ist. HD-fähige LCD-Monitore und Röhrendisplays mit der passenden Grafikhardware haben normalerweise nicht die Probleme billiger Geräte. Sie werden allerdings bestenfalls von der Hälfte der entwickelten Welt wirklich benutzt. Die Herausforderungen bei einer originalgetreuen Farbwiedergabe betreffen auch Bilder und die darin eingebetteten Farbprofile (siehe im Abschnitt »Mit Farbprofilen arbeiten« auf Seite 189).
1 Obwohl sie als Teil der CSS 1-Spezifikation definiert ist, konnte sich die Verwendung von Prozentwerten nie richtig durchsetzen. Sie werden hier nur der Vollständigkeit halber angegeben.
Farbenlehre und Webfarben
|
153
Abbildung 9-2: Ältere Standard-LCD-Monitore machen keine gute Figur bei der Darstellung von Farbverläufen.
Eigene Farbpaletten erstellen Wenn Sie Auftragsarbeiten ausführen oder fest bei einer Firma angestellt sind, stehen die Chancen recht gut, dass mindestens zwei Palettenfarben bereits feststehen. Um diese Wahl auszugleichen, gibt es zwei beliebte systematische Methoden: Mathematik und die Verwendung »gefundener« Farben. Beim mathematischen Ansatz werden sogenannte Farb-Dyaden, -Triaden oder -Tetraden gebildet, die eine offensichtliche Beziehung zu den Ausgangsfarben haben. Im Falle einer Triade geht man davon aus, dass zwei Farben bereits feststehen. Nehmen wir an, dies seien die stets beliebten HSB-Werte 205 und 105 – Aquamarin und ein helles Gelbgrün. Der Mittelwert für diese beiden Farben liegt bei 155 , einer Farbe, die als »Seegrün« bezeichnet wird. Als dritte Farbe der Triade kann entweder dieser Farbton oder seine Komplementärfarbe eingesetzt werden. Jetzt gilt es nur noch, die richtige Sättigung und Helligkeit für diese Farbe zu finden und sie in Ihr Design zu integrieren. Die beliebteste Alternative zur Berechnung von Winkeln besteht in der Verwendung »gefundener« Farben. Nehmen Sie hierfür ein attraktives Foto, und benutzen Sie ein Pipettenwerkzeug, um die Farben darin zu messen. Danach entscheiden Sie nach Gefühl, welche dieser Farben am besten zu Ihrer Palette passt. 154
|
Kapitel 9: Farben und Hintergründe
Die Erstellung von Paletten wird wesentlich detaillierter auf der Website zu diesem Buch besprochen.
CSS-Hintergründe CSS-Hintergründe können für viele verschiedene Elemente definiert werden. Gibt es eine Elementbox, können Sie fast immer auch einen Hintergrund dafür festlegen. Am besten fangen wir mit einem Überblick über die CSS-Eigenschaften an, mit denen sich das Erscheinungsbild von Hintergründen steuern lässt (siehe Tabelle 9-3). Tabelle 9-3: CSS-Eigenschaften für Hintergründe (Standardwerte sind fettgedruckt dargestellt) Eigenschaft
Zweck
background
Kurzschrift-Eigenschaft, fasst die Werte mehrerer Einzeleigenschaften zusammen.
background-attachment
Legt fest, ob der Hintergrund zusammen mit dem restlichen Inhalt gescrollt werden soll oder nicht.
•
fixed
•
scroll
Definiert die Hintergrundfarbe
•
[Farbwert]
•
transparent
•
none
•
[URI]
•
[Längenangabe]
•
[Prozentwert]
background-color
background-image
background-position
background-repeat
Definiert das Hintergrundbild, das ggf. vor einer definierten Hintergrundfarbe angezeigt wird. Definiert die Position des Hintergrundbildes im umgebenden Element. Bei der Angabe zweier Werte werden diese durch ein Leerzeichen getrennt.
Legt fest, ob und wie das Hintergrundbild »gekachelt« werden soll.
Werte
•
bottom
•
center
•
left
•
right
•
top
•
no-repeat
•
repeat
•
repeat-x
•
repeat-y
Die richtigen Werte für »background-position« Wird ein Wert für background-position angegeben, besteht er i.d.R. aus zwei Teilen: dem Abstand von der linken Kante und dem Abstand von der Oberkante des Elements. Werden Längeneinheiten wie px oder em verwendet, sind die Ergebnisse leicht vorherzusagen. Wird nur ein Wert angegeben, gilt dieser für die horizontale Position. Der fehlende Wert wird
CSS-Hintergründe
|
155
automatisch als center bzw. 50% ergänzt. Das Hintergrundbild wird um die angegebenen Werte von der linken oberen Ecke des Elements verschoben dargestellt. Negative Werte sind möglich und sorgen dafür, dass das Hintergrundbild ganz oder teilweise außerhalb seines Elements liegt und nicht dargestellt wird. Bei gekachelten Hintergründen wird das Startbild möglicherweise außerhalb des sichtbaren Bereichs platziert. Bei der Angabe von Schlüsselwörtern oder Prozentwerten ändert sich das Verhalten von background-position. Prozentwerte definieren nicht nur den Abstand von der linken oberen Ecke des Elements, sondern auch die Position im Hintergrundbild selbst. Auf diese Weise ist es möglich, ein Hintergrundbild in der Mitte des Elements zu zentrieren. Nehmen wir beispielsweise die Werte 33% 33%. Sie bezeichnen einerseits einen Punkt, der um ein Drittel der Höhe und Breite des Elements von dessen linker oberer Ecke entfernt ist. Gleichzeitig bezeichnet der Wert den gleichen Punkt im Hintergrundbild. Für die Darstellung werden diese beiden Punkte zur Deckung gebracht, wie in Abbildung 9-3 zu sehen ist.
Abbildung 9-3: Ein Hintergrundbild, das mit der Einstellung »background-position: 33% 33%;« definiert wurde. Die Hilfslinien dienen nur der Illustration.
Die für background-position möglichen Schlüsselwörter entsprechen den Werten 0% (left bzw. top), 50% (center bzw. center) und 100% (bottom bzw. right). Für Designer, die die Drittelregel oder den Goldenen Schnitt in ihren Designs einsetzen möchten, birgt diese Methode einige Schwierigkeiten. Was machen Sie beispielsweise, wenn das Bild in Abbildung 9-3 an den Koordinaten 33% 33% zentriert werden soll? Die einzige effektive Methode besteht darin, die Höhe und Breite Ihres Layouts ausdrücklich festzulegen, was neue Herausforderungen mit sich bringt. Wenn es nur darum geht, Hintergrundbilder zu zentrieren, ist der Aufwand vermutlich zu groß.
156
|
Kapitel 9: Farben und Hintergründe
In CSS 3 wird es vermutlich die Eigenschaft background-size geben, mit der die Größe des Hintergrundbildes gesteuert werden kann. Im Moment wird sie aber von den meisten Browsern noch nicht unterstützt.
Die CSS-Kurzschrift-Eigenschaft »background« Wie margin, border, padding und font ist auch background eine sogenannte KurzschriftEigenschaft. Die Werte für einzelnen Eigenschaften werden in der folgenden Reihenfolge, durch Leerzeichen getrennt, angegeben: background-color background-image background-repeat background-position background-attachment
Wie die anderen Kurzschrift-Eigenschaften so kann auch background eine Menge Platz sparen, hat aber auch einen entscheidenden Nachteil: Werden einzelne Werte nicht angegeben, können sich die Ergebnisse unterscheiden.
Hintergrundbilder erstellen Tatsächlich kann die Erstellung von Hintergrundbildern schwieriger sein als ihre Verwendung in einer Website. Wie in Abbildung 9-4 gezeigt ist, gibt es verschiedene Arten von Hintergrundbildern, die jeweils ihre eigenen technischen Probleme aufwerfen.
Abbildung 9-4: Beliebte Stile für Hintergrundbilder
»Faux Columns« Als »Faux Columns« bezeichnet man eine Methode, verschieden hohe Spalten mithilfe von Hintergrundfarben und -bildern gleich hoch erscheinen zu lassen. Im Hintergrundbilder erstellen
|
157
Abschnitt zu mehrspaltigen Layouts (siehe im Abschnitt »Mehrspaltige Layouts implementieren« auf Seite 91) wird gesagt, dass es möglich ist, ein Element an die Höhe seines Inhalts anzupassen. Meistens ist der Aufwand aber nicht gerechtfertigt. Wird dem Container-Element für eine Spalte ein Hintergrundbild zugewiesen, das dieses Verhalten imitieren soll, ist das Ergebnis eine Illusion, die meist genauso gut funktioniert. Manchmal ist die Spaltenhöhe in einem Layout nicht mit Sicherheit vorhersagbar. In solchen Fällen kann diese Technik auch verwendet werden, um anstelle der Eigenschaften border-left und border-right vertikale Trennlinien zwischen den Spalten zu erzeugen. Hintergrundtexturen und -muster Texturen und Muster sind als Hintergründe recht beliebt, in manchen Jahren mehr, in anderen weniger. Sie können einem Design eine gewisse »Patina« verleihen, als sei der Inhalt schon lange oder häufig verwendet worden. Diese Hintergründe bestehen entweder aus gekachelten (vertikal und/oder horizontal wiederholten) Bildern oder aus großen Einzelbildern. Nicht-wiederholte Motive und Symbole Hierunter versteht man Muster, die deutlich weniger detailliert sind und meistens in einer bestimmten Ecke des Browser-Ansichtsbereichs verankert werden. Schattenwürfe und Gel-Effekte Schattenwürfe vermitteln den Eindruck, dass bestimmte Elemente sich näher am Benutzer befinden als der eigentliche Ansichtsbereich und sind ungefähr so beliebt, wie es strukturierte Hintergründe einmal waren. Gel-Effekte werden oft für Links und Buttons verwendet – besonders auf Websites, die sich als Teil der »Web 2.0«-Bewegung verstehen. Beide Effekte werden auf ähnliche Weise erstellt. Abgerundete Ecken Die Techniken zur Erstellung abgerundeter Ecken unterscheiden sich vollkommen von der Methode für Schattenwürfe. Die Herausforderungen an den Gestalter bei der Implementierung sind dagegen sehr ähnlich. Diese Hintergründe können um Schrift ergänzt werden, die ebenfalls als Grafik vorliegt. Oftmals wird für die Implementierung grafischer Schriften das im Abschnitt »Grafische Schriften und das Fahrner Image Replacement« auf Seite 162 beschriebene »Fahrner Image Replacement« – eine Methode zur Ersetzung von Text durch Bilder – eingesetzt.
»Faux Columns« Stellen Sie sich ein zweispaltiges Layout vor, bei dem die Spalten eine variable Höhe haben können. Unabhängig von den verwendeten CSS-Regeln ergibt sich ein Problem: Die Spalten haben so gut wie immer unterschiedlich viel Inhalt und sind damit unterschiedlich hoch. Die Regel ... { overflow: auto; height: 1%; } für das Container-Element der Spalten gibt Ihnen ein weiteres Element, für das Hintergründe definiert werden können.
158
|
Kapitel 9: Farben und Hintergründe
Trotzdem bleibt die ursprüngliche Aufgabe bestehen: beide Spalten so aussehen zu lassen, als hätten sie die gleiche Höhe. Sollen die beiden Spalten unterschiedliche Hintergründe haben, verwenden Sie die folgenden Arbeitsschritte: 1. Definieren Sie für den Container, der die Spalten enthält, die Regel #spalten_container { overflow: auto; height: 1%; }. Dieser Schritt ist nicht unbedingt nötig, er erhöht aber die Flexibilität, mit der Sie das Layout-Markup umsetzen. 2. Um Rundungsfehlern, Änderungen durch den Benutzer und zukünftigen Änderungen am Layout zu begegnen, sollte das Hintergrundbild breiter sein als die tatsächlich benötigte Breite. Diese hängt normalerweise von Ihrem Layout ab und davon, wie Sie das Hintergrundbild in Ihr Layout einbauen. Wenn Sie mit einem flexiblen Layout (siehe Kapitel 6) arbeiten, sollte das Hintergrundbild deutlich größer sein als die geplante Layoutbreite. 3. Um Bandbreite zu sparen, sollten Hintergrundbilder, die zu Mustern zusammengesetzt werden, nicht höher sein als für die Kachelung nötig. 4. In den meisten Fällen wollen Sie die proportionale Breite Ihrer Spalten berechnen. Davon ausgenommen sind Situationen, in denen eine Spalte unabhängig von Änderungen durch den Benutzer oder das verwendete Benutzerprogramm eine statische Breite erhalten soll. 5. Für flexible Layouts füllen Sie die gewünschten Bereiche proportional. Soll mindestens eine Spalte eine feste Breite erhalten, berechnen Sie die Breite des Bereichs für diese Spalte wie folgt: Addieren Sie die Breite der Spalte und des gewünschten Zwischenraums. Soll stattdessen zwischen zwei Spalten eine grafische Trennlinie auf ganzer Höhe realisiert werden, platzieren Sie diese an der X-Koordinate, an der sich die beiden farbigen Hintergrundbereiche berühren würden. 6. Hierfür kommen folgenden Eigenschaften zum Einsatz: background-color
Als Wert sollte normalerweise die gewünschte Hintergrundfarbe für die Hauptspalte gewählt werden. background-repeat
Vorsichtigen Leuten wird hier der Wert repeat-y empfohlen. background-position
Unabhängig davon, ob es sich um ein statisches oder proportionales Layout handelt, verwenden Sie hier einen ähnlichen Wert für die x-Koordinate (den ersten der beiden Werte) wie für die Breite des farbigen Bereichs. Bei festen Layouts entspricht dieser Wert der umgekehrten Breite für den Raum zwischen den Spalten. Ist dieser beispielsweise mit einer Breite von 5 Pixeln definiert, würde die Definition so lauten: background-position: --5px 0. Normalerweise würde Ihr Spaltenhintergrund keine transparenten Pixel enthalten und der background-color-Wert für das Container-Element der Spalten entspräche der Farbe für die Hauptspalte. Eine Ausnahme tritt auf, wenn die Spaltenfarben als Hilfe zur Hintergrundbilder erstellen
|
159
Ortsbestimmung verwendet werden sollen. Oftmals lassen sich in solchen Fällen Ressourcen sparen, indem ein einzelnes Hintergrundbild verwendet wird, das für die proportionale Spalte transparente Pixel verwendet. Die Hintergrundfarbe wird hierbei (ortsabhängig) vom background-color-Wert des Container-Elements für die Spalten definiert. Diese Methode funktioniert für zweispaltige Layouts recht gut. Bei dreispaltigen Layouts mit variabler Breite ist die Sache komplizierter. (Hintergründe mit fester Breite lassen sich normalerweise auf das body-Element beschränken.) Wird bei einem dreispaltigen Layout für jede Spalte ein eigener Hintergrund benötigt, verwenden Sie zwei Hintergrundbilder: eines für body oder das breiteste Container-Element und ein weiteres für den Container, der die zwei anderen Spalten enthält (siehe Kapitel 6). Danach können die beschriebenen Schritte zweimal hintereinander durchgeführt werden.
Gekachelte Hintergrundtexturen und -muster Standardmäßig werden Hintergrundbilder automatisch gekachelt dargestellt. Die linke obere Ecke des Ausgangsbildes wird hierbei bündig an der linken oberen Ecke der umgebenden Elementbox ausgerichtet. Gekachelte Hintergründe sind schwerer umzusetzen, wenn ein asymmetrisches Ausgangsbild verwendet wird, können aber helfen, Bandbreite zu sparen. Um sie zu erstellen, können Benutzer von Adobe Photoshop die folgende (mit viel Zoomen und Schielen verbundene) Methode verwenden: 1. Verwenden Sie Filter → Sonstige Filter → Verschiebungseffekt, um die Nahtstellen zu zentrieren, die durch den Mangel an Symmetrie im Ausgangsbild entstehen. Die Nahtstellen sollten die Form eines Kreuzes darstellen. 2. Versehen Sie das Ausgangsbild mit zwei angrenzenden Duplikaten (eines für jede Achse). Die Verwendung eigener Hilfslinien (Ansicht → Einblenden → Magnetische Hilfslinien) kann diesen Arbeitsschritt stark erleichtern. 3. Reduzieren Sie die drei Kopien des Ausgangsbildes auf eine gemeinsame Ebene. 4. Verwenden Sie eine Kombination aus Kopierstempel, Reparaturpinsel und BewegenWerkzeug, um die Nahtstellen zu verbergen. Vermeiden Sie Weichzeichnungsfilter. Diese schaffen mehr Probleme, als sie lösen, es sei denn, sie werden nur auf einen winzigen Bereich des Bildes angewandt. Das richtige Werkzeug finden Sie am besten durch Erfahrung und Ausprobieren. Dieser Schritt sollte zuerst an den Stellen durchgeführt werden, an denen sich die Nahtstellen mit den Kanten Ihres Ausgangsbildes berühren. Einige dieser Aktionen sind nur für die Duplikate nötig. Fügen Sie diese Bereiche anschließend in die entsprechenden Regionen des Originals ein. 5. Beschneiden Sie das Bild wieder auf seine ursprüngliche Größe. 6. Wiederholen Sie die Schritte 2 bis 4 im zentralen Bildbereich. Machen Sie sich auf häufige Verwendung des Rückgängig-Befehls und der Protokoll-Palette gefasst.
160
|
Kapitel 9: Farben und Hintergründe
7. Speichern Sie das Bild, laden Sie es hoch, und weisen Sie es dem gewünschten Element zu. Die Standardwerte für Hintergründe sollten für diese Aufgabe ausreichen. Symmetrische Bilder sollten ebenfalls verschoben werden – entweder bereits bei der Erstellung oder mithilfe der Eigenschaft background-position. Ansonsten erscheinen oberhalb und links des Elements möglicherweise leere Bereiche.
Größere Hintergrundtexturen und nicht wiederholte Embleme Größere Hintergrundbilder können leicht aus schon vorhandenem Material erstellt werden. Allerdings verbrauchen sie meist deutlich mehr Bandbreite. Der Trick ist daher, den bestmöglichen Kompromiss zwischen Dateigröße, Bildgröße (Höhe/Breite) und nützlichen Details zu finden. Um kleinere Dateien zu bekommen, muss man entweder die Bildgröße oder den Detailreichtum verringern (oder beides!). Wird ein Hintergrund für das body-Element definiert, wird die Herausforderung sogar noch größer, da das Hintergrundbild mindestens 1680 × 1050 Pixel groß sein muss. Eine Größe von 1920 × 1200 Pixeln (Full HD, 1080p) ist nur in den allerwenigsten Fällen nötig. Zwar gibt es seltene Fälle, in denen Ihr großes Hintergrundbild mehrere Male größer ist als das Element, für das es benutzt wird, oder exakt auf ein Element mit garantiert festen Maßen abgestimmt ist. Ansonsten sollte Ihr Stylesheet ungefähr so aussehen: #meinElement { background-image: url(/pfad/zum/bild.png); background-attachment: fixed; background-position: 50% 50%; }
Wenn Sie ein Hintergrundbild erstellen, das ein Emblem enthält (z.B. ein Ideogramm, eine geometrische Form, eine berühmte Illustration aus der Public Domain oder sonst einen Teil der visuellen Identität des Website-Betreibers), wird dieses fast immer kleiner sein als das Ausgangsbild für ein gekacheltes Muster. Bei der Erstellung eines solchen Hintergrundbildes und der entsprechenden CSS-Regeln sollten Sie sich an die folgenden Richtlinien halten: • Verwenden Sie mehr Kontrast als für ein Hintergrundmuster. Dabei sollte die Lesbarkeit des darüberliegenden Inhalts nicht beeinträchtigt werden. • Ist das Hintergrundbild deutlich kleiner als die Ausmaße des Elements, sollten Sie das Bild an einer Seite oder Ecke des Elements verankern. Die Ergebnisse werden dadurch leichter vorhersagbar. • In den meisten Fällen ist die Regel background-attachment: fixed am besten geeignet. • Stellen Sie die Lesbarkeit eines Elements, dessen Hintergrundbild an der Unterkante verankert ist, sicher, indem Sie den Wert für padding-bottom ungefähr auf die tatsächliche Höhe des Hintergrundbilds setzen.
Hintergrundbilder erstellen
|
161
Schattenwürfe, Gel-Effekte und abgerundete Ecken Um Schattenwürfe, Gel-Effekte und abgerundete Ecken zu erstellen, können Sie entweder den Effekte-Dialog der Ebenenpalette von Photoshop verwenden oder eine umfangreiche Kombination aus Werkzeugen und Filtern Wir betrachten diese drei Hintergrund-Effekte separat, weil hierbei ein paar Unwägbarkeiten auftreten können. So kann es sein, dass ein Designer, der diese Effekte einsetzt, ein Layout mit festen Breiten voraussetzt. Dadurch kann es passieren, dass die Ecken von Schattenwürfen über die sichtbaren Layoutkanten hinausgeschoben werden (normalerweise über die Ober- und Unterkante des Ansichtsbereichs) oder dass der Gestalter gezwungen wird, schlechten Markup-Code zu schreiben. Der Grund für diese Probleme liegt im Fluss der Elemente selbst: Abgesehen von PluginInstanzen oder Bildern ist es unmöglich, die Höhe eines Elements sicher vorherzusagen. Hintergrundbilder können von aktuellen Browsern nicht beliebig skaliert werden. Daher müssen Effekte, die an vorhersagbaren Stellen im Layout erscheinen müssen (z.B. bei abgerundeten Ecken oder den Ecken von Schattenwürfen) einzeln platziert werden, wenn die Ausmaße des Elements nicht bekannt sind. Der am Anfang von im Abschnitt »Angewohnheit 1: In der Kürze liegt die Würze« auf Seite 50 gezeigte Markup- und CSS-Code ist ein Negativbeispiel für das Prinzip der Einfachheit. In Firefox und Safari ist es möglich, abgerundete Ecken mit proprietären CSS-Eigenschaften zu definieren (-moz-border-radius bzw. -webkit-border-radius). Der Internet Explorer hat momentan leider nichts Vergleichbares im Angebot. Diese beiden Eigenschaften dienen als experimentelle Vorabimplementierung der in CSS 3 geplanten Eigenschaft border-radius.
Grafische Schriften und das Fahrner Image Replacement In Kapitel 12 finden Sie umfassende Informationen zur Web-Typografie. Im Bezug auf Hintergrundbilder sind dabei zwei Dinge zu beachten: der Mangel an Schriften, die im Web benutzbar sind, und die Vorteile, die das Anti-Aliasing gerade bei großen Schriften bringt. Anhand von Inline- und Hintergrundbildern haben Designer die Möglichkeit, attraktive Typografie auch im Web umzusetzen, schließlich sind die Browser seit 1993 in der Lage, Bilder darzustellen. In der ersten Jahreshälfte von 2002 arbeitete eine Reihe von WebExperten (mich eingeschlossen) unabhängig an Techniken, um grafische Schriften nicht mehr im Markup, sondern im Stylesheet zu definieren. Allgemein werden diese Methoden als Fahrner Image Replacement (FIR) bezeichnet oder als Fahrner-Methode zur Bildersetzung. Sie sind benannt nach Todd Fahrner, einem CSS-Pionier, der als einer der Ersten seine Ideen zur Bildersetzung ausarbeitete und publizierte. Beispiele für die Verwendung dieser Technik finden Sie in Abbildung 9-5.
162
|
Kapitel 9: Farben und Hintergründe
1
2
3
Abbildung 9-5: Drei Schritte von einer einfachen Überschrift zu einer mit der FIR-Methode realisierten grafischen Überschrift: (1) zeigt die ursprüngliche Überschrift, (2) zeigt die Überschrift mit ihrem neuen Hintergrundbild, und (3) zeigt das fertige Resultat, nachdem die ursprüngliche Überschrift per »textindent« aus dem sichtbaren Bereich verschoben wurde.
Das Hauptargument für die Verwendung der FIR-Methode ist, dass ein Bild nur dann im Inhalt eines Dokuments auftauchen sollte, wenn es tatsächlich Teil des Inhalts ist. Wie kann man die Vorteile von Bildern also auch dann nutzen, wenn man sie in die Präsentationsschicht verschiebt, wo sie hingehören? Es ist offensichtlich, dass die Hintergrund-Eigenschaften hierbei eine Rolle spielen. Allerdings reichen sie allein nicht aus. Der Text bleibt weiterhin sichtbar (siehe Bild 2 in Abbildung 9-5). Um das Problem zu lösen, brauchen wir einen Weg, den Text aus dem sichtbaren Bereich zu entfernen, ohne Änderungen am Markup-Code vornehmen zu müssen. Zuerst versuchte man, den zu versteckenden Text mit einem span-Element zu umgeben und dieses per display: none zu verbergen. Dies verhindert aber die Darstellung für Benutzer von Hilfstechnologien. Die Überschrift wird nicht »vorgelesen«, weil mit display: none kennzeichnete Elemente ignoriert werden. Weitere Bildersetzungen wurden getestet, die aber alle mit zusätzlichem Markup arbeiteten. Jede Methode setzte hierfür eigene CSS-Regeln ein (z.B. visibility oder position), um den Textinhalt aus dem sichtbaren Bereich zu entfernen. Nach einer Weile hatte der Entwickler Mike Rundle die Idee, die Eigenschaft text-indent zu verwenden, um nur den Text zu verschieben. Fast zur gleichen Zeit kam Russ Weakley auf den Gedanken,
Grafische Schriften und das Fahrner Image Replacement
|
163
winzigen Text vor einem Hintergrund mit der gleichen Farbe zu verstecken. Dabei ließ er genügend Platz am Rand des Elements, wodurch der Text komplett unsichtbar wurde.
Die FIR-Stylesheet-Regeln Hier ist der CSS-Code für die Methoden von Rundle und Weakley. Gegeben sei eine Überschrift zweiten Grades mit dem Inhalt Lorem ipsum dolor sit amet, consectetur adipiscing elit und ein Hintergrundbild mit einer Höhe von 30 Pixeln: /* *** Rundle-Methode (Phark) *** */ h2 { height: 30px; margin: 0; text-indent: –10000px; background-image: url(/pfad/zum/bild.png); background-repeat: no-repeat; } /* *** Weakley-Methode *** */ h2 { height: 1px; margin-bottom: –1px; padding-top: 30px; color: #fff; background-color: #fff; background-image: url(/pfad/zum/bild.png); background-repeat: no-repeat; font-size: 1px; line-height: 1; }
Die Weakley-Methode benötigt deutlich mehr Code, umgeht aber ein böses Darstellungsproblem im Internet Explorer 6. Es tritt auf, wenn text-indent auf einen Link angewandt wird, der als Float definiert wurde. Der Text selbst folgt dem Wert von text-indent, aber seine Unterstreichung nicht. Wir sollten nicht verschweigen, dass die Weakley-Methode, die mit kleinem, verstecktem Text arbeitet, möglicherweise zu Problemen mit Suchmaschinen führen kann. Das gilt besonders dann, wenn sie nur verwendet wird, um die Seite zur Suchmaschinenoptimierung (SEO) mit Stichwörtern aufzupumpen.
Nachteile der FIR-Methode Das Fahrner Image Replacement hat zwei große Nachteile: Zum einen haben Gestalter keinen Einfluss auf die Darstellung der Hintergrundbilder in Druckseiten (wo sie vermutlich überhaupt nicht angezeigt werden), zum anderen gibt es einen kleinen Kreis von Benutzern, die die Darstellung von Bildern deaktiviert haben. Diese sind nicht in der Lage, die aus dem sichtbaren Bereich verschobene Schrift zu lesen.
164
|
Kapitel 9: Farben und Hintergründe
Nur die wenigsten Benutzer wissen, dass mit der FIR-Methode ersetzte Inhalte immer noch ausgewählt und in die Zwischenablage kopiert werden können. Daher sollten Inhalte, die wahrscheinlich kopiert werden (z.B. Kontaktinformationen) immer in normalem Text dargestellt oder zumindest wiederholt werden.
Die Serverlast mit Sprites verringern Ein Jahr, nachdem die FIR-Methode bekannt wurde, veröffentlichte Dave Shea im Webzine A List Apart einen Artikel, der eine Idee aus der Zeit der 8-Bit-Computerspiele wiederbelebte: Sprites. In den Spielen wurde sie meist verwendet, um verschiedene »Landschaften« oder »Szenen« in einer gemeinsamen Datei zu speichern. Das Programm stellte dann, je nach Situation, nur den passenden Teil des Bildes dar. Gestalter können diesen Ansatz verwenden, um verschiedene ähnliche Hintergrundbilder in einer gemeinsamen Datei zu speichern, um so die Zahl der Serveranfragen und den Wartungsaufwand gering zu halten. Die Verwendung von Sprites bietet sich beispielsweise für Navigationslinks an. In vielen Fällen können die Grafiken für inaktive (:link) und aktive (:hover) Linkzustände in einer Datei kombiniert werden. Nehmen Sie beispielsweise das Navigationsmenü in Abbildung 9-6. Die verschiedenen Einträge sind als grafische Schriften realisiert, die mit der FIR-Methode eingebunden werden, da die verwendete Schrift nicht von allen Browsern und Betriebssystemen zuverlässig unterstützt wird.
Abbildung 9-6: Das gewünschte Ergebnis der Verwendung von Sprites für ein Navigationsmenü
Hierbei gibt es keine Regel, wie die Ausgangsgrafik angelegt ist. Normalerweise würde ich die »aktiven« Linkzustände wohl unter den neutralen platzieren. Letztendlich können Sie das aber selbst entscheiden. Wichtig ist nur, dass Sie sich die Ursprungskoordinaten für jeden Teil notieren, da diese später als Werte für background-position wichtig sind. Wenn Sie grafische Schriften aus einer gemeinsamen Datei mit der FIR-Methode einsetzen wollen, führen Sie nacheinander die folgenden Schritte aus: 1. Geben Sie Ihrer Navigation das gewünschte Layout (siehe im Abschnitt »Rezept für die primäre Navigation« auf Seite 125). Die Serverlast mit Sprites verringern
|
165
2. Geben Sie für die Listeneinträge mit den Navigationslinks und für die :hover-Pseudoelemente der Links denselben background-image-Wert an. Jetzt sollte für jeden Listeneintrag das gleichen Hintergrundbild zu sehen sein (siehe Abbildung 9-7). 3. Definieren Sie für die einzelnen Links und ihre Pseudoklassen (z.B. #nav li { ... } und #nav li a:hover { ... }) die passenden Werte für background-position. Für die Demonstration dieser Technik auf der Website zu diesem Buch kamen die folgenden Stylesheet-Regeln zum Einsatz: #nav li { #nav li a { #nav li, #nav li a { #nav li a:link, #nav li a:visited { #navUeber #navKontakt #navForum #navGalerie
Abbildung 9-7: Das Hintergrundbild für ein mit Sprites realisiertes Navigationsmenü
166
|
Kapitel 9: Farben und Hintergründe
KAPITEL 10
(Daten-)Tabellen
Altgediente Webentwickler erinnern sich noch an die Bücher, die empfahlen, das Layout mit table-Elementen umzusetzen. Früher war dies die einzige verlässliche Layout-Methode, mit der Browser umgehen konnten. Und wie in der Diskussion dreispaltiger Layouts (siehe im Abschnitt »Mehrspaltige Layouts implementieren« auf Seite 91) bereits angesprochen wurde, scheinen Tabellenlayouts ja auch vergleichsweise einfach umsetzbar zu sein. Tun Sie das nicht!
Nachteile von Layout-Tabellen Layout-Tabellen bringen nur wenige unliebsame Überraschungen mit sich, doch ihre Verwendung geht auf Kosten der Usability und Wartungsfreundlichkeit Ihrer Site. Tabellenbasierte Layouts sind bei der Erstellung einer neuen Site vielleicht einfacher zu entwickeln. Doch sobald die Site aktualisiert werden muss, ein Redesign oder einfach nur ein Wartungs-Update ansteht, bereiten Tabellen schnell Kopfschmerzen.
Quellcode-Reihenfolge: Die Quadratur des Kreises Bei der Verwendung von Layout-Tabellen sind Sie gezwungen, die gesamte Website um einen bestimmten Rendering-Algorithmus (den für Tabellen) herum zu bauen. Dieser hat eigentlich die Funktion, tabellarische Daten darzustellen. Deshalb ist die Inhaltsstruktur auch deutlich besser für die Darstellung von Tabellenkalkulationen geeignet als für Dokumente mit Textpassagen. (Sie schreiben Ihren Bericht oder ein Memo ja auch nicht mit Microsoft Excel, oder?) Die Verwendung von Layout-Tabellen hat besonders für die Benutzer von Hilfstechnologien bedeutende Nachteile. Da deren Hersteller die Intention der Webentwickler nicht kennen können, werden die Inhalte von Tabellen in Bildschirmleseprogrammen, BrailleZeilen etc. gemäß der Quellcode-Reihenfolge dargestellt. Das hat unter anderem zur Folge, dass auf Hilfe angewiesene Benutzer auch 15 Jahre nach der ersten Implementierung von Tabellen noch davon ausgehen, dass die Navigation der Site sich am Seitenanfang befindet, unabhängig davon, ob das wirklich sinnvoll ist. |
167
Auf Websites, in denen die linke Spalte den Inhalt der Seitenleiste enthält, wird die Wichtigkeit des Inhalts sogar noch stärker auf den Kopf gestellt. Stellen Sie sich vor, Sie müssten sich erst durch dreihundert unzusammenhängende Wörter unwichtigen Mülls graben, bevor auch nur der Titel des Dokuments, geschweige denn der Inhalt, in Sichtweite kommt. Mit diesen Dingen müssen sich die Benutzer von Hilfstechnologien täglich herumschlagen.
Vom CSS-Zen bleibt nur ein Mythos Bei richtiger Anwendung bietet das Prinzip des CSS-Zen (siehe im Abschnitt »Die Funktionsprinzipien des CSS-Zen« auf Seite 60) unbegrenzte Redesign-Varianten. Ermöglicht wird diese Flexibilität durch strukturelles Markup und die korrekte Verwendung von class- und id-Werten. Hierdurch wird wiederum die Implementierungszeit deutlich verringert. So habe ich für drei der letzten vier Redesigns von henick.net jeweils nur ein paar Stunden gebraucht. Wenn Website und Seiten eine sinnvolle Struktur haben und die Anforderungen an den richtigen Stellen übererfüllt wurden (Overbuilding), so können selbst riesige Websites in ein paar Tagen mit einem komplett neuen Look and Feel versehen werden. Bei der Verwendung von Tabellen für das Layout ist das nicht möglich. Eigentlich sollte das Design das vorhandene Markup verschönern. Bei Layout-Tabellen wird das Design jedoch vom Markup diktiert. Redesigns werden dadurch auf Änderungen von Farben und Akzenten beschränkt. Sobald neue Inhalte hinzukommen, alte entfernt werden oder eine größere Layoutänderung ansteht, müssten vollkommen neue Templates für die Website erstellt werden.
Die unvermeidliche Abhängigkeit von Templates Solange Sie nicht Berge von Templates für die Website verwenden, tendiert die Flexibilität von Tabellen-Layouts gegen Null. Gerade in größeren Firmen, in denen ein detaillierter Genehmigungsprozess durchlaufen werden muss, stehen Tabellen für ein Design, das ab dem ersten Tag keinerlei Änderungen mehr zulässt. Allein das ist schon frustrierend. Was passiert aber, wenn es ein größeres Problem mit der Site gibt? Hiervon betroffene Besucher sind schon die zweite Gruppe von Benachteiligten. Wenn nicht sofort etwas passiert, kann das schnell teuer werden. Sobald die ersten Rückmeldungen über Probleme mit einer tabellenbasierten Site eintrudeln, beginnt das für die Website zuständige Team vermutlich auch schon mit der Planung des nächsten Layouts, das mindestens genauso viel Arbeit bedeutet wie das erste. Ist die Zeit gekommen, stattdessen CSS einzusetzen, wird die Arbeit anfangs sogar noch schwieriger. Schließlich müssen sich die Teammitglieder erst einmal mit der Knappheit und den Referenzpunkten von CSS vertraut machen. Welche Zeit wäre also besser für diesen Schritt geeignet als jetzt?
168
|
Kapitel 10: (Daten-)Tabellen
Positionierung ist bei Tabellen-Layouts wertlos Die Eigenschaften float und position sind zwei der wichtigsten Grundpfeiler bei CSSbasierten Layouts. Bei der Verwendung von Tabellen für das Layout verlieren die Eigenschaften für die Positionierung fast ihre gesamte Macht. Die Anordnung von Layout-Elementen, das »Stapeln« von Inhalten und diverse andere Hilfen stehen nicht zur Verfügung. Beim Tabellenlayout haben die Entwickler keine Wahl – ihre Kreativität bleibt auf eine Tabellenzelle beschränkt, Querdenken geht nicht, weil die Darstellungseigenschaften nichts anderes zulassen. Und damit genug von diesem Horrorszenario!
Bestandteile einer Datentabelle Am besten versteht man das Markup einer Datentabelle, indem man sich die einzelnen Bestandteile ansieht, die in Abbildung 10-1 gezeigt sind. col
td
colgroup
thead tr tbody
tfoot th
Abbildung 10-1: Anatomie einer Datentabelle
Zeilen und Zellen: tr und td Diese Elemente enthalten typischerweise die Daten eines einzelnen Datensatzes. Die Zeilen werden in einzelne Zellen (td) unterteilt. Analoge Zellen in verschiedenen Spalten werden immer in konsistenten Spalten dargestellt. Abgesehen von tbody müssen Zeilen und Zellen immer in einer Tabelle enthalten sein. Leser, die sich mit relationalen Datenbanken auskennen, erkennen, dass das tr-Element die Grenze eines einzelnen Datensatzes markiert. Spalten und Spaltengruppen: col und colgroup Während die Zeile für einen Datensatz steht, bezeichnet die Spalte eine bestimmte Datenkategorie (z.B. Anzahl der Achsen in Abbildung 10-1).
Bestandteile einer Datentabelle
|
169
Zeilen- und Spaltenüberschriften: th th funktioniert als Alternative zu td und definiert die Art der Daten einer bestimmten Zeile oder Spalte. Dabei besteht der Unterschied zwischen th und td nicht nur in der Art der Darstellung, sondern auch in ihrer Funktion. th-Elemente sind speziell dafür gedacht, keine Daten, sondern ihre Beschreibung zu enthalten. Beschriftungen: caption So wie die Elemente h1, h2 usw. Überschriften für normalen Text markieren, steht caption für eine Beschriftung der Tabelle. Standardmäßig wird das caption-Element über der Tabelle dargestellt. (Dieses Verhalten lässt sich mit der Eigenschaft captionside verändern.) Kopf- und Fußteil für Tabellen: thead und tfoot Diese Elemente dienen als praktische Behälter und können beispielsweise eine Beschreibung der Daten in den Spalten und (seltener) in den Zeilen der Tabelle enthalten. Sie unterscheiden sich aus zwei Gründen von einfachen Tabellenzeilen: – Um die verschiedenen Datentypen zu beschreiben, werden möglicherweise mehrere Zeilen benötigt. So kann die erste Zeile die verschiedenen Datenklassen beschreiben, während die zweite die Datentypen der einzelnen Spalten beschreibt. – Gemäß der Spezifikationen von HTML und CSS sollten die Elemente thead und tfoot bei seitenbasierten Medien auf jeder Druckseite wiederholt werden. Bei Systemen, die nur allgemeine Zeilen und Spalten verwenden, ist das oft nicht möglich. Offiziell sind thead und tfoot nicht nötig, damit das Dokument validiert, tbody dagegen schon. Der Tabellen»körper«: tbody Der Tabellenkörper enthält alle Tabellenzellen mit den tatsächlichen Daten, aber keine Metadaten.
Beispiel: Die volle Packung Tabellen-Markup Eine Tabelle, die sämtliche gerade beschriebenen Elemente verwendet, könnte beispielsweise wie folgt aussehen:
Und bei Odeo sieht das Ganze so aus: <param name="movie" value= "http://static.odeo.com/flash/player_audio_embed_v2.swf" /> <param name="FlashVars" value="jStr=[{’id’: 24363363}]" />
Multimediadaten integrieren
|
201
In allen drei Beispielen wird ein embed-Element (das übrigens nicht Teil der HTML 4Spezifikation ist) in ein object-Element (das offiziell unterstützt wird) verschachtelt. Das geschieht, weil das object-Element neben param-Elementen auch Dinge enthalten kann, die geladen werden, wenn der Browser die mit object angegebenen Inhalte nicht darstellen kann. Idealerweise ist dies einfach ein Bild und ein kurzer erklärender Text. Wenn man Postels Gesetz anwendet (»Seien Sie konservativ beim Verschicken und liberal beim Empfangen«), gibt es allerdings keinen Grund, für diesen Zweck auch ein embed-Element zu verwenden.
Die Geschichte dreier Firmen In der Anfangszeit des Webs war der Browserhersteller Netscape besonders stark, während Microsoft und einige kleinere Firmen versuchten, den Anschluss nicht zu verpassen. Die Rolle von CSS in diesem Kampf um Marktanteile haben wir bereits im Abschnitt »Prioritäten der Hersteller« auf Seite 44 angesprochen. Einen ähnlichen Konflikt gab es bezüglich der Einbindung von Multimedia-Inhalten. Das Ergebnis war abzusehen: Auf dem Papier gewann Microsoft das Rennen, während der Vorschlag von Netscape (bzw. dessen Konsequenz, das embed-Element) für die nächsten Jahre als QuasiStandard galt. Erst seit kurzer Zeit gibt es ein vom W3C definiertes Element zum Einbinden multimedialer Inhalte: object. Die Browserunterstützung reichte aber kaum aus, um es tatsächlich browserübergreifend einsetzen zu können. Das Element embed bot für lange Zeit die einzige Möglichkeit, die Netscapes Rendering-Plattform für das Einbinden von Multimediadaten unterstützte. Darüber hinaus gab es zusätzliche Probleme mit der Firma Eolas. Diese Gesellschaft existiert ausschließlich, um geistiges Eigentum zu sammeln und dann gegen Zahlung von Lizenzgebühren weiterzugeben. 1999 wurde Microsoft erfolgreich von Eolas verklagt. Offenbar verletzte Microsofts Implementierung des object-Elements die Rechte von Eolas. Dieser Prozess machte die Sache noch komplizierter und zwang Microsoft, das Verhalten des Internet Explorers beim Laden von Multimediadaten zu ändern. Als Resultat ist Microsofts Unterstützung für die Elemente object und param sehr eng mit Microsofts eigener API verbunden. Entwickler, die den Windows Media Player zum Abspielen verwenden wollen, sollten sich daher bei Microsofts Wiederverkäufer-Programm anmelden, um auf die gesamte Dokumentation zugreifen zu können. Größere Firmen können sich diese Form der Unterstützung leicht leisten. Für freiberufliche Entwickler, die mit mehreren Plattformen arbeiten müssen, sind diese Kosten (die schnell Hunderte von US-Dollar erreichen können) oft zu hoch.
Flash als möglicher Ausweg Geht es um die Webkodierung von Audio- und Video-Inhalten (A/V) für Endbenutzer, treten die meisten Probleme bei der Kompression der Daten auf. Stellen Sie sich das Chaos vor, wenn es für jedes Betriebssystem ein eigenes Kompressionsformat für Bilder gäbe. Genau aus diesem Grund sind Videoinhalte so schwer zu implementieren. Es gibt genau
202
|
Kapitel 11: Bilder und Multimedia
ein A/V-Format, das von allen Systemen von Haus aus unterstützt wird: MPEG1. Zwar ist dieses Format recht beliebt, aber leider auch schon ziemlich alt und nicht besonders effizient. Für alle anderen Kodierungsformate ist eine spezielle Software nötig, zum Beispiel Adobe Flash. Der Vorteil ist, dass Flash außergewöhnlich weit verbreitet ist. Laut Adobe ist Flash auf ca. 99 % aller Desktop-Rechner installiert. Keine andere Software ist so weit verbreitet. Selbst Microsoft Windows (unabhängig von der Systemversion oder dem verwendeten Browser) hatte bei der Veröffentlichung dieses Buches »nur« einen Marktanteil von 90 bis 95 %. YouTube und andere Sites, die ihr Geld damit verdienen, benutzererzeugte A/V-Inhalte im Web bereitzustellen, haben gezeigt, dass Flash nicht nur funktioniert, sondern auch noch einfach zu benutzen ist. Dies begründet die vorherrschende Stellung, die Flash heutzutage bei den Abspielplattformen für Audio- und Video-Inhalte innehat. SWFObject (das ursprünglich von einem YouTube-Entwickler geschrieben wurde) bringt
Flash schmerzfrei in Ihre Webdokumente. Wie steht es aber mit anderen Programmen wie QuickTime oder dem Windows Media Player? Was machen Sie, wenn Sie keinen FlashContainer für Ihre Videoinhalte verwenden können? Wie können Plugin-Inhalte eingebettet werden, ohne hierfür ungültiges Markup schreiben zu müssen?
Multimedia-Inhalte mit reinem Markup einbinden Es ist schwierig, ganz ohne das embed-Element auszukommen, wenn man A/V-Inhalte in seinen Webdokumenten verwenden möchte. Tatsächlich hat aber schon jemand die nötigen Tests und Anpassungen durchgeführt. Dadurch ist es möglich, Plugin-Inhalte einzubinden und gültigen Markup-Code zu schreiben. Unser Wohltäter ist ein Gentleman namens Simon Jessey, der seit 2006 im DreamhostWiki eine Reihe getesteter und gültiger Beispiele für das Markup von object-Elementen pflegt. Zum Zeitpunkt der Veröffentlichung dieses Buches standen Beispiele für die folgenden Player-Plattformen zur Verfügung: • Flash • QuickTime • Windows Media Player Auf den ersten Blick scheint diese Liste recht kurz zu sein. Allerdings erreichen Sie mit diesen drei Abspielumgebungen fast die ganze Webbevölkerung. Die aktuelle Version von Jesseys Arbeit finden Sie unter http://wiki.dreamhost.com/Object_Embedding.
Probleme mit Stilen für Plugin-Inhalte Das Problem bei der Definition von Stilen für Plugin-Inhalte besteht darin, dass die Inhalte als modale Dialogfenster angezeigt werden. Das heißt, die Plugin-Instanz verhält sich weniger wie normaler Webinhalt, sondern eher wie ein »Fenster im Fenster«. Wenn Multimediadaten integrieren
|
203
Sie für die Darstellung von Plugin-Inhalten fortgeschrittene Layouttechniken verwenden wollen, sollten Sie vorher sicherstellen, dass die Inhalte keinesfalls andere Elemente, speziell select-Formularfelder, überdecken. Ansonsten kann es passieren, dass die übrigen Inhalte nicht mehr benutzbar oder sogar unsichtbar sind.
Plugin-Probleme mit dem HTTP-Header »Content-Disposition« umgehen Häufigt umgehen Websitebetreiber das Problem, indem sie die Besucher auffordern, über ein Kontextmenü das Speichern der Datei einzuleiten. In Internet Explorer heißt diese Option Ziel speichern als …, in Firefox ist es Ziel speichern unter… und in Safari heißt sie Verknüpfte Datei laden unter… Allerdings lassen sich Situationen wie diese auch ohne das Zutun der Benutzer handhaben. Wenn Sie Ihre Benutzer nicht belästigen wollen bzw. nicht mit Support-Anfragen überhäuft werden wollen, können Sie den Download-Dialog auch erzwingen, anstatt die Multimedia-Inhalte im Browserfenster darzustellen. Hierfür muss der Webserver so eingerichtet sein, dass die Datei mit einem entsprechenden HTTP-Header an den Browser geschickt wird. Details hierzu finden Sie im Anhang dieses Buches. Für eine Videodatei im AVI-Format könnte das zum Beispiel so aussehen: Content-Disposition: attachment; file=/video/entwickler.avi
Diese Art von Headern erzeugen Sie am besten mithilfe der HTTP-API einer serverseitigen Skriptsprache Ihrer Wahl. Als Ergebnis wird neben der Darstellung der Seite im Browser das Speichern der A/V-Datei (in unserem Beispiel entwickler.avi) eingeleitet. Entweder landet die Datei daraufhin im Download-Ordner (abhängig von den Benutzereinstellungen), oder es erscheint ein Sichern als-Dialog, in dem der Benutzer einen eigenen Speicherort angeben kann. Ein sehr beliebtes Beispiel für dieses Verhalten ist die Website von download.com. Mit sorgfältiger Planung können Sie den Rückgabewert einer XMLHttpRequest-Funktion verwenden, um dieses Verhalten auszulösen, ohne die Seite komplett neu laden zu müssen. Der wichtigste Schritt besteht auch hier darin, das korrekte Content-Disposition-Feld im HTTP-Header der Datei anzugeben.
Eine offene Haltung bewahren Trotz ihres offensichtlichen Werts gab es im Laufe der Geschichte des Webs viel Streit um die Veröffentlichung von multimedialen Inhalten. Das hat zum Großteil mit schlechten Designpraktiken bei deren Präsentation zu tun. Trotzdem scheinen die Auftraggeber und die Leute, die am Ende die Schecks unterschreiben, dieses Brimborium zu mögen. Der Webentwickler muss dafür sorgen, dass bei der Veröffentlichung von Multimedia-Inhalten in Bezug auf Benutzbarkeit, Ressourcenkosten, Produktionswerte und Vorwärtskompatibilität die nötigen Standards eingehalten werden.
204
|
Kapitel 11: Bilder und Multimedia
Die Elemente »video« und »audio« (HTML 5) Durch die HTML 5-Elemente video und audio werden audiovisuelle Inhalte endlich auch zu Webbürgern erster Klasse. Das bedeutet: • Video- und Audioinhalte können damit so einfach in Webdokumente integriert werden wie Text, Hyperlinks und Bilder. • Die Elemente video und audio können mit anderen Kerntechnologien des Webs gemeinsam verwendet werden, zum Beispiel durch die Definition von SVG-Filtern oder CSS-Stilen für Videoinhalte. Die Elemente video und audio helfen beim Erreichen dieser Ziele, indem Video- und Audio-Inhalte direkt in die Webdokumente eingebettet werden, ohne dass hierfür Plugins nötig wären. Die dazugehörige HTMLMediaElement-API erlaubt die Manipulation von Audio- und Video-Inhalten mithilfe von DOM-Skripting, genau wie bei anderen erstklassigen Webinhalten auch.
Videos einbetten Im folgenden Beispiel wird gezeigt, wie Sie ein Video in ein HTML 5-Dokument einbetten können, inklusive der nötigen Steuerungselemente:
In diesem Beispiel funktioniert das src-Attribut analog zum img-Element: Der Wert ist der URI, unter dem die einzubettende Videodatei zu finden ist. Das Attribut controls sorgt dafür, dass der Browser automatisch die zum Abspielen nötigen Steuerungselemente (Abspielen, Pause, Stopp, Lautstärke, Vollbildmodus etc.) einblendet. Dies sind im Prinzip die gleichen Steuerungselemente wie bei einem Plugin. Beim video-Element werden diese Dinge jedoch direkt vom Browser erledigt.
Unterstützung für alternative Videoformate Als besonders aufmerksamer Leser haben Sie gemerkt, dass wir im vorigen Beispiel eine Videodatei namens papagei.foo verwendet haben. Die Dateiendung .foo steht hierbei für ein beliebiges Standard-Videoformat, das von allen aktuellen Browsern unterstützt wird. In der Realität gibt es jedoch kein allgemein gültiges Videoformat, mit dem das videoElement in aktuellen Browsern funktioniert. Firefox bevorzugt Theora-kodierte Ogg Vorbis-Dateien, während sich Safari sehr wahrscheinlich auf H.264-kodierte MP4-Dateien festlegt. Im Moment versuchen die Browserhersteller, sich auf ein Standard-Videoformat zu einigen. Bis ein Konsens erreicht ist, kann allerdings noch einige Zeit vergehen. Wenn Sie Ihre Videos möglichst vielen Benutzern zugänglich machen wollen, kommen Sie also nicht umhin, sie in unterschiedlichen Kodierungsformaten vorzuhalten. Hierbei wird die Quelldatei nicht über das src-Attribut, sondern mit eigenen source-Elementen angegeben, die als Inhalt des video-Elements definiert werden, wie hier gezeigt:
In diesem Fall durchläuft der Browser die Liste, bis er ein Videoformat findet, das er abspielen kann.
Rückwärtskompatibilität mit Browsern, die das »video«-Element nicht unterstützen Auch wenn Sie sich für die Verwendung des video-Elements entscheiden, sollten Sie ältere Browser nicht vergessen, die dieses Element nicht unterstützen. Eine Möglichkeit besteht darin, ein object-Element zu verwenden, dass den Inhalt bei Bedarf über ein DrittanbieterPlugin bereitstellt, wie im folgenden Beispiel: <source src="papagei.ogg"/> <source src="papagei.mov"/> <source src="papagei.wmv"/> <source src="papagei.3gp"/> <param name="movie" value="papagei.swf"/>
Benutzer, die kein Flash-Plugin installiert oder es deaktiviert haben, werden den per object eingebundenen Inhalt aber trotzdem nicht sehen können.
Das »canvas«-Element (HTML 5) Bei einer Einführung in HTML 5 darf das Element canvas auf keinen Fall fehlen. Bei dem Element canvas handelt es sich im Prinzip um eine Art dynamisches img-Element. Der canvas beschreibt einen bestimmten Bereich der Seite, in dem Sie dynamische (soll heißen: über ein Skript oder Programm erzeugte und gesteuerte) Bilder oder Animationen anzeigen können. canvas kann beispielsweise verwendet werden, um dynamische Diagramme zu erzeugen oder direkt im Browser Mal- und Zeichenprogramme (oder sogar Textverarbeitungen) oder Spiele zu realisieren. Im Prinzip können Sie mit canvas also die Dinge tun, die bisher nur mit Browser-Plugins wie Flash möglich waren.
Die »CanvasRenderingContext2D«-API Man kann sich das canvas-Element auch als Teil einer zweidimensionalen Zeichenfläche vorstellen, die ihre eigene Programmierschnittstelle mitbringt. Ohne diese API mit dem langen Namen CanvasRenderingContext2D wäre das canvas-Element ziemlich nutzlos. Vergleichen Sie das mit weniger interaktiven Elementen, die ebenfalls neu in HTML 5 sind, wie z.B. video, aber auch ohne zusätzliche API-Skripte funktionieren. Das canvasElement erwacht aber tatsächlich erst dann zum Leben, wenn Sie es zusammen mit der CanvasRenderingContext2D-API verwenden.
206
|
Kapitel 11: Bilder und Multimedia
Wenn Sie Inhalte für das canvas-Element entwickeln wollen, verwenden Sie die CanvasRenderingContext2D-API zusammen mit JavaScript. Eine eingehende Beschreibung würde den Rahmen dieses Buches leider sprengen. Das canvas-Element ist also kein gewöhnliches Markup-Element, sondern eher ein »Hook«, an dem Sie eigene Programme »aufhängen« können. Das Web ist voll mit Beispielen für die Verwendung von canvas. In Painting the Web ist diesem Thema ein eigenes Kapitel gewidmet.
SVG als Alternative zu »canvas« Wenn Sie nicht schon ein erfahrener JavaScript-Programmierer sind, ist canvas für Sie vermutlich nicht so gut geeignet, um Animationen und interaktive Bilder als Teil Ihrer Webinhalte umzusetzen. Vielleicht sollten Sie stattdessen einen Blick auf SVG (Scalable Vector Graphics) werfen. Wenn Sie hauptsächlich mit der Erstellung oder dem Design von Markup zu tun haben, wird Ihnen die deklarative Programmierung von SVG vermutlich besser liegen. Der Programmieransatz von SVG ist viel näher an CSS als am imperativen Vorgehen bei der Programmierung für canvas.
Multimediadaten integrieren
|
207
KAPITEL 12
Web-Typografie
Manche Bereiche von CSS sind schwer zu lernen, besonders der Umgang mit der Eigenschaft float. Dafür gibt es andere Bereiche, bei denen sich die investierte Lernzeit schnell wieder auszahlt, zum Beispiel die Eigenschaften zur Gestaltung von Texten und Buchstaben. Das folgende Material erhebt keinen Anspruch auf Vollständigkeit. Eine vollständige Übersicht über die CSS-Eigenschaften und -Werte finden Sie auf der Website zu diesem Buch (http://www.htmlcssgoodparts.net). Die folgenden O’Reilly-Bücher (beide geschrieben von Eric Meyer) können ebenfalls hilfreich sein: • CSS: Das umfassende Handbuch (http://www.oreilly.de/catalog/csstdg3 ger/index.html) • CSS kurz & gut (http://www.oreilly.de/catalog/csspr3ger/index.html)
Dieses Kapitel beginnt mit einer Einführung in die westeuropäische Druckkunst. Das soll Ihnen helfen zu verstehen, warum uneingeweihte Akteure oftmals unrealistische Erwartungen an die Darstellungsfähigkeiten des Webs haben.
Eine kurze Geschichte der Schrift In der heutigen Zeit, in der nur die ärmsten und isoliertesten Menschen nicht lesen können, wird oft vorausgesetzt, dass dies auch auf das Schreiben zutrifft. Tatsächlich haben sich die verschiedenen Schriftsysteme seit 5.000 Jahren permanent weiterentwickelt und dabei viele Veränderungen durchgemacht. Die Geschichte des Schreibens und der Druckkunst lehrt Kontrolle. Die Fähigkeit von Künstlern und Designern, das Aussehen einer gedruckten Seite in allen Aspekten steuern zu können, hat eine teilweise Jahrhunderte alte Tradition. Davon ist das Web jedoch noch weit entfernt. Trotz einiger interessanter Ansätze sind die typografischen Möglichkeiten noch sehr eingeschränkt. Die Verwendung von Adobe Flash kann diese Einschränkungen teilweise verringern, schafft aber neue Hindernisse. Bisher gibt es keine Technologie, die die Vielzahl an verschiedenen Benutzerumgebungen ausgleichen könnte.
|
209
Wenn man betrachtet, welchen Einfluss korrekt ausgebildete Grafikdesigner auf das Web haben, ist es hilfreich zu sehen, wie sich ihre Arbeit entwickelt hat – besonders im Bezug auf die Typografie.
Die Herkunft moderner westlicher Buchstabenformen Schon die ältesten Zivilisationen der Welt haben eigene Schriftsysteme entwickelt, um Ereignisse für die Nachwelt zu bewahren, sprich: um das Erinnerungsvermögen zu erhöhen. In dieser Diskussion der Geschichte der Druckkunst werden die asiatischen Beiträge nicht weiter betrachtet. Die Gründe sind das Fehlen englischsprachiger Informationsquellen von ausreichender Qualität, Unkenntnis seitens des Autors und die Tatsache, dass der Druck in industriellem Maßstab in erster Linie eine europäische Erfindung war.
Die heute verwendeten westlichen Alphabete lassen sich auf die Verbreitung ägyptischer Hieroglyphen in der Levante (östlicher Mittelmeerraum) vor ungefähr 3.500 Jahren zurückführen. Diese Verbreitung führte zum phönizischen Alphabet, das wiederum die Grundlage für das griechische Alphabet bildet. Das griechische Alphabet ist seinerseits ein Vorläufer der heutigen lateinischen und kyrillischen Schrift. Die Form des klassischen lateinischen Alphabets, wie es in zahllosen römischen Monumenten zu sehen ist, ist eine Untermenge der modernen Druckmajuskel (Großbuchstaben), während die späteren Minuskeln (Kleinbuchstaben) im Mittelalter aus der römischen Kursivschrift entstanden. Bis Johannes Gutenberg die Druckerpresse erfand, wurde fast ausschließlich von Hand geschrieben, z.B. um Aufzeichnungen vorzunehmen und zu kopieren.
Gutenbergs Druckerpresse und die Kunst der Typografie Gutenbergs Konstruktion der ersten mechanischen Druckerpresse, die bewegliche Buchstaben aus gegossenem Metall verwendete, veränderte die Ökonomie des Publizierens und führte direkt zur Typografie: der Gestaltung von Buchstabenformen für bestimmte Zwecke und Arten der Vervielfältigung. Die Formen variierten meist mit dem Geschmack der Künstler und belesenen Leute. Einer der vielen Vorteile der gegossenen Drucktypen bestand in einer nie gekannten Konsistenz im Aussehen der Druckprodukte – eine Konsistenz, die heute als selbstverständlich gilt. Druckerpressen, Papiere und Buchbinderei wurden seit Gutenbergs Erfindung beständig weiterentwickelt. Die größten Innovationen in der Typografie fanden erst im letzten Viertel des 19. Jahrhunderts statt. Bis dahin gab es nur wenig Unterschiede zum Schriftsatz zu Gutenbergs Zeiten. Mit der Einführung des Bleisatzes begann die Innovation, Fahrt aufzunehmen. Hierbei werden die Lettern maschinell zeilenweise aus geschmolzenen Bleibarren hergestellt und 210
|
Kapitel 12: Web-Typografie
dann auf der Arbeitsfläche der Druckerpresse angeordnet. Der englische Begriff »leading« (deutsch: »Durchschuss«) ist direkt vergleichbar mit der CSS-Eigenschaft line-height. Er wird auch heute noch in der Druckvorstufe verwendet und hat seinen Ursprung in der Praxis, zwischen den frisch gesetzten Druckzeilen Streifen kalten Bleis einzufügen, um Leerraum zu schaffen – eine Praxis, die noch aus früheren Jahrhunderten stammt. In der zweiten Hälfte des 20. Jahrhunderts wurde dann der Fotosatz eingeführt, bei dem lichtempfindliche Filme zur Herstellung von Druckplatten verwendet wurden. Dies war eine große Erneuerung der Lithographie, die Drucker seit Jahrhunderten verwendeten.
Das Aufkommen des Digitalsatzes Nach der Erfindung des Laserdruckers dauerte es nur wenige Jahre, bis ein brauchbarer computergestützter Satz möglich war. Kurz darauf folgten bezahlbare Computer, auf denen die ersten Schriftsatz-Programme liefen. Das letzte Stück des digitalen Typo-Puzzles waren bezahlbare Laserdrucker und benutzerfreundliche Textverarbeitungsprogramme mit grafischen Oberflächen, auf die wenige Jahre später die ersten ausgewachsenen Desktop-Publishing-Produkte folgten. Innerhalb von 20 Jahren hat sich aus dem einspaltigen Kaltsatz der Digitalsatz entwickelt. Anstatt die Buchstaben von Hand aus dem Setzkasten in das Druckbild einzufügen, stehen heute gleich mehrere Programme zur Verfügung, mit denen man ganze Seitenlayouts inklusive Grafiken am Computer erstellen kann. Anfang der Neunzigerjahre waren Computer und Drucker dann so weit, dass sie nicht nur belichtungsfähigen Schriftsatz, sondern auch belichtungsfähige Grafiken erstellen konnten. Im aktuellen Offsetdruck werden diese digital gesetzten Layouts direkt auf einen sogenannten Plattenbelichter übertragen, der aus den exportierten Rasterdaten Druckplatten erstellt. Weniger oft wurden Layouts mit dem Laserdrucker ausgegeben, fotografiert und dann als Fotonegativ manuell in den Plattenbelichter eingegeben. Die Weichen für die heutige digitale Typografie wurden 1991 gestellt, als das TrueTypeFormat für die Benutzung in Microsoft Windows lizenziert wurde. Mittlerweile kommt neben TrueType auch das Format OpenType zum Einsatz, wobei der Unterschied zwischen beiden, bezogen auf das Webdesign, nur minimal ist.
Verschiedene Beschränkungen, aber keine veränderten Erwartungen Jahrhundertelang waren Schriftsatz und Druck begreifbare Verfahren. Während dieser Zeit lagen die Beschränkungen im Design hauptsächlich in den Werkzeugen und weniger im Medium selbst. Mit der Entwicklung der Webbrowser wird dieses Paradigma quasi auf den Kopf gestellt. Das Medium sorgt für fast alle Einschränkungen, während die Grenze für erfahrene Entwickler allein in der eigenen Vorstellungskraft liegt.
Eine kurze Geschichte der Schrift
|
211
Ein kurzes Glossar der Typografie In Abbildung 12-1 sehen Sie eine Reihe von Fachbegriffen, die verschiedene Bestandteile und Formen von Schrift sowie das Erscheinungsbild einzelner Buchstaben beschreiben. x-Höhe
Endstrich
Anstrich
Unterlänge
Grundlinie
Oberlänge
Hauptstrich
Glyphe
Zeichen
Abbildung 12-1: Typoygrafische Begriffe für Buchstabenformen
Gestalter von Websites sollten zudem noch eine Reihe weiterer Fachbegriffe kennen: Buchstabenabstand Der zwischen zwei Glyphen eingefügte Leerraum innerhalb einer Textpassage. Wird gesteuert mit der CSS-Eigenschaft letter-spacing (teilweise auch per word-spacing). Diakritische Zeichen Diakritische Zeichen sind Zusatzzeichen, die im Grunde nicht zum Buchstaben gehören, aber eine andere Aussprache signalisieren können. Häufige Beispiele sind der Akut-Akzent (´, z.B. in générale), Umlaute (¨, z.B. in Klönschnack), die Cedille (z.B. in »Ça va?«), gelegentlich auch der Schrägstrich (z.B. in »Smørgåsbrød«). Dingbats (Zierschrift) Zeichensammlung (üblicherweise als eigener Zeichensatz), die nicht aus normalen orthografischen Zeichen, sondern z.B. aus Ornamenten oder Symbolen besteht (Musiknoten, Schaltungssymbole etc.). Durchschuss Wie bereits beschrieben, bezeichnet der Durchschuss den vertikalen Raum zwischen zwei Textzeilen. Dies ist verwandt (aber nicht identisch) mit der CSS-Eigenschaft line-height. Festbreitenschrift (Mono) Eine Schrift, bei der all Buchstaben die gleiche Breite haben, wie z.B. Courier. Es wird kein Schriftweitenausgleich vorgenommen. Gebrochene Schrift (Blackletter) Ein typografischer Stil, der von den deutschen Handschriften des Spätmittelalters inspiriert wurde. Ein Beispiel für eine gebrochene Schrift ist die Fraktur. Glyphe Die grafische Darstellung eines Buchstabens, eines Silbenzeichens, einer Ligatur (z.B. fl und ff) oder eines Buchstabenteils.
212
|
Kapitel 12: Web-Typografie
Groß-/Kleinbuchstaben (Upper-/Lowercase) Synonym mit Majuskeln/Minuskeln, manchmal auch als Versal/Gemeine bezeichnet. Groteske (Gothic) Üblicherweise synonym mit serifenlos. (Nicht zu verwechseln mit »gotischen«, also schmalfetten, gebrochenen, mittelalterlichen Schreibschriften, wie z.B. Fraktur). Kursiv (Italic) Ein Schriftschnitt, der durch das Hinzufügen kalligraphischer Akzente aus der entsprechenden aufrechten Urschrift entwickelt wurde. Der übliche Neigungswinkel beträgt i.d.R. 5 bis 10 nach rechts (vgl. oblique). Leerraum Beliebiger Raum auf der Seite oder Zeichenfläche, der nicht mit Schrift, Illustrationen oder Trennlinien ausgefüllt ist. Der englische Begriff »whitespace« steht einerseits für diesen Leerraum, aber auch für den Computerbegriff »Whitespace-Zeichen« (z.B. Leerzeichen, Tabulator etc.). Oblique (Geneigte Schrift) Oft fälschlicherweise mit »kursiv« gleichgesetzt. Tatsächlich handelt es sich um die Urschrift (Roman), die künstlich schräggestellt wurde. Orthografie Rechtschreibung. Regeln zur korrekten Schreibweise von Wörtern. Roman Bezeichnet die Urschrift eines Zeichensatzes (Fonts), z.B. Times New Roman. Von dieser können andere Schriftschnitte abgeleitet sein, etwa kursive Varianten. Schreibschrift (Script) Eine Klasse von Schriften, die entwickelt wurde, um Handschriften nachzuempfinden. Schriftgewicht Kennzeichnet im Allgemeinen die Linienstärke (»Fette«) einer Schrift. Wird mit der CSS-Eigenschaft font-weight gesteuert. Übliche Schriftgewichte im Druck reichen von »Ultraleicht« (Haarlinie, geringstes Schriftgewicht) bis zu »Ultrafett«. Normaler Text erhält i.d.R. das Schriftgewicht »Mittel« (Medium, Book), muss aber nicht extra definiert werden. Die Abbildungen 12-2 und 12-3 zeigen verschiedene Schriften in unterschiedlichen Gewichtungen. In Abbildung 12-2 sehen Sie die Microsoft-Standardschriften (»Core Fonts«) für das Web, während Abbildung 12-3 die Standardschriften für Safari 4/Firefox 3.5 am Mac bzw. Firefox 3.5 unter Windows zeigt. Schriftweitenausgleich (Kerning) Automatischer Ausgleich der Schriftweite, entweder durch Unterschneidung (Verringerung des Buchstabenabstands) oder auch durch Spationierung (Erweiterung des Abstands), z.B. bei Buchstabenpaaren wie fl, Fe, We, ff oder Te. Ohne diesen Ausgleich erscheinen diese Buchstaben ungewöhnlich weit voneinander entfernt. Bei manchen Kombinationen aus Betriebssystem, Software und Schrift muss die Schriftweite für Ein kurzes Glossar der Typografie
|
213
Rasterschriften hoher Qualität manuell angepasst werden. In diesem Fall spricht man von »Ausgleichen«. Schmalschrift (Condensed) Stil einer Schrift, die sich von anderen Schriften durch ihre schmale Natur und eng beieinander stehende Buchstaben unterscheidet. Das Gegenteil von Breitschrift. Serifenlose Schrift Eine Klasse von Schriften, die durch offensichtliche geometrische Formen, Strichführung mit gleicher Dicke und das Fehlen von Verzierungen (Serifen) an den Linienenden gekennzeichnet ist. Serifenschrift Das Hauptmerkmal einer Serifenschrift sind eben die sogenannten Serifen, Verzierungen an den Linienenden, wie beispielsweise bei der Times. Spationierte Schrift (Extended) Das Gegenstück zur Schmalschrift. Die Buchstaben sind breiter als bei normalen Schriften, der Buchstabenabstand ist meist etwas weiter. Auch als breitlaufende Schrift bezeichnet. Steg (Gutter) Im Druck der unbedruckte Bereich zwischen dem Satzspiegel und dem Rand. Im Web auch der Leerraum zwischen dem Text und einer möglichen Trennlinie bzw. zwischen zwei Spalten oder zwei Textpassagen. Der Steg wird in vielen Fällen über die CSS-Eigenschaft padding gesteuert. Text Allgemeiner Begriff für das Arbeitsprodukt eines Texters. Textausrichtung Bezieht sich auf die Längsachse, an der sich der Text orientiert. Bei linksbündig ausgerichteten Texten beginnen die Zeilen alle an einer gemeinsamen linken Achse; bei rechtsbündig ausgerichteten Texten entsprechend rechts. Beim Blocksatz haben alle Zeilen bis auf die letzte eine gemeinsame linke und rechte Achse. Dieser Teil des Layouts wird über die CSS-Eigenschaft text-align gesteuert. Trennlinie (Rule) Eine Linie, die auf einer Seite eines Textblocks eingefügt wird. Üblicherweise über die CSS-Eigenschaft border gesteuert. Die Nomenklatur für die Zeichenkodierung sowie die Eigenschaften zur Textgestaltung werden weiter hinten in diesem Kapitel besprochen.
214
|
Kapitel 12: Web-Typografie
Abbildung 12-2: Normalerweise verfügbare Microsoft-Standardschriften für das Web
Mac: Safari 4 and Firefox 3.5
Windows: Firefox 3.5
Times
Times New Roman
Helvetica
Arial
Courier
Courier New
Apple Chancery
ComicSans MS
Papyrus Abbildung 12-3: Standardschriften in verschiedenen Browsern für die »font-family«-Schlüsselwörter »serif«, »sans-serif«, »monospace«, »cursive« und »fantasy«.
Schriftenglättung: Aliasing und Anti-Aliasing Die gute Nachricht zuerst: Jahrhundertelang war die Typografie ein Garant hoher ästhetischer Standards. Die schlechte Nachricht ist, dass während dieser Zeit niemand daran dachte, dass Schriften einmal als Pixel in elektronischen Medien angezeigt werden müssten. Schriftenglättung: Aliasing und Anti-Aliasing
|
215
Dadurch machen die meisten traditionellen Schriften auf dem Bildschirm eine ziemlich schlechte Figur, wie in Abbildung 12-4 zu sehen ist.
Abbildung 12-4: Schriftglättung am Beispiel der Helvetica (12 Punkt/16 Pixel): (1) das Original in einem Pixelgitter, (2) nicht geglättet, (3) Schriftglättung unter Mac OS X und (4) Schriftglättung in Clear Type/Windows Vista
Das Aliasing versucht, sich den Linien von Buchstaben anzunähern. Das führt zu deutlich sichtbaren »Stufen« in der Darstellung. Aus diesem Grund sehen Schriften, in deren Design das Aliasing nicht berücksichtigt wurde, am Bildschirm oft anders aus als ihr gedrucktes Gegenstück – meistens hässlicher. Dieser Effekt wird noch dadurch verstärkt, dass das menschliche Auge besonders auf Helligkeitsunterschiede reagiert. Anti-Aliasing versucht, die Probleme der Schriftdarstellung auf dem Bildschirm durch Kantenglättung zu beheben, wie in Abbildung 12-4 zu sehen ist. Hierfür erzeugen die Anti-Aliasing-Algorithmen Bereiche zwischen den »Stufen«, in denen Vorder- und Hintergrund nach und nach interpoliert werden. Hierdurch wird der tatsächliche Kontrast verringert, und die Schrift erscheint für den Bildschirm optimiert. Im Gegensatz zu modernen Laserdruckern, die mit Auflösungen von 600 Pixeln und mehr arbeiten, ist die Auflösung auch auf modernen Monitoren verschwindend gering. Dies 216
|
Kapitel 12: Web-Typografie
führt gerade bei geringen Schriftgrößen zu Problemen, denen mit der Bildschirmoptimierung (engl. »hinting«) begegnet werden soll. Hierbei enthält die Schriftdatei Hinweise darauf, wie die Pixeltreppen ausgeglichen werden können. Der größte Nachteil des Anti-Aliasings besteht darin, dass gerade kleine Schriften schnell unlesbar werden. So wie ein verkleinertes Bild leicht verschwommen erscheint, erscheinen Bereiche mit kleiner Schrift schnell nur noch als kontrastreiche Bereiche, wie in Abbildung 12-5 gezeigt wird.
Abbildung 12-5: Das Ergebnis einer geringen Schriftgröße, um ihre Aufösung bei der Bildschirmdarstellung herabzusetzen. Wird das Anti-Aliasing auf so kleine Schriften angewendet, sind die Ergebnisse oft nicht mehr lesbar. Oft sehen für den Bildschirm optimierte Schriften bei kleineren Schriftgrößen besser aus als bei hohen. Da die meisten Texte mit einer durchschnittlichen Größe von 12pt/16 Pixel angezeigt werden, erscheinen viele Schriften bei dieser Einstellung auch am lesbarsten. Daher sind bildschirmoptimierte Schriften meist auch nicht so komplex gestaltet wie ihre Verwandten für den Druck. Andererseits erscheinen bildschirmoptimierte Schriften bei hohen Darstellungsgrößen oft deutlich schlichter als ihre traditionellen Gegenparts. Deshalb ziehen Designer oft grafische Überschriften in traditionellen Schriften den vom Webbrowser unterstützten Fonts vor. Die Details der Schriften aus dem Druckbereich werden bei hohen Größen erhalten (oder sogar verstärkt). Dadurch erscheinen sie attraktiver als ihre bildschirmoptimierten Kollegen.
Schriftenglättung: Aliasing und Anti-Aliasing
|
217
Schriftstile, Lesbarkeit und Erkennbarkeit Bei der Layoutentwicklung wird die Wahl der verwendeten Schriften von zwei sich ergänzenden Ideen bestimmt: Lesbarkeit und Erkennbarkeit des Schrift. Die Lesbarkeit bestimmt, wie gut größere Textmengen lesbar sind. Die Erkennbarkeit bezieht sich darauf, wie leicht bestimmte Daten, Wörter und kurze Sätze beim Überfliegen des Textes erkannt werden.
Stildefinitionen zum Erhöhen der Lesbarkeit Wenn wir uns ein typisches Buch vorstellen, haben wir bereits eine ziemlich genaue Idee davon, was Lesbarkeit ausmacht: • Serifenschrift • 12–15 Wörter pro Zeile • Blocksatz • Moderate, konsistente Buchstabenabstände Besonders bei teureren Publikationen findet man des Öfteren höhere Zeilenabstände (20 % der Schrifthöhe oder mehr) und detailliertere Fonts, um Zeilen, Buchstaben und andere Teile der Seite leichter entziffern zu können. Bei billigeren Produkten ist die Gewinnspanne oft so niedrig, dass um jeden Preis Kosten gespart werden müssen. Das heißt: schlechteres und weniger starkes Papier, mehr Zeilen, weniger Leerraum. Dazu werden Fonts mit weniger Details verwendet, die auch bei schlechten Papieren nicht zum »Ausfransen« von Buchstaben führen. Im Web spielen Papierkosten keine Rolle. Wir können also das komplette Arsenal verfügbarer Werkzeuge aufbieten, um die Lesbarkeit zu erhöhen. Für die Bildschirmdarstellung könnte das Resultat etwa so aussehen: #haupttext p { width: 50em; font-family: Georgia,’Times New Roman’, serif; font-size: 14px; line-height: 17px; text-align: justify; }
Allerdings gibt es bei der Bildschirmdarstellung andere Probleme, die bei Büchern nicht auftreten. Zu diesen Problemen gehört beispielsweise das Scrollen von Inhalt. Die im Web übliche linksbündige Darstellung erleichtert das Lesen von Text, der im Browserfenster auf- und abbewegt wird.
Stildefinitionen zum Erhöhen der Erkennbarkeit Während die Lesbarkeit besonders bei langen Textpassagen eine Rolle spielt, hat die Erkennbarkeit bei Überschriften, Daten oder kurzen Textabschnitten Vorrang. Infografi-
218
|
Kapitel 12: Web-Typografie
ken und Tabellen in Zeitungen sind hierfür ein ausgezeichnetes Beispiel. Hierbei kommen nicht selten die folgenden Prinzipien zur Anwendung: • serifenlose Schriften • hohe Schriftgrößen für Überschriften, kleinere für Daten • strikte Orientierung am Layoutraster • häufige Verwendung von Trennlinien zwischen Text und Daten (vertikal und horizontal) • farbige Unterscheidung von Zeilen (seltener auch Spalten) • Nebeneinanderliegende Spalten mit zusammengehörigen Inhalten werden an einer gemeinsamen Achse ausgerichtet (z.B. Spalte 1: Straße, rechtsbündig; Spalte 2: Hausnummer, linksbündig). In den Kapiteln 10 und 13 finden Sie eine Reihe von Empfehlungen, wie Sie die Erkennbarkeit von Tabellen- und Formularinhalten erhöhen können. Bei der Arbeit mit Schreibsystemen, die von links nach rechts gelesen werden (wie die europäischen Sprachen), ist der Text meist am besten erkennbar, wenn er linksbündig ausgerichtet wird. Haben die Zeilen deutlich unterschiedliche Längen, kann es sinnvoll sein, Zeilenumbrüche mithilfe der Eigenschaft white-space manuell vorzunehmen (in Kürze mehr dazu), den Text rechtsbündig auszurichten oder beide Lösungen gemeinsam zu verwenden.
Der »Knick« und kleine Schriften Stellen Sie sich eine in der Mitte gefaltete Zeitung vor, die mit der Titelseite dem Käufer zugewandt an einem Zeitungsstand ausliegt. Für die erforderliche Sichtbarkeit von Überschriften und Inhalten sind sorgfältige Layoutentscheidungen nötig – schließlich kommt den Geschichten »über dem Knick« besondere Bedeutung zu. Im Browserfenster entspricht dies dem Bereich, der ohne zu scrollen sichtbar ist. Dies ist oft nur ein kleiner Teil des tatsächlichen Seiteninhalts (siehe Abbildung 12-6). Viele Leute betrachten den Bereich »über dem Knick« als den wertvollsten Teil einer Webseite. Daher ist die Versuchung groß, ihn mit möglichst viel Inhalt vollzupacken. Je mehr Inhalt sich »über dem Knick« befindet, desto größer ist die Chance, den Besucher auf der Website zu halten – oder? Dies ist aus folgenden Gründen ein Trugschluss: Zu viel Inhalt schreckt Besucher, die nach bestimmten Inhalten suchen, eher ab. Das »Über dem Knick«-Modell geht davon aus, dass der typische Benutzer die Seite lieber verlässt, als sie zu scrollen. Das führt manchmal zu extremen Auswüchsen. So wird versucht, die Darstellung von Scrollbalken komplett zu verhindern. Tatsächlich ist das Scrollen ein Zeichen für die Motivation des Besuchers. Oft ist es leichter, eine Seite zu scrollen, als die sprichwörtliche Nadel in dem »Heuhaufen« einer bis zum Rand vollgepackten Webseite zu finden. Schriftstile, Lesbarkeit und Erkennbarkeit
|
219
Abbildung 12-6: Ein Browserfenster mit einer Größe von 1920 × 1080 Pixeln. Die Rahmen kennzeichnen jeweils den Bereich »über dem Knick« bei verschiedenen Auflösungen.
Zu viel Inhalt erschwert das Unterscheiden von Inhalten. Bei so vielen Dingen lässt sich der Inhalt oft nur noch anhand der verwendeten Farben unterscheiden. Der Anspruch, alles Wichtige »über dem Knick« darzustellen, führt schnell zur Verwendung gleich stark gesättigter Farben. Dadurch wird die Website mit Sicherheit nicht schöner. Die Verwendung geringer Schriftgrößen, um mehr Inhalt »über dem Knick« unterzubringen, macht die Seiten für Benutzer mit Sehproblemen unbenutzbar. Um diese These zu bestätigen, brauchen Sie nicht einmal online zu gehen. Versuchen Sie einfach, die erste Seite Ihres Handy-Vertrags zu lesen. Dann überlegen Sie, ob eine solche Bleiwüste für Ihre Website eine gute Idee ist. Die Vielfalt an Bildschirmauflösungen hat zur Folge, dass »über dem Knick« für andere Benutzer bereits »unter dem Knick« bedeutet. Für Benutzer mit hohen Bildschirmauflösungen hat der Versuch, den Bereich »über dem Knick« zu betonen, oft zur Folge, dass das Browserfenster zu großen Teilen leer bleibt. Daher gilt: Verkleinerte Schrift sollte keinesfalls als Designmittel verwendet werden, außer vielleicht aus ästhetischen Gründen, die für den größten Teil Ihres Publikums nachvollziehbar sind. Winzige Buchstaben sind weder cool noch hilfreich, außer in seltenen Sonderfällen. Natürlich sollte der Inhalt trotzdem in der Reihenfolge seiner Wichtigkeit präsentiert werden. Hierbei können die verschiedenen Zeilen eines Layoutrasters ebenfalls helfen.
220
|
Kapitel 12: Web-Typografie
Schriftgrößen angeben Wenn sich Designer für etwas begeistern können, so ist es die Kontrolle über die Gestaltung von Schriften. Hierfür ist CSS wunderbar geeignet. Ist eine Schrift im Browser des Benutzers darstellbar, kann ihre Präsentation in weiten Teilen vom Gestalter bestimmt werden. Dies gilt besonders für die Schriftgröße, für die ein paar einfache Regeln gelten: • Designer aus dem Printbereich übersehen leicht, dass der Benutzer sehr großen Einfluss auf die Schriftgröße nehmen kann. Aus diesem Grund ist es meistens am besten, die Ausgangsschriftgröße für das body-Elemet in Pixeln anzugeben, wie hier: body { font-size: 14px; ... }
Danach können Sie die Schriftgrößen im Verlauf der Kaskade mit em-Einheiten oder Prozentwerten steuern (die sich in der Funktionsweise kaum unterscheiden). Erwarten Sie überdurchschnittlich viele Benutzer des IE 6, kann es zu Problemen mit der Usability kommen. Im IE 6 hat der Benutzer keine Möglichkeit, in Pixeln angegebene Schriften zu vergrößern oder zu verkleinern. • Browser berechnen die Schriftgröße von Überschriften anhand der angegebenen Grundschriftgröße. Um auf spätere Änderungen am Layout vorbereitet zu sein, sollten Sie beim Zurücksetzen der Überschriften ähnlich vorgehen. Wollen Sie grafische Überschriften einsetzen, kann es nötig werden, die Regeln für die Bildersetzung um die Eigenschaft background-position zu erweitern. • Brauchen Sie absolute Kontrolle über die Größe eines Elements, sollten Sie dessen Inhalt als Bild definieren und den eigentlichen Text im alt-Attribut angeben. Diese Situation sollte jedoch nach Möglichkeit vermieden werden. Manchmal geht es aber nicht anders. • Vermeiden Sie es, die Werte für line-height in Pixeln anzugeben. Ansonsten müssen Sie diese Angabe für jedes Vorkommen von font-size wiederholen. Die Werte für die Größe von Überschriften werden von der Kaskade automatisch gehandhabt, so auch die Werte für line-height. Wenn Sie line-height für Ihren Haupttext in Pixeln definieren, wird die gleiche Zeilenhöhe auch bei höheren Schriftgrößen verwendet, was Ihre Text schnell unlesbar macht.
Die richtigen Längeneinheiten für Schriftgrößen Bei der Gestaltung von Schriften für die Browserdarstellung können Sie eine von vier Längenangaben verwenden: Pixel, em-Einheiten, Prozentwerte oder Schlüsselwörter. (Darüber hinaus gibt es noch verschiedene weitere Längeneinheiten, die in der Praxis aber kaum verwendet werden.) • Pixel (px) sind im Prinzip absolute Längeneinheiten. Wird die Schriftgröße in Pixeln angegeben, wird der Text unabhängig von den Benutzereinstellungen oder seiner Position in der Kaskade in allen Umgebungen gleich groß ausgegeben. Bei der Verwendung von Pixeln können jedoch zwei Probleme auftreten. Die Schriftgröße im Internet Explorer 6 kann in diesem Fall nicht vom Benutzer verändert werden. In Schriftgrößen angeben
|
221
anderen Browsern tritt ein anderes Problem auf: Bei zu hoher Vergrößerung kann die Schrift über die Grenzen von Hintergrundbildern oder Elementboxen hinausragen. • Em-Einheiten (em) und Prozentwerte sind dagegen relative Längeneinheiten. Der angegebene Wert ist im Prinzip ein Multiplikationsfaktor für den entsprechenden Wert des Elternelements. Der Wert für das Elternelement muss hierbei nicht ausdrücklich angegeben werden, sondern kann auch der Standardwert des Browsers sein. Dieses Verfahren wird im folgenden Abschnitt genauer erklärt. • Wird die Schriftgröße als Schlüsselwort angegeben, ist einer von sieben Werten möglich. Diese entsprechen ungefähr den verschiedenen Gewichtungen für Überschriften (siehe unten). Die tatsächlichen Werte für Schlüsselwörter werden übrigens immer relativ zur Standardeinstellung des Browsers berechnet. Die im Browser eingestellte Standardschriftgröße entspricht hierbei dem Wert medium und beträgt in aktuellen Browsern meist 16 Pixel.
Berechnung der Werte für em-Einheiten und Prozentangaben Wird der Wert für font-size in em-Einheiten oder als Prozentwert angegeben, hängt der berechnete Wert davon ab, wo in der Kaskade sich das betreffende Element befindet. Der tatsächliche Wert wird als Vielfaches der geerbten Schriftgröße berechnet. Zum Beispiel: body { font-size: 15px; } .wichtig { font-size: 1.4em; } .anmerkung { font-size: .667em; }
Werden keine weiteren Angaben für font-size gemacht, hat der Text in Abschnitten der Klasse wichtig eine Größe von 21 Pixeln, während er in Abschnitten, die als .anmerkung markiert sind, nur 10 Pixel groß ist. Ergänzen wir dies um die folgende Regel: .wichtig strong { font-size: 1.429em; font-style: normal; }
Hier würde man davon ausgehen, dass der Text nicht fettgedruckt, sondern einfach etwas größer als der umgebende Inhalt dargestellt wird. Tatsächlich werden die Angaben für font-size aber nicht addiert, sondern multipliziert, wodurch der mit strong markierte Teil deutlich größer ausfällt: (15 \x 1,4 \x 1,429) = ca. (15 \x 2) 30 Pixel
Der gleiche Effekt tritt auch bei verkleinernden Werten auf. Aus diesem Grund rate ich CSS-Anfängern in Diskussionsforen eigentlich davon ab, em-Einheiten oder Prozentangaben für font-size-Werte des body-Elements zu benutzen. Wird font-size mehrfach in Stylesheet-Regeln für verschachtelte Elemente verwendet, können relative Werte schnell zu unlesbarem Text führen.
222
|
Kapitel 12: Web-Typografie
Schlüsselwörter für Schriftgrößen Gemäß der CSS 2.1-Spezifikation entsprechen die sieben Schlüsselwörter den verschiedenen Überschriftsgrößen, wie in Tabelle 12-1 dargestellt ist. Tabelle 12-1: Die Beziehung zwischen den Schlüsselwörtern für »font-size« und den Überschriftsgrößen Schlu¨sselwort
xx-small
x-small
small
medium
large
x-large
xx-large
h3
h2
h1
(Standardwert) U¨berschrift
h6
–
h5
h4
Die Schlüsselwörter für font-size entsprechen den Werten des size-Attributs für das nicht mehr unterstützte Element font. Geht man von den Standardschriftgrößen in Firefox 3, Internet Explorer 8 und Safari 3/4 aus, so entsprechen die Schlüsselwörter den Pixelwerten, die in Tabelle 12-2 aufgeführt sind: Tabelle 12-2: Standardschriftgrößen und die entsprechenden Schlüsselwörter für »font-size« Schlu¨sselwort
xx-small
x-small
small
medium
large
x-large
xx-large
Pixelwert
9
10
13
16
18
24
32
Arbeit mit Schriften und Schriftschnitten Die Möglichkeit, Schriften (Fonts) und Schriftschnitte außerhalb des Markups zu definieren, ist eine der größten Stärken von CSS. Dies ist eine deutliche Verbesserung gegenüber den Kindertagen des Webs, als die Seiten ausschließlich in der vom Benutzer eingestellten Standardschrift dargestellt wurden.
Das Problem der geringen Auswahl Unter Windows XP gibt es gerade einmal 16 Schriften, die im Web verwendet werden können. Drei davon sind aus verschiedenen Gründen jedoch komplett nutzlos. Unter Mac OS X ist die Auswahl deutlich größer. Aufgrund des geringen Marktanteils von Mac OS X sollten Designer aber prinzipiell eine der XP-Schriften als Ersatz angeben, die in Tabelle 12-3 gezeigt sind. Die Allgegenwärtigkeit von Microsoft Office (und der beiliegenden Schriften) ist ein Lichtblick in der ansonsten eher düsteren Landschaft der Web-Typografie. Allerdings sind die meisten Schriften eher im Printbereich als im Web zu Hause.
Arbeit mit Schriften und Schriftschnitten
|
223
Tabelle 12-3: Verfügbare lateinische Schriften, geordnet nach Betriebssystem. Großflächig unterstützte Schriften sind hervorgehoben. Mögliche Ersatzschriften für die verschiedenen Betriebssysteme bzw. die entsprechenden allgemeinen Schlüsselwörter sind angegeben.1, 2 Schrift
Betriebssystem Windows XP
Windows Vista & 7
Mac OS X 10.3
Mac OS X 10.5
American Typewriter
Courier New
Courier New
✓
✓
Andale Mono 3
✓
✓
Monaco
✓
Apple Gothic
Microsoft Sans Serif
Microsoft Sans Serif
✓
✓
Arial
✓
✓
✓
✓
Arial Black 4
✓
✓
✓
✓
Arial Narrow
✓
✓
✓
✓
Arial Rounded
Arial
Arial
✓
✓
Arial Unicode
Arial Unicode MS
Arial Unicode MS
Arial
×
Arial Unicode MS
✓
✓
Arial Unicode
✓
Baskerville
Palatino Linotype
Palatino Linotype
✓
✓
Big Caslon
Bookman Old Style
×
✓
✓
Book Antiqua
✓
✓
✓
✓
Bookman Old Style
✓
✓
✓
✓
Brush Script
cursive
cursive
✓
✓
Calibri
Trebuchet MS
✓
Trebuchet MS
Trebuchet MS
Century Gothic
✓
✓
✓
✓
Cambria
serif
✓
serif
Plantagenet Cherokee
Cambria Math
×
✓
×
×
Candara
Tahoma
✓
Tahoma
Tahoma
Chalkboard
Comic Sans MS
Comic Sans MS
✓
✓
Cochin
serif
serif
✓
✓
Comic Sans MS
✓
✓
✓
✓
Consolas
Lucida Console
✓
Monaco
×
Constantia
Book Antiqua
✓
Book Antiqua
×
1 Auf sämtlichen genannten Betriebssystemen gibt es außerdem eine Reihe von kyrillischen und asiatischen Schriften, die teilweise eine beschränkte Unterstützung für lateinische Buchstaben enthalten. Zudem enthalten nicht alle Fonts den kompletten lateinischen Zeichensatz. 2 Die hier vorgeschlagenen Ersatzangaben sind vollkommen subjektiv. Die Ersatzschriften funktionieren größtenteils auf allen Betriebssystemen. 3 Folgende Schriften sind Teil der Microsoft-Standardschriften für das Web: Arial, Arial Black, Comic Sans MS, Courier New, Georgia, Impact, Tahoma, Times, New Roman, Trebuchet MS und Verdana. 4 Einige der in dieser Tabelle genannten Schriften sind nicht Teil von Windows selbst, sondern von Microsoft Office, das zumindest als Demoversion den meisten Betriebssystemen (inklusive Mac OS X) beiliegt. Die Schriften können auch dann weiterbenutzt werden, wenn die Demoversion bereits abgelaufen ist. Unter Mac OS X muss eines der Office-Programme zumindest einmal gestartet werden, damit die Schriften installiert werden. Viele dieser Schriften wurden für gedruckte Medien entwickelt. Ihre Verwendung im Web ist daher mit Vorsicht zu genießen.
224
|
Kapitel 12: Web-Typografie
Tabelle 12-3: Verfügbare lateinische Schriften, geordnet nach Betriebssystem. Großflächig unterstützte Schriften sind hervorgehoben. Mögliche Ersatzschriften für die verschiedenen Betriebssysteme bzw. die entsprechenden allgemeinen Schlüsselwörter sind angegeben. (Fortsetzung) Schrift
Betriebssystem Windows XP
Windows Vista & 7
Mac OS X 10.3
Mac OS X 10.5
Corbel
Tahoma
✓
Tahoma
×
Courier New
✓
✓
✓
✓
Didot
serif
serif
✓
✓
Franklin Gothic
sans-serif
✓
Gill Sans
Gill Sans
Futura
Century Gothic
Century Gothic
✓
✓
Garamond
✓
✓
✓
✓
Georgia
✓
✓
✓
✓
sans-serif
Franklin Gothic
✓
✓
Helvetica
Arial
Arial
✓
✓
Helvetica Neue
Arial
Arial
✓
✓
Herculanum
fantasy
fantasy
✓
✓
Hoefler Text
Georgia
Georgia
✓
✓
Impact
✓
×
✓
×
Lucida Console
✓
✓
Monaco
Monaco
Lucida Grande
Lucida Sans Unicode
Lucida Sans Unicode
✓
✓
Lucida Handwriting
✓
✓
✓
✓
Lucida Sans Unicode
✓
✓
Lucida Grande
Lucida Grande
Marker Felt
cursive
cursive
✓
✓
Gill Sans
5
Microsoft Sans Serif
✓
✓
Apple Gothic
✓
Mistral
cursive
✓
Brush Script
Brush Script
Monaco
Lucida Console
Lucida Console
✓
✓
Monotype Corsiva
✓
✓
✓
✓
Nyala
fantasy
✓
Papyrus
Papyrus
Optima
sans-serif
sans-serif
✓
✓
Palatino Linotype
✓
✓
Baskerville
Baskerville
Papyrus
✓
✓
✓
✓
Plantagenet Cherokee6
serif
✓
serif
✓
Segoe Print
Lucida Handwriting
✓
Lucida Handwriting
Lucida Handwriting
Segoe Script
cursive
✓
cursive
cursive
Segoe UI
sans-serif
✓
Gill Sans
Gill Sans
Skia
sans-serif
sans-serif
✓
✓
5 Gill Sans wird von Mac OS X als Standardschrift für Benutzerschnittstellen und Textbeschriftungen verwendet. 6 Enthält lateinische Buchstaben, Symbole (z.B. für Währungen) und Zeichen für Cherokee-Silben.
Arbeit mit Schriften und Schriftschnitten
|
225
Tabelle 12-3: Verfügbare lateinische Schriften, geordnet nach Betriebssystem. Großflächig unterstützte Schriften sind hervorgehoben. Mögliche Ersatzschriften für die verschiedenen Betriebssysteme bzw. die entsprechenden allgemeinen Schlüsselwörter sind angegeben. (Fortsetzung) Schrift
Betriebssystem Windows XP
Windows Vista & 7
Mac OS X 10.3
Mac OS X 10.5
Sylfaen
✓
✓
Baskerville
Baskerville
Tahoma
✓
✓
✓
✓
Times
Times New Roman
Times New Roman
✓
✓
Times New Roman
✓
✓
✓
✓
Trebuchet MS
✓
✓
✓
✓
Verdana
✓
✓
✓
✓
Zapfino
cursive
cursive
×
✓
×
×
✓
✓
Dingbats Apple Symbols
✓
✓
×
×
Symbol
✓
✓
✓
✓
Webdings
✓
✓
✓
✓
Wingdings
✓
✓
×
×
Zapf Dingbats
×
×
✓
✓
Marlett
7
Beispiele für die in Tabelle 12-3 aufgelisteten Schriften finden Sie in verschiedenen Quellen, so auch auf der Website zu diesem Buch.
Eigene Schriften definieren: Die Eigenschaft »font-family« Wenn Sie sich CSS-Stylesheets ansehen, scheint die Eigenschaft font-family eigentlich ganz einfach zu sein: Eigenschaft, Doppelpunkt, Schriftname, Komma, Schriftname, Komma, allgemeines Schlüsselwort, fertig. Das kann doch nicht so schwer sein, oder? Tatsächlich gibt es bei font-family aber einiges zu beachten: 1. Alle Schriften sollten exakt mit dem Namen angegeben werden, der auch in den Schriftsammlungen des vom Benutzer eingesetzten Betriebssytems verwendet wird. Hierzu gehörten auch die Groß- und Kleinschreibung und eventuelle Zusatzbezeichnungen. So ist Arial etwas vollkommen anderes als ’Arial Unicode MS’. Daher ist es eventuell nötig, mehrere Varianten der gleichen Schrift anzugeben. 2. Enthält der Name einer Schrift Leerzeichen, muss der Name in einfache oder doppelte Anführungszeichen gesetzt werden. 3. Die Reihenfolge der Namen in der Liste ist wichtig. Angenommen, Ihr Stylesheet enthält die folgende Regel: font-family: Futura,’Century Gothic’,sans-serif. In diesem Fall versucht der Browser zuerst, die ganz links stehende Schrift (Futura) für 7 Enthält viele Zeichen, die für die Beschriftung von Windows-Kontrollelementen verwendet werden.
226
|
Kapitel 12: Web-Typografie
die Darstellung zu verwenden. Ist dies nicht möglich (z.B. weil sie nicht installiert ist), wird die nächste Schrift (Century Gothic) probiert usw. Schlägt auch das fehl, wählt der Browser gemäß dem angegebenen allgemeinen Schlüsselwort (sans-serif) selbst eine Schrift aus, wie im nächsten Punkt erklärt wird. Die Liste für font-family kann beliebig viele Schriftnamen enthalten. 4. Die Liste sollte immer mit einem allgemeinen Schlüsselwort abgeschlossen werden. Mögliche Werte sind (siehe auch Abbildung 12-3): serif Serifenschrift, z.B. »Latin«, »Old Style«, »Antiqua« und »Copperplate« sans-serif Serifenlose Schriften, z.B. »Geometric« und »Grotesk« monospace Nichtproportionale Schriften wie »Courier New«, »Mono« oder »Typewriter« cursive Hierbei handelt es sich, einfach gesagt, um »schräg gestellte« Varianten der Ausgangsschrift, die oft mit zusätzlichen kalligrafischen Verzierungen versehen sind. fantasy Dekorativschrift. Kaum für lange Text geeignet. 5. Erhalten neuere Browser gültige HTTP-Header vom Typ Content-Type, ContentLanguage und charset, kann man davon ausgehen, dass korrekt implementierte Schriften auch wie gewünscht dargestellt werden. Bei älteren Browserversionen ist das aber nicht immer der Fall. Hier sollten Entwickler Fonts verwenden, die von sich aus mit dem angegebenen charset kompatibel sind (siehe im Abschnitt »Was ist Zeichenkodierung?« auf Seite 230). Für Seiten, die lateinische Schriften verwenden, besteht der sicherste Weg darin, Inhalte explizit mit dem passenden ISO 8859-x-Code zu kennzeichnen und auszuliefern. Auch wenn sich der Internet Explorer erfreulich von seinen Vorgängern abhebt, produziert er bei allgemeinen Schlüsselwörtern für font-family oft unvorhersagbare Ergebnisse. Daher sollte man darauf achten, dass vor dem Schlüsselwort ein unter Windows mit Sicherheit funktionierender Schriftname angegeben wird. Weitere Details zu diesem Thema finden Sie auf der Website zu diesem Buch.
Die richtigen Schriftnamen finden In Regel 1 wurde gesagt, dass die Werte für font-family exakt den Schriftnamen auf dem Benutzerrechner entsprechen müssen. Unter Windows finden Sie die installierten Schriften wie folgt:
Arbeit mit Schriften und Schriftschnitten
|
227
1. Öffnen Sie die Systemsteuerung, die Sie im Start-Menü unter Einstellungen oder Systemsteuerung finden. Alternativ dazu können Sie unter Windows Explorer auch den Pfad C:\WINDOWS eingeben. 2. In der Systemsteuerung finden Sie einen Ordner namens Schriftarten; bei der Verwendung von Windows Explorer heißt er C:\WINDOWS\Fonts (beide Dinge verweisen auf den gleichen Ort im Dateisystem). Öffnen Sie ihn, und navigieren Sie zu der Schriftdatei, die Sie in Ihrem Dokument verwenden wollen. 3. Öffnen Sie die gewünschte Schrift. In der Zeile Schriftart finden Sie den Namen, der für font-family angegeben werden muss (hier: Verdana). Am Mac geht das sogar noch einfacher. Öffnen Sie das Programm Schriftsammlung im Programme-Ordner, und wählen Sie in der linken Spalte den Eintrag Alle Schriften. Danach navigieren Sie in der mittleren Spalte zur gewünschten Schrift. Der hier angezeigte Name ist der für font-family benötigte Wert. In Abbildung 12-7 sehen Sie die Darstellungsprogramme für Schriften unter Windows und Mac OS X am Beispiel der Schrift »Verdana«.
Abbildung 12-7: Die Darstellungsprogramme für Schriften unter Windows (oben) und Mac OS X (unten)
228
|
Kapitel 12: Web-Typografie
Mit der Eigenschaft »font« auf Systemschriften zugreifen Normalerweise rate ich von der Verwendung der Kurzschrift-Eigenschaft font ab. Sie zwingt den Gestalter, ansonsten unnötige, typografische Werte zu definieren, die anderswo wieder überschrieben werden müssen, was das Stylesheet nur komplexer macht. Die wichtigste Ausnahme gibt es, wenn Sie auf die Systemschriften zugreifen müssen, was nur mit font möglich ist. Die Kurzschrift-Eigenschaft font fasst die Werte der einzelnen font-*-Einzeleigenschaften in einer Regel zusammen. Die Struktur sieht wie folgt aus: font-style font-variant font-weight font-size/line-height [font-family|Angabe zur Systemschrift]
Die einzelnen Werte sollten in der oben gezeigten Reihenfolge angegeben werden. Ist ein expliziter Wert für line-height nicht nötig, kann der Schrägstrich zur Trennung vom Wert für font-size weggelassen werden. Der Wert für font-family wird entsprechend der Einzeleigenschaft angegeben, wie im vorigen Abschnitt beschrieben. Alternativ kann bei font auch ein Schlüsselwort angegeben werden. Dieses bezeichnet die Systemschrift für bestimmte Elemente der Benutzerschnittstelle, wie Formulare und Fensterelemente (siehe Tabelle 12-4). Tabelle 12-4: Schlüsselwörter für Systemschriften für Elemente der Benutzerschnittstelle des BenutzerBetriebssystems Schlüsselwort
Entsprechende Betriebssystem-Elemente
caption
Entspricht den Einstellungen z.B. für Beschriftungen von Buttons und Aufklappmenüs
icon
Beschriftung von Icons des Betriebssystems (Festplatten, Ordner, Dateinamen etc.)
menu
Die in Aufklappmenüs und Menülisten verwendete Schrift
message-box
Texteinstellungen für Dialogboxen, wie sie z.B. per window.alert() erzeugt werden
small-caption
Text für kleine Steuerelemente mit Beschriftung
status-bar
Schrift für die Statusleiste von Fenstern
In CSS3 ist geplant, die neue Kurzschrift-Eigenschaft appearance für diesen Zweck zu verwenden. Mehr dazu finden Sie auf der Website des W3C (http://www.w3.org/TR/ css3-ui/#system0).
Überblick über die Zeichenkodierung Besonders die letzte Regel zur Verwendung von font-family kann verwirrend wirken, da Gestalter nicht immer Zugriff auf die HTTP-Antwort-Header haben. Jeder korrekt konfigurierte Webserver, der das Hypertext Transfer Protocol (HTTP) richtig implementiert (das sind fast alle), liefert zusammen mit dem angeforderten Dokument auch die richtigen Header für dessen Sprache und Zeichenkodierung an den Browser zurück. Zusätzliche Schnittstellen, wie das meta-Element oder die PHP-Funktion
Überblick über die Zeichenkodierung
|
229
Header() geben Entwicklern die Möglichkeit, diese Zuweisungen bei Bedarf mit eigenen Werten zu überschreiben. Weitere Details hierzu finden Sie im Anhang zu diesem Buch.
Was ist Zeichenkodierung? Hoffentlich kennen Sie sich mit dem Prinzip von Bits und Bytes aus. Ein Bit beschreibt den Zustand eines einzelnen Schaltkreises im Arbeitsspeicher des Systems. Ein Byte entspricht acht dieser Zustände in einer logischen Reihe. Hierdurch lassen sich 256 verschiedene Zustände ausdrücken. In den meisten westlichen Sprachen haben wir uns daran gewöhnt, die verschiedenen Buchstaben und Zeichen eines Alphabets mit einem Byte auszudrücken. Stellen Sie sich hierzu einmal das Morse-Alphabet vor: Hier wird ein Buchstabe als unterschiedlich lange Folge von Punkten (entsprechend einem nicht gesetzten Bit) und Strichen (entsprechend gesetzten Bits) ausgedrückt. Diese Zeichenfolgen konnten zu Wörtern kombiniert werden und wurden typischerweise zum Übermitteln von Telegrammen benutzt. Im Innern eines Computers sind dagegen systematischere Zuweisungen möglich. Bei der Definition des Worts »systematisch« stellen sich die folgenden Fragen: • Sollen Großbuchstaben vor oder nach Kleinbuchstaben stehen? • Stehen Kontrollzeichen (Zeilenumbruch, Wagenrücklauf etc.) am Anfang oder am Ende des Zeichensatzes? • Enthält das Kodierungsschema Anweisungen darüber, ob das erste Bit eines Zeichens sich auf die Codepositionen Null und Eins bezieht oder auf die gesamte obere oder untere Hälfte des Bereichs von 0 bis 255? • Welche Beschränkungen des Betriebssystems könnten Auswirkungen auf das endgültige Kodierungsschema haben? • Welche Codepositionen sollten nicht zugewiesen werden, um auf zukünftige Entwicklungen, wie z.B. die Einführung neuer Währungssymbole, vorbereitet zu sein? • Welche Zuweisungslogik soll für logografische Schreibsysteme wie Hanzi und Kanji oder komplexe Silbensprachen wie Hangul verwendet werden? • Ist eine bestimmte Kodierung für alle Nutzer einer gemeinsamen Orthographie sinnvoll? Die schiere Menge der heutzutage verwendeten Zeichenkodierungen lässt sich durch die Vielzahl an Antworten erklären, die Ingenieure auf diese Fragen haben. Im Web müssen die meisten dieser Zeichensätze natürlich unterstützt werden.
ASCII, ISO 8859-1, Unicode und UTF-8 Mitte der 1960er-Jahre arbeiteten verschiedene Gruppen zusammen an einem neuen, 128 Zeichen umfassenden (7-Bit-)Kodierungsschema für die lateinischen Buchstaben, die im amerikanischen Englisch verwendet wurden. Dieses Schema wurde unter dem Namen 230
|
Kapitel 12: Web-Typografie
ASCII (American Standard Code for Information Interchange) bekannt. Es basierte auf früheren Kodierungen für Telexgeräte. Einige Jahre später wurde verfügt, dass sämtliche Computer, Speicher- und Übertragungsgeräte, die von der US-Regierung angeschafft wurden, diesen Standard unterstützen mussten. Kurz darauf war ASCII aus der englischsprachigen Welt nicht mehr wegzudenken. In den 80er-Jahren veröffentliche die International Organization for Standardization (ISO) einen statischen 8-Bit-Standard für die Kodierung mehrerer europäischer und nahöstlicher Alphabete. Viele von ihnen waren Varianten des einfachen lateinischen Alphabets. Alle diese Kodierungsschemata bestehen zur Hälfte aus dem ASCII-Code und sind auch heute noch im Einsatz, wie etwa das ISO 8859-Schema. Zeitgleich wurde versucht, Standardkodierungen auch für andere Schreibsysteme zu entwickeln, besonders in Japan. In den frühen 1990er-Jahren wurde diese Arbeit im Unicode-Standard zusammengefasst, der seitdem immer weiter ausgedehnt wird. Das erklärte Ziel ist es, alle bekannten Schreibsysteme, inklusive antiker Schriften und solcher, die in historischen Aufzeichnungen verwendet wurden, zusammenzufassen. Im Unterschied zu früheren Kodierungen kann die Bitlänge in Unicode variieren. Aktuell umfasst der Unicode-Standard mehr als 100.000 Zeichen. Im Web werden die normalerweise benötigten Zeichen meist nach dem UTF-8-Schema (8-Bit Unicode Transformation Format) kodiert. Hierbei werden alle ASCII-Zeichen in einem von vier möglichen Bytes kodiert, wodurch die Rückwärtskompatibilität auch älteren ASCII-basierten Systemen sichergestellt werden soll.
Das richtige Kodierungsschema wählen Standardmäßig liefern Webserver die angeforderten Dokumente typischerweise als UTF-8 kodiert aus. Wenn Ihre Inhalte in Englisch geschrieben sind und Sie HTML-Entities verwenden, um Zeichen außerhalb des ASCII-Zeichensatzes darzustellen (wie später in diesem Kapitel besprochen wird), besteht keine Notwendigkeit, die Serverkonfiguration anzupassen. Auch spezielle HTTP-Header sind nicht notwendig, wenn es nur darum geht, den richtigen Zeichensatz anzugeben. Das hat zwei Gründe: • Der erste Grund hat mit der Effizienz des Kodierungsschemas zu tun: ASCII-basierte Inhalte verwenden 7 Bit pro Zeichen. Der zusätzliche Aufwand, Zeichen-Entities zu definieren, kann außer Acht gelassen werden, wenn man ihn mit den Schwierigkeiten vergleicht, Zeichen mit hohen Bitwerten (über 128) mit unsicherer Kodierung direkt zu verwenden. • Der zweite Grund, aus dem UTF-8 hauptsächlich für Inhalte in europäischen Sprachen geeignet ist, hat damit zu tun, wie moderne Browser mit Schriften umgehen. Die Standardeinstellung für Zeichenkodierungen erfolgt in den meisten Browsern automatisch, was im Falle von ASCII nur wenig Bedeutung hat. Diese Einstellung ermöglicht es den Bowsern, Zeichen-Entities unabhängig von der Kodierung der verwendeten Schrift korrekt darzustellen. Schließlich sind die Beziehungen zwischen den Unicode-Codepositionen und denen in anderen Kodierungsschemata
Überblick über die Zeichenkodierung
|
231
gut dokumentiert. Der Browser kann diese Codepositionen bei Bedarf transparent übersetzen und so das gewünschte Zeichen darstellen. UTF-8 und die automatische Wahl der Kodierung sind aber nicht das Ein und Alles bei der Darstellung von Schriften. Eine Reihe von Umständen kann trotzdem zu falsch dargestellten Zeichen in Ihrem Dokument führen. Am häufigsten sind Formulareingaben von Browsern mit abweichenden Kodierungseinstellungen und das Kopieren und Einfügen von Text aus Textverarbeitungsprogrammen. Dieser wird bei der Verwendung eines lateinischen Alphabets meist als 8-Bit-Zeichen statischer Länge kodiert. Wenn diese »verdrehten« Zeichen es bis in Ihre Texte schaffen, stellt der Browser des Benutzers sie möglicherweise nicht korrekt dar. Treten diese Probleme häufiger auf, ist es unter Umständen sinnvoll, die Zeichenkodierung Ihrer Dokumente in ISO 8859-x oder Windows-1252 zu ändern (die fast identisch sind). Entwickler, die mit asiatischen Inhalten arbeiten, sollten ggf. ähnlich verfahren.
Zeichen-Entities zur Definition von Nicht-ASCII-Zeichen Europäische Sprachen verwenden eine Reihe von diakritischen Zeichen (Ä, ø, ß etc.). Ist eine durchgehende Verwendung von UTF-8 oder einer anderen 8-Bit Zeichenkodierung nicht möglich, können Sie auf die in HTML 4 definierten Zeichen-Entities zurückgreifen. In Tabelle 12-5 sehen Sie eine Übersicht diakritischer Zeichen, die häufig in europäischen Sprachen verwendet werden und die entsprechenden Zeichen-Entities: Tabelle 12-5: Häufige europäische diakritische Zeichen und die entsprechenden HTML 4-ZeichenEntities Name
diakritische Zeichen
Zeichen-Entity
Beispiel
Akut-Akzent
¤
&?acute;
é, í
Cedille
|,
&?cedil;
ç
Zircumflex-Akzent
|^
&?circ;
ô
Grave-Akzent
`
&?grave;
~
&?tilde;
à ~n, â
&?uml;
ö
Tilde Umlaut
«
Die diakritischen Zeichen können nicht beliebig mit allen Buchstaben kombiniert werden. Ist eine Kombination möglich, gilt sie für Groß- und für Kleinbuchstaben. Eine vollständige Tabelle der HTML-Zeichen-Entities finden Sie auf der Website zu diesem Buch. Diese von Adrian Roselli (http://adrianroselli.com/) zusammengestellte Liste enthält außerdem die Dezimalcodes für hochbittige IS0 8859-x-Zeichen, die in XHTML nicht korrekt dargestellt werden. Neben den diakritischen Zeichen gibt es eine Reihe von Sonderzeichen, die hilfreich sein können, wenn Gestalter einen hohen typografischen Standard einhalten müssen. Viele dieser Zeichen finden Sie in Tabelle 12-6.
Festes (nicht umbrechendes) Leerzeichen Gedankenstrich kurz
–
–
–
- für Wertebereiche
Gedankenstrich lang
–
—
—
- mit Leerzeichen umgeben, oder --
Grad
°
° (U+00B0)
8 Einige Symbole werden möglicherweise als Werte für die Eigenschaft content verwendet. Diese sind in Dezimal- als auch in hexadezimaler Unicode-Schreibweise aufgeführt. Weitere Informationen finden Sie in der Diskussion zur Eigenschaft content in den »Schlechten Seiten«. 9 Ein-Viertel- und Drei-Viertel-Brüche können ebenfalls nach dem hier gezeigten Muster angegeben werden. 10 Die einzigen von XML unterstützten Entity-Namen sind &, < und > (&, < bzw. >). Bei der Verwendung von XML sollten sämtliche Entities in dieser Tabelle mit ihren numerischen Werten angegeben werden.
’, ’’, ', ",vergangene Stunde:Minute x, X; * in nicht mathematischem Kontext
Minuten- oder Fuß-Zei- ′ ″ chen, Sekunden- oder Zoll-Zeichen Multiplikationszeichen
×
×
×
Paragraf-Zeichen
§
§
§ (U+00A7)
Pfund (Währung)
£
£
£ (U+00A3)
Plus/Minus
±
±
±
12
+/-
‰
‰
‰
Punkt in der Zeilenmitte
·
·
Rund, etwa
≈
≈
Spanisches Ausrufungs- ¿ zeichen, Fragezeichen
¡ ¿
¡ ¿
Spitze Anführungszeichen
«»
« »
« »
" in manchen
(U+00AB, U+00BB)
Sprachen
Trademark-Zeichen
2
™
™
(tm) etc.
Ungleich
6¼
≠
≠
!=
Yen-Symbol, YuanSymbol
¥
¥
¥ (U+00A5)
RMB für chinesische Währungsangaben
Promille-Zeichen
~
Beachten Sie, dass die Unicode-Angaben in der vierten Spalte von Tabelle 12-6 nicht verlässlich sind, wenn eine andere Zeichenkodierung als UTF-8 für das Dokument gewählt wurde.
Ausgewogene Schriftgestaltung Wenn Sie schon einmal Dokumente erstellt haben, dann wissen Sie, dass man den »Erpresserbrief-Effekt« vermeiden sollte – das Nebeneinander zu vieler verschiedener Schriften in einem Dokument. Im Web entsteht dieser Effekt aber nicht nur durch zu viele Schriften. Er hat auch mit den Farben, Größen und Schriftschnitten zu tun, die Sie verwenden. 11 Einige Symbole werden möglicherweise als Werte für die Eigenschaft content verwendet. Diese sind in Dezimal- als auch in hexadezimaler Unicode-Schreibweise aufgeführt. Weitere Informationen finden Sie in der Diskussion zur Eigenschaft content in den »Schlechten Seiten«. 12 Das Promyriade-Zeichen (‰) befindet sich auf der folgenden Codeposition (8241), ist aber nicht Teil der HTML 4-Spezifikation.
234
|
Kapitel 12: Web-Typografie
Vorhersagbarkeit und Panik Eine Website ist normalerweise in verschiedene Bereiche unterteilt, die aus einer oder mehreren Seiten bestehen. Die Möglichkeit, Webdokumente hierarchisch zu organsieren, hat Vorteile. So ist es nicht nur möglich, sondern einfach, die Präsentation einer Site äußerst konsistent zu gestalten. Das zahlt sich auf auch auf lange Sicht aus. Die Arbeitsbelastung von Designern und Gestaltern wird verringert, und Seitenbestandteile, die als Wegweiser dienen, sind leicht zu erkennen und zu kennzeichnen. Leider hat die Konsistenz auch ihre Grenzen. Besonders bei benutzergenerierten Inhalten (z.B. Blog-Kommentaren) ist es fast unmöglich, vorherzusagen, wie viel Inhalt eine Seite am Ende enthält. Dies hat einen gewissen Kontrollverlust zur Folge. Dieser kann wiederum zu panikartigen Versuchen führen, das Verhalten und die inhaltliche Aufbereitung eines Seitenlayouts zu verändern. Dies können kleine, aber Site-weite Anpassungen von Zwischenräumen, Trennlinien und Schriftgröße sein. Tatsächlich ist das fallweise Lösen der Layoutprobleme nur oberflächlich eine Erleichterung.
Die Grenzen von Inhalten ermitteln Der erste Schritt, um mehr Kontrolle über die Schriftgestaltung zu erlangen, besteht darin, mithilfe der Kaskade festzustellen, wo die Grenzen Ihrer Inhalte liegen. Eine typische Website kann einige oder alle der folgenden Elemente enthalten: •
»Anreißertexte« und/oder Werbung (multimediale Inhalte, die Besucher anregen sollen, einem Link auf eine andere Seite zu folgen)
•
Formulare
•
Applikationsfunktionalität
•
… und natürlich Hyperlinks
Ausgewogene Schriftgestaltung
|
235
Derart viele Elemente mit unterschiedlichen Funktionen verleiten Designer leicht zu zwei großen Fehlern. Der erste wurde schon genannt: das Verlangen, Anpassungen fallweise vorzunehmen, was den eigentlichen Sinn von CSS für Gestalter komplett verdreht. In kürzester Zeit ist das Template derartig voll mit überflüssigen id-, class- und anderen Elementen, dass der resultierende Markup-Code kaum noch wiederzuerkennen ist. Der zweite Fehler besteht in der Annahme, für jedes wichtige Designelement würde ein eigenes Schriftdesign gebraucht. Das ist nicht der Fall. Tatsächlich gibt es gerade einmal sechs verschiedene Arten von Elementen, für die möglicherweise ein eigenes Schriftdesign nötig ist: • Identität der Website • Titel (Hauptüberschriften) • ergänzende Überschriften • Haupttext • Navigation • Hyperlinks Bei vielen Designs wird außerdem erwartet, dass sekundäre Inhalte wie Zitate und Seitenleisten eine eigene Schriftgestaltung erhalten. Anstatt die Liste in Gedanken zu ergänzen, sollten Sie sich fragen: Warum muss dieser Teil eigentlich anders aussehen?
In der Liste steht jeder Eintrag für einen wichtigen Teil einer Site. Er dient als wichtige Wegmarke innerhalb der Seite oder der Site, oder er dient als primärer Inhalt und muss daher hervorgehoben werden.
Schrift unterscheiden: Schriftschnitt, Größe, Gewicht, Stil und Farbe Die Informationen in diesem Abschnitt mögen offensichtlich erscheinen. Ihre Erwähnung soll hier als Rahmen für Designentscheidungen dienen.
Wenn Sie wissen, welche Schriftgestaltung für welche Inhalte verwendet werden soll, müssen Sie entscheiden, wie Sie Ihre Designkonzepte umsetzen. Es gibt verschiedene Parameter, mit denen Sie Textteile voneinander unterschiedlich gestalten können: Schriftart, Schriftgröße, Schriftgewicht, Schriftstil und Schriftfarbe. Die Möglichkeit, Inhaltsbereiche mit eigenen Hintergrundfarben zu versehen, kann bei Ihrer Entscheidung helfen, entscheidet aber nicht für Sie. Aufgrund von Traditionen und Gewohnheiten haben diese Einstellungen eine unterschiedliche Wirkung beim Benutzer.
236
|
Kapitel 12: Web-Typografie
Schriftart Verschiedene Schriften geben Hinweise auf die Art des Inhalts. So werden die Überschriften mancher Zeitungen in einer serifenlosen Schrift gedruckt, während der eigentliche Text eine Serifenschrift verwendet. Dieser Ansatz ist allerdings nicht so beliebt, wie es scheint – weder für Überschriften noch für zusätzliche Inhalte. Die Gründe können traditioneller, aber auch praktischer Art sein (z.B. verschiedene Schriftabmessungen). Schriftgröße Die Schriftgröße kann einen Hinweis auf die relative Wichtigkeit einer Passage geben. Gleichzeitig ist dies auch der Grund für viele Problemfälle bei der Arbeit mit Stylesheets. Jedes Mal, wenn unterschiedliche Schriftgrößen gebraucht werden, muss auch die übrige Darstellung angepasst werden. Diese Situationen haben schon so manchen Gestalter um seinen wohlverdienten Schlaf gebracht. Schriftgewicht Fettgedruckter Text verstärkt den Inhalt, allerdings nur, wenn die Linienstärke der Buchstaben sich nicht zu stark von den Nachbarelementen unterscheidet. Eine Änderung des Schriftgewichts signalisiert eine Änderung der Wichtigkeit in Halbschritten, während eine offensichtliche Größenänderung für einen ganzen Schritt steht. Schriftstil Die Verwendung von schräggestelltem Text (kursiv oder oblique) signalisiert Änderungen im »Tonfall« des Schreibers, normalerweise als Form der Hervorhebung. Diese Schriftstile werden außerdem verwendet, um Eigennamen (wie Titel von Zeitschriften, künstlerischen Werken, Namen von Schiffen und Flugzeugen und seltener auch von berühmten Einrichtungen) zu kennzeichnen. Kapitälchen und ein weiter Buchstabenabstand werden ebenfalls zur Betonung von Textteilen benutzt, jedoch deutlich seltener. Schriftfarbe Die Verwendung von verschiedenen Schriftfarben ist im Web deutlich einfacher als in anderen Medien. Allerdings kann sie für Benutzer mit verminderter Farbwahrnehmung ein Problem sein. Aus diesem Grund sollten die Änderungen sowohl in der Helligkeit als auch im Farbton vorgenommen werden. Dabei ist es egal, ob dies für Links oder für anderen Text, der betont werden soll, geschieht. Idealerweise werden farbliche Änderungen daher mit anderen Anpassungen der Schriftdarstellung kombiniert. In Kapitel 9 werden diese Änderungen detailliert besprochen. Im Allgemeinen gilt auch hier: Je weniger Parameter Sie in der Darstellung ändern, desto besser. Zu viele Änderungen an den Einstellungen der Textdarstellung »überfahren« den Besucher möglicherweise. Sobald Sie wissen, welche Anpassungen Sie vornehmen wollen, müssen Sie sich um die Details der Darstellung kümmern. Am schwierigsten ist die Entscheidung, wie auf ungewöhnliche Situationen reagiert wird:
Ausgewogene Schriftgestaltung
|
237
• Was passiert, wenn der Inhalt mehr Platz beansprucht als erwartet? Dies ist besonders wichtig, wenn ein Layoutraster verwendet wird. • Wie unterscheiden Sie Textpassagen mit ähnlicher Wichtigkeit, aber unterschiedlicher Funktion, z.B. Überschriften für den Haupttext und für die Seitenleiste? • Hat der Designer sich für einen print-orientierten Ansatz entschieden, gibt es vermutlich kleine Unterschiede zwischen den Designelementen. Wie schafft es der Gestalter, die wild gewordene Meute von CSS-Regeln zu bändigen?
Das »Überlaufen« von Text verhindern Die letzten beiden Fragen lassen sich mit einem gut geschriebenen Stylesheet beantworten. Die einfachste Möglichkeit, das »Überlaufen« von Text in andere Elemente zu vermeiden, besteht in der Verwendung möglichst weniger Regeln für Text- und Box-Eigenschaften. Danach benutzen Sie die Regel overflow: hidden für die Box-Eigenschaften und geben die Verantwortung an die Texter ab. In Umgebungen, in denen das Fehlen angemessener Beschränkungen normal, aber vermeidbar ist, befürworte ich diesen Ansatz. (Die Beschränkung des Platzes für Inhalte fördert Einfachheit und Klarheit. Jeder Twitter-Benutzer weiß, was damit gemeint ist.) Ist die einfache Lösung nicht machbar, was leider recht oft der Fall ist, muss der Gestalter eine andere Lösung finden. Was machen Sie beispielsweise, wenn eine Überschrift, für die im Design eigentlich nur eine Zeile vorgesehen ist, so lang ist, dass zwei Zeilen für die Darstellung gebraucht werden? Eine Verringerung der Schriftgröße ist vermutlich keine Lösung. Vielleicht reicht aber schon ein kleinerer Wert für line-height aus, um die lange Überschrift auf einer Zeile unterzubringen. Ein anderer Fall sind mit Bindestrich zusammengesetzte Wörter, die nicht auf eine Spalte passen. Der Internet Explorer umbricht die Zeile am Bindestrich, andere Browser tun das aber nicht. Das Einfügen eines »Nichtverbinders der Breite null« (, normalerweise verwendet, um einen logischen, aber unsichtbaren Leerraum zwischen zwei Zeichen zu schaffen) sorgt hier ebenfalls nicht für einen Zeilenumbruch. In jedem Fall sollte die Schriftgestaltung zum Verhindern des Überlaufens von Text: • dem Layoutraster folgen • logisch zu den übrigen Schriftgrößen der bereits vorhandenen Stile und Schriftgestaltung passen • mit dem verfügbaren Platz auskommen, ohne die allgemeine Vorgehensweise groß zu ändern
238
|
Kapitel 12: Web-Typografie
Stile für Textpassagen mit gleicher Priorität Die Arbeit des Gestalters ist am einfachsten, wenn der Designer mit einem Grundstil beginnt und andere Stile davon ableitet. CSS ist für diesen Ansatz gut geeignet. In einem simplen zweispaltigen Layout könnte das etwa so aussehen: Haupttext 12px Georgia; schwarz Überschriften werden in 4-Pixel-Schritten, beginnend bei h4 (hat normalerweise die Standardschriftgröße), gesteigert. Seitenleiste Sämtlicher Text wird auf 75 % Schwarz aufgehellt. Navigation Eine Vergrößerung um 4 Pixel für die Hauptnavigation; normale Textgröße für die sekundäre Navigation; Farben werden über die Pseudoelemente für Links gesteuert. Ein Stylesheet, das diesem Ansatz folgt, würde die folgenden Regeln enthalten: body { color: rgb(0,0,0); font-size: 12px; font-family: Georgia, serif; } h1 { font-size: 2em; } h2 { font-size: 1.667em; } h3 { font-size: 1.333em; } #seitenleiste { color: rgb(64,64,64); } #hauptnavigation a:link { color: rgb(0,0,192); } #hauptnavigation a:link { color: rgb(0,192,0); } #hauptnavigation a:active, #unternavigation a:active { color: rgb(192,0,0); }
Normalerweise sind zusätzliche Selektoren nötig, um die verschiedenen Abschnitte einer Site zu unterscheiden. Das Grundprinzip sollte aber klar sein. Die Probleme vergrößern sich immens, wenn ein Designer aus dem Printbereich beginnt, Dinge anzupassen. Kann beispielsweise die Überschrift einer Spalte nicht verkürzt werden, könnte der Designer versuchen, die Schriftgröße zu verringern, um die Konsistenz zu wahren. Lassen Sie ihn das drei- oder viermal auf der gleichen Website machen, und in kürzester Zeit müssen Sie Selektoren wie diesen schreiben: body.ueber_uns#kontakt #seitenleiste h3.telefonnummern
Wenn Sie Selektoren wie diesen verwenden, kann es schnell passieren, dass Sie das gleiche Spiel auch für die Elemente zwischen body und body.ueber_uns#kontakt #seitenleiste h3.telefonnummern schreiben müssen.
Ausgewogene Schriftgestaltung
|
239
Schriftübersichten Das gerade beschriebene Szenario hätte sich vermeiden lassen, wenn man sich vorher darauf geeinigt hätte, dass die Überschriften der Seitenleiste ggf. auch zwei Zeilen lang sein dürfen. Genau dafür gibt es Stilrichtlinien. Ein Teil dieser Richtlinien ist außerdem eine Übersicht über alle im Projekt verwendeten Schriften. Wenn ich eine Schriftübersicht erstelle, sieht das ungefähr so aus wie in Abbildung 12-8 – eine dreispaltige Darstellung mit folgender Aufteilung: 1. die Funktion und möglicherweise die Selektoren für die einzelnen Elemente (Website-Identität, Hauptüberschrift, Einleitung, Haupttext) 2. ein Beispiel für die Benutzung der Schrift 3. die verschiedenen Parameter für die Schrift, auf Deutsch oder in Form der verwendeten CSS-Regeln
Abbildung 12-8: Ein Beispiel für eine dreispaltige Schriftübersicht (erstellt vom Autor)
Hat der Designer einer Site sämtliche Ausnahmen und Sonderfälle berücksichtigt, kann die Schriftübersicht schnell mehrere Seiten lang werden. Dies ist ein deutliches Zeichen dafür, dass bestimmte Aspekte des Designprozesses außer Kontrolle geraten sind. Noch wichtiger ist aber, dass eine effektive Schriftübersicht die vielen Designentscheidungen in einer Form dokumentiert, die von Menschen besser gelesen werden kann als Stylesheets. Dies kann im Falle von wechselnden Mitarbeitern oder mangelnder Pflege der Site eine Menge Zeit sparen.
Verschiedene typografische Aspekte von CSS Es gibt eine Reihe von weniger bekannten CSS-Eigenschaften, die zeigen, wo die Grenzen dessen liegen, was Designer mit CSS steuern können. Andererseits demonstrieren sie aber auch die vielen Abstufen zwischen »schlicht« und »elegant«.
240
|
Kapitel 12: Web-Typografie
Die Eigenschaft »line-height« Wie bereits gesagt wurde, steuert die Eigenschaft line-height, wie viel Leerraum zwischen den einzelnen Zeilen eingefügt wird. Dies entspricht ungefähr dem »Durchschuss« im Printbereich. Wie Abbildung 12-9 zeigt, wird der Leerraum gleichmäßig ober- und unterhalb der jeweiligen Zeile eingefügt. Zumindest in aktuellen Browsern ist dieses Verhalten konsistent. Wie Sie sehen, fügen ältere Browser den Leerraum teilweise nur unterhalb oder nur oberhalb (wie z.B. IE 6) der Zeile ein.
Internet Explorer 6 Firefox und Safari (ältere Versionen) Safari 3+, Firefox 2.5+, Internet Explorer 7+
Abbildung 12-9: Das Verhalten der Eigenschaft »line-height« in verschiedenen Browsern (hier am Beispiel der Times New Roman, Schriftgröße 16 Pixel, »line-height«: 32 Pixel)
Ein weiteres bemerkenswertes Detail von line-height ist die Möglichkeit, Werte auch ohne Längeneinheit anzugeben, wie hier: line-height: 1.5;
Dies funktioniert so ähnlich, als hätten Sie stattdessen den Wert 150% oder 1.5em angegeben. Aus Gründen der Konsistenz und Disziplin bevorzuge ich es normalerweise, für lineheight die gleichen Längeneinheiten zu verwenden wie für die anderen Schrift- und Texteigenschaften auch. Die Standardzeilenhöhe geben Sie mit line-height: normal an. Diese kann jedoch je nach Betriebssystem und Browser unterschiedlich ausfallen. Meist werden kleinere Werte im Bereich zwischen 120 % und 125 % als Standard verwendet.
Die Eigenschaften »font-variant« und »text-transform« Die Eigenschaften font-variant und text-transform haben meist die Funktion, seltene Formen von Hervorhebungen zu realisieren. Das kann beispielsweise ein großgeschriebenes Warenzeichen oder eine zitierte Passage sein, die besonders betont werden soll. Die Eigenschaft text-transform wird nur selten benutzt, und ihre Werte (von denen uppercase am häufigsten verwendet wird) sind kaum der Rede wert. Die Eigenschaft font-variant und ihr einziger nicht standardmäßiger Wert, small-caps, ist da schon eine andere Sache. Wird die Großschreibung eines Wortes nur über verschiedene Schriftgrößen realisiert, haben die Buchstaben das gleiche Aussehen. Wird dagegen die Eigenschaft font-variant
Verschiedene typografische Aspekte von CSS
|
241
verwendet, werden die Kleinbuchstaben durch einen eigenen Schriftschnitt ersetzt, in dem die tatsächlichen Großbuchstaben etwas »fülliger« daherkommen. Das gleiche Ergebnis tritt bei der Verwendung von Schriften auf, die ausschließlich für den Printbereich erstellt wurden. Besonders auffällig ist das, wenn die Regel font-variant: smallcaps verwendet wird.
Die Eigenschaften »letter-spacing« und »word-spacing« Änderungen der Buchstaben- und Wortabstände werden normalerweise vermieden. Manchmal müssen die Abstände aber angepasst werden, damit ein Gestaltungselement exakt das gewünschte Aussehen bekommt. Ebenfalls selten ist die Verwendung dieser Eigenschaften, um Textteile zu betonen, so als würde der Sprecher jede Silbe eines Wortes a-a-a-u-u-u-s-s-s-d-e-e-e-h-n-e-e-e-n. Größere Buchstabenabstände können helfen, diese Betonung auch außerhalb von Dialogen darzustellen. Die Werte für letter-spacing und word-spacing werden üblicherweise als kleine em-Werte definiert (z.B. letter-spacing: 0.02em). Dabei gibt es allerdings ein kleines Problem. Auf dem Mac wird dieser Wert zunächst auf ganze Pixel gerundet, bevor er auf die Darstellung angewendet wird. Windows ist da, zumindest wenn ClearType aktiviert ist, etwas flexibler.
Die Eigenschaft »white-space« Das Element pre ist etwas ungewöhnlich, weil es Inhalte, bei denen die Textanordnung eine Rolle spielt (z.B. in Gedichten), so wie im Quellcode definiert darstellen kann. Andererseits wird seine Fähigkeit, Zeilenumbrüche ohne das Einfügen von br- oder zusätzlichen div-Elementen zu realisieren, häufig missbraucht. Definieren Sie für ein Element die Regel white-space: pre, so verhält es sich, als wäre es mit pre-Tags umgeben. Die Verwendung dieser Regel bedeutet außerdem zusätzliche Flexibilität für Entwickler. Auf diese Weise können echte vorformatierte Inhalte von solchen unterschieden werden, deren Darstellung einfach nur sehr genau gesteuert werden muss. Abgesehen vom Standardwert normal, kennt die Eigenschaft drei weitere Werte, die sich von pre in ihrer Handhabung von »weichen« und »harten« Zeilenumbrüchen untescheiden.
Gute Webtypografie in der Praxis Sobald Besucher die Farbpalette einer Website wahrgenommen haben (siehe im Abschnitt »Eigene Farbpaletten erstellen« auf Seite 154), besteht der nächste große Eindruck im Aussehen des Textes. Angesichts der hohen Erwartungen heutiger Besucher bietet das Web endlich die Werkzeuge, mit denen eine große Vielfalt an typografischen Details umgesetzt werden kann. Tatsächlich entspricht die Webtypografie inzwischen wesentlich stärker den Erwartungen an ästhetische Qualität als früher. Leider ist für die Umsetzung ein ziemlich hohes Maß an Theoriewissen nötig. Hat man die Theorie jedoch verstanden, wird die Praxis umso leichter.
242
|
Kapitel 12: Web-Typografie
KAPITEL 13
Saubere und zugängliche Formulare
Für die Webentwicklung ist mehr nötig als CSS-Layout und Typografie. Natürlich gibt es Websites, die den Besuchern nur Informationen anbieten. Webapplikationen müssen dagegen in der Lage sein, auch Informationen von den Besuchern entgegenzunehmen. Das heißt, für Webapplikationen ist das Design und die Implementierung von Formularen lebensnotwendig. Benutzergenerierte Inhalte kommen ohne Formulare nicht aus. Und wo Formulare sind, ist die Gefahr, die Benutzerfreundlichkeit zu verderben, nicht weit. Dieses Kapitel stellt Techniken für das Design und die Implementierung von Formularen vor, die das Risiko schwerwiegender Fehler verringern.
Effektive Formulare erstellen Für die Erstellung nützlicher Formulare reicht die Kenntnis des nötigen Markups nicht aus. Es ist mindestens ebenso wichtig, dass Sie verstanden haben, wie Formulare funktionieren.
Webapplikationen, Benutzerperspektive und Design-Entscheidungen Stellen Sie sich vor, Sie hätten eine SQL-Datenbank mit einer Sammlung von Gedichten. Die Datenbank bietet zahllose Möglichkeiten, den Inhalt zu sortieren und anzuordnen. Das Herz dieser imaginären Website beschreibt, wie die Tabelle (hier am Beispiel von MySQL) aufgebaut ist. Der Code ist mehr oder weniger für Menschen lesbar: CREATE TABLE gedichte ( id autor_id hinzugefuegt_datum veroeffentlicht_datum besprechung herausgeber_id buch_id sprache_id originalsprache_id
Um die Lesbarkeit zu erleichtern, haben wir hier keine zusätzlichen Definitionen für die Tabelle aufgeführt. Ein Blick auf die Tabellenstruktur reicht einem erfahrenen Applikationsentwickler, um zu erkennen, nach welchen Kriterien das Design des Datenbank-Backends der Website aufgebaut ist. So ist zu erkennen, dass die Informationen zu Autor, Übersetzer und Website-Betreiber (Herausgeber) in separaten Tabellen der gleichen Datenbank gespeichert sind. Wenn man die Struktur aus der Sicht des Benutzers betrachtet, stellt man fest, dass bestimmte Ansichten der Site auch ohne hohe Ressourcenanforderungen möglich sind. Diese Ansichten beeinflussen alle anderen Aspekte der Site, besonders ihre Informationsarchitektur und den Entwicklungsprozess. Folgende Informationen lassen sich mit einfachen SELECT-Abfragen darstellen: • Autor • Erstveröffentlichung • Ursprünglich erschienen in (Buch/Sammlung) • Anzeigesprache • Quellsprache • Titel • Übersetzer Neben diesen Ansichten ermöglicht das Feld veroeffentlicht_datum den einfachen Export neuer Inhalte als RSS-Feed, während andere Felder, insbesondere text einen eigenen Zusammenhang für die Volltextsuche schaffen. Für alle diese Ansichten gibt es mehrere Möglichkeiten, die Formulare und Inhaltstabellen anzulegen, mit denen der Inhalt gefunden werden kann. Ist der fragliche Inhalt benutzergeneriert, sind die Designentscheidungen für das Formular zum Veröffentlichen mindestens genauso vielfältig. Der einfachste Ansatz besteht in der Verwendung des CRUD-Konzepts.
Benutzerschnittstellen nach Funktion ordnen Wenn wir uns den Inhalt als Datensätze vorstellen, gibt es vier Aktionen, die damit möglich sind. Diese werden im Englischen mit CRUD abgekürzt. CRUD steht für create (erstellen), read (lesen), update (aktualisieren) und delete (löschen). In den nachgestellten Klammern stehen die entsprechenden SQL-Anweisungen:
244
|
Kapitel 13: Saubere und zugängliche Formulare
Erstellen (INSERT, CREATE) Erstellen von neuen Datensätzen oder Tabellen. Formulare, die diese Funktion nutzen, haben oft leere Felder oder solche, die mit Standardwerten gefüllt sind. Lesen (SELECT) Lesen und Anzeigen vorhandener Datensätze, ohne die Möglichkeit, diese zu überschreiben. Die einfachsten Formulare, die diese Funktion nutzen, implementieren beispielsweise eine Volltextsuche. Auf Websites, auf denen nur navigiert werden kann, die aber nicht durchsucht werden können, findet der Zugriff auf diese Funktion allein über Hyperlinks statt. Aktualisieren (UPDATE) Das teilweise oder komplette Ändern eines Datensatzes. Gut erstellte Applikationen verwenden hierfür Formulare, die denen für das Anlegen neuer Datensätze entsprechen. Hierbei werden die Formularfelder zuerst mit den Werten des bestehenden Datensatzes gefüllt. Löschen (DELETE, DROP) Vollständiges Entfernen eines oder mehrerer Datensätze. Normalerweise haben Benutzer nicht die Möglichkeit, Datensätze tatsächlich zu löschen. Stattdessen werden »gelöschte« Daten aus rechtlichen und praktischen Gründen nur von der Darstellung ausgenommen. Die wirkliche Löschung der Daten bleibt dem Website-Betreiber überlassen. Bei der Erstellung von Applikationen und Formularen um diese Funktionen herum ist gesunder Menschenverstand gefragt. Viele der folgenden Richtlinien beziehen sich direkt auf das Design von Schnittstellen und Implementierung. Stylesheet-Regeln für Formulare sollten zumindest einige der aufgeführten Punkte berücksichtigen.
Zehn Regeln für effektive Webformulare und -applikationen Drei Grundsätze sind für effektive Webapplikationen wichtiger als alles andere: Sicherheit, Einfachheit und Transparenz. Die folgenden zehn Regeln sind für die Umsetzung dieser Grundsätze unentbehrlich. 1. Fordern Sie nur Informationen an, die Sie wirklich brauchen. Die knappste Ressource des Besuchers ist vermutlich seine Zeit. Nehmen Sie Rücksicht darauf (und verbessern Sie dabei auch gleich die Sicherheit), indem Sie Ihre Formulare so knapp und klar wie möglich gestalten. Weitere Formulare können später aufgerufen und Nutzerdaten bei Bedarf aktualisiert werden. 2. Unterscheiden Sie benötigte Formularfelder von optionalen. Verwenden Sie einen visuellen und einen textbasierten Hinweis, um anzuzeigen, dass ein bestimmtes Formularfeld ausgefüllt werden muss, damit das Formular erfolgreich abgeschickt werden kann. Müssen alle Felder ausgefüllt werden, weisen Sie in den Anweisungen deutlich darauf hin.
Effektive Formulare erstellen
|
245
3. Verwenden Sie klare Anweisungen und Fehlermeldungen. Kommt es in Ihrer Webapplikation zu einem Fehler, weil ein Benutzer sich nicht an die Anweisungen gehalten hat, sollten Sie die Probleme so klar und deutlich wie möglich beschreiben. Das gilt selbst für das einfachste E-Mail-Formular. 4. Erklären Sie im Voraus, welche Folgen das erfolgreiche Abschicken eines Formulars hat. In vielen Fällen, besonders bei Suchfeldern, ist klar, was nach dem erfolgreichen Abschicken eines Formulars passiert. Abgesehen von diesen Fällen, wird der Benutzer vorher wissen wollen, was er davon hat, Ihnen seine Informationen zu überlassen, besonders wenn es sich um wertvolle Informationen handelt. Beantworten Sie seine Fragen so deutlich wie möglich. Aus dem gleichen Grund sollten Sie eine Warnmeldung ausgeben, sofern die Ergebnisse nicht den Erwartungen entsprechen. 5. Seien Sie RESTful: Machen Sie Ihre Applikation nicht von unzuverlässigen Annahmen über den Browser oder bestimmte Sitzungsdaten abhängig. Wie im Anhang beschrieben wird, ist HTTP ein zustandsloses Protokoll. REST (REpresentational State Transfer) beschreibt eine Praxis, diese Zustandslosigkeit in der Architektur HTTPbasierter Dienste zu berücksichtigen. Gehen Sie nicht davon aus, dass der Besucher während der aktuellen Sitzung bereits andere Teile Ihrer Applikation besucht hat, es sei denn, Sie verwenden einen Mechanismus, mit dem die Annahmen im Voraus überprüft werden können (z.B. eine Session-ID). 6. Verwenden Sie Feldtypen, die die feinmotorische Kontrolle Ihrer Besucher nicht überfordern. Verwenden Sie Formularelemente wie select, checkbox und radio für eindeutige Angaben, wie boolesche Werte und Regionenlisten. Wird der Typ checkbox für boolesche Werte benutzt, sollten Sie nur ein Feld dieses Typs verwenden. Gestalten Sie das Formular so, dass alle nicht beliebigen Auswahlmöglichkeiten sichtbar sind. Die einzige Ausnahme davon ist der Fall, in dem die Liste der Wahlmöglichkeiten lang (und vorhersagbar) genug ist, um das Scrollrad oder die »Nach unten«-Taste zu verwenden, um zu einem bestimmten option-Feld zu gelangen. Listen vom Typ select multiple sollten Sie möglichst überhaupt nicht benutzen. 7. Versehen Sie die Formularelemente prinzipiell mit den entsprechenden label-Elementen. Das Element label ist deutlich mehr als nur semantischer Blödsinn. Es ist ein aktiver Teil der Schnittstelle, die mit einem bestimmten Formularelement verbunden ist. Hierfür gibt es das Attribut for. Interagiert ein Benutzer mit einem labelElement, z.B. indem er es anklickt, erhält das Formularelement mit dem in for angegebenen id-Wert den Fokus. 8. Machen Sie Benutzereingaben so lesbar wie möglich. Das heißt: Konzipieren Sie kurze Formulare. Gestalten Sie Texteingaben so, dass die größtmögliche Menge an Eingaben sichtbar ist, und stellen Sie die Textgröße so ein, dass sie mindestens genauso groß wie der Haupttext Ihrer Seite ist, vielleicht sogar größer. Gleichzeitig sollten Sie das Formular möglichst nicht auf mehrere Seiten verteilen. Hierdurch entstehen unnötige Abhängigkeiten innerhalb Ihrer Applikation, die schnell zu verwaisten Sessions führen können.
246
|
Kapitel 13: Saubere und zugängliche Formulare
9. Halten Sie sich streng an feste Werte für die Größe der Formularfelder, Textausrichtung und Spaltenbreiten. Haben Formularelemente die gleiche Größe und Ausrichtung, kann der Benutzer das Formular leichter visuell erfassen und muss nicht so oft die Maus benutzen. Kleine Textfelder sollten bevorzugt werden, weil hierdurch die Lesbarkeit der Eingaben erleichtert wird. 10. Konzentrieren Sie die Benutzeraktivität auf eine der grundsätzlichen »CRUD«-Aktionen: Erstellen, Lesen, Aktualisieren, Löschen. Das Risiko von Benutzerfehlern kann stark verringert werden, wenn Sie jede Applikationsschnittstelle auf bestimmte Kombinationen aus Aktion und Anwendungsbereich beschränken. Das Gleiche gilt für den Bedarf an Bestätigungsdialogen. Neben diesen zehn Regeln gibt es noch einige mehr, deren Befolgung sich lohnt. Die hier genannten treffen aber auf fast alle Anwendungsszenarien zu. Wollen Sie die Benutzbarkeit Ihrer Formulare weiter verbessern, empfehle ich Ihnen die folgenden Bücher: • Web Form Design: Filling in the Blanks, von Luke Wrobleski (Rosenfeld Media) • Don’t Make Me Think: Web Usability – Das intuitive Web, 2. Auflage, von Steve Krug (Mitp)
Einschätzung und Struktur Gute Formular-Implementierungen sind ein Beispiel für Priorität und Einfachheit. Um dieses Ziel zu erreichen, müssen Sie zuerst genau wissen, welche Informationen das Formular vom Benutzer abfragen soll. In manchen Fällen sind die Anforderungen und das dafür nötige Design hinreichend bekannt. In anderen Situationen sind zu viele Einschränkungen im Spiel, wie Firmenkultur, rechtliche Anforderungen, Erwartungen seitens der Besucher oder die Verwendung bzw. die Ablehnung von Ajax. In diesem Fall ist eine sofortige Implementierung nicht möglich. Ich weise auf diese Dinge hin, damit das Design bedachtsam und vorsichtig umgesetzt wird. Formulare sind zu wichtig, als dass unsinnige, blind getroffene Designentscheidungen toleriert werden könnten. Das Absichern von Applikationen ist zwar ein wichtiges Thema, kann aber aus Platzgründen in diesem Buch nicht behandelt werden. Bitte treffen Sie die üblichen Sicherheitsmaßnahmen. Hierzu gehört besonders die Absicherung von Formulareingaben gegen SQL-Injection-Angriffe.
Einschätzung und Struktur
|
247
Anforderungen ermitteln Vor dem Versuch, das visuelle Material wie Layoutraster und Designbestandteile zu erstellen, müssen Sie zuerst Form und Funktion (wenn Sie so wollen) der Formularschnittstelle ermitteln. Diese Aufgaben lassen sich wie folgt unterteilen und ordnen: Einschätzung (Assessment) Finden Sie heraus, welche Vorteile und Anforderungen das Formular sowohl für den Besucher als auch den Betreiber mit sich bringt. Auch wenn es offensichtlich erscheint, gibt es viel zu viele Entwickler, die Formulare nur aus ihrem eigenen Blickwinkel betrachten. Werden die Anforderungen der Besucher einbezogen, kann dies zu vollkommen anderen Designentscheidungen führen. Geltungsbereich (Scope) Webapplikationen und andere Bestandteile, bei denen große Informationsmengen vom Besucher abgefragt werden, machen es nötig, die Aufgaben in kleinere handhabbare Schritte zu unterteilen. Wenn jedes Formular für einen klar definierten Aufgabenbereich zuständig ist, sind Sie dem Ziel eines idealen Formulars schon ziemlich nahe: nicht zu lang, nicht zu kurz – gerade richtig. Auswahl Stellen Sie sich die Frage: Wer hat Vorteile, wenn er die angeforderten Informationen auf eine bestimmte Weise erhält?
Hierfür gibt es drei mögliche Antworten: der Besucher, der Website-Betreiber oder beide. Felder, die nur Vorteile für den Website-Betreiber bringen, sollten entfernt werden, mit einem Anreiz zum Ausfüllen kombiniert werden oder optional sein. Prioritäten In den meisten Fällen kann das Besucherinteresse als einfacher Imperativ mit einem einzelnen Objekt beschrieben werden. »Nachricht schicken«, »Benutzerkonto anlegen« oder »Gutscheincode erhalten« sind alle Beispiele für häufige Ziele der Besucher. Manchmal enthält das Formular Felder, die sich nicht eindeutig auf das Ziel beziehen. Dann sollten Sie dem Besucher erklären, was er davon hat, das Feld auszufüllen, und es eher am Ende des Formulars platzieren. Datentypen Geben Sie an, welche Art von Daten in die einzelnen Formularfelder eingegeben werden müssen, und verwenden Sie das entsprechende HTML-Element. Tabelle 13-1 soll Ihnen bei der Entscheidung helfen.
248
|
Kapitel 13: Saubere und zugängliche Formulare
Tabelle 13-1: Formularelemente nach Datentyp Datentyp
Element
Weitere Erwägungen
Beliebiger Text oder Zahlen (kurz)
input type="text"
Am besten geeignet für Wörter, kurze Sätze und Zeichenketten (z.B. URIs)
Beliebiger Text (lang)
textarea
Am besten geeignet für Sätze, Absätze und beliebig lange Listen, mit durch Zeilenumbrüche getrennten Daten wie URIs und Auftragsnummern. Ampersand-Zeichen (&) müssen als & kodiert werden, bevor der Inhalt von textareaFeldern zum Aktualisieren von Inhalten verwendet werden kann.
Dargestellt wie input type="text". Daten werden als Klartext an den Server übertragen und müssen ggf. über einen anderen Mechanismus verschlüsselt werden. checked="checked" für aktive Inhalte nötig, wenn XHTML verwendet wird; Opt-Out-Wahlmöglichkeiten sollten prinzipiell durch ein nicht aktiviertes Element dargestellt werden.
Zwei oder drei Auswahlmöglichkeiten
input type="radio"
Enthalten in einem einzelnen fieldset; checked="checked" ist für aktive Inhalte nötig, wenn XHTML verwendet wird; Optionen, die sich gegenseitig ausschließen, müssen den gleichen Wert für name haben. selected="selected" für aktive Inhalte nötig, wenn XHTML verwendet wird; dem Benutzer unbekannte Werte sollten sofort und ohne Scrollen lesbar sein.
Auswahl einzelner Optionen aus einer Liste (nicht vom Benutzer veränderbar)
select
Auswahl mehrerer Optionen aus einer Liste (nicht vom Benutzer veränderbar)
select multipleinput type="checkbox"
Am besten in einem einzelnen fieldset enthalten, das von sorgfältig gewählten Werten für width und overflow profitiert; siehe auch »Zusätzliche Optionen« und »Auswahl einzelner Optionen aus einer Liste«.
Dateien hochladen
input type="file"
Siehe im Abschnitt »Die POST-Methode und das Hochladen von Dateien« auf Seite 256.
ASCII-kodierte Sitzungs- oder benut- input type="hidden" zerspezifische Daten
Alternative zur Verwendung von Cookies zur Sitzungsverwaltung. Die Daten verfallen nicht komplett, bis das Browserfenster geschlossen wird und der Seitencache geleert wurde.
Einschätzung und Struktur
|
249
Tabelle 13-1: Formularelemente nach Datentyp (Fortsetzung) Datentyp
Element
Weitere Erwägungen
Buttons zur Interaktion mit der Benutzerschnittstelle
input type="button", button
Am besten über ein clientseitiges Script eingefügt. Da diese Buttons nur Events auslösen können, profitieren sie von der Zuweisung eines speziell für Buttons reservierten class-Wertes; anhand der CSS-background-*-Eigenschaften kann anstelle des Buttons auch ein Bild verwendet werden; die Verwendung des Elements button bietet feinere Kontrolle über die Darstellung als z.B. input="button", wird aber nicht überall verlässlich unterstützt.
»Abschicken«-Button als Text
input type="submit"
Profitiert von der Zuweisung eines class-Werts, der allein für die Darstellung von Buttons reserviert ist.
»Abschicken«-Button als Bild
input type="image"
Wie bei normalen Bildern sollte auch für dieses Element ein alt-Wert angegeben werden; wird dieses Element in einem grafischen Browser aktiviert, werden die beim onlick-Event empfangenen x- und y-Koordinaten des Cursors kodiert. Skripte, die diese Werte verwenden, sollten ein Standardverhalten besitzen, um Benutzern von Hilfstechnologien oder reinen Textbrowsern die Benutzung zu ermöglichen. Alternativ dazu können Sie den deutlich zugänglicheren Ansatz wählen und dieses Feature komplett vermeiden.
Die in Tabelle 13-1 gezeigten Richtlinien sind nicht immer bindend. So könnte der Mechanismus für eine Bewertung auf einer bestimmten Skala (z.B. von 1 bis 10) entweder mit input-tpye="radio"-Elementen oder auch über eine select-Liste realisiert werden.
Markup und Struktur Sobald die Funktion und Reihenfolge Ihrer Formularfelder feststeht, können Sie sich mit dem Markup beschäftigen. Neben den in Tabelle 13-1 beschriebenen Elementen für Formularfelder kommen hierbei die folgenden vier Elemente zum Einsatz: fieldset
Das Element fieldset ist nur in Formularen gültig. Der Zweck lässt sich am Namen ablesen: Es schafft einen Kontext für ähnliche, aufeinander folgende Elemente. Weitere Details können über den Inhalt des Elements legend hinzugefügt werden. Typische Kandidaten für fieldset sind beispielsweise Gruppen von Radiobuttons, Ankreuzfeldern, Feldern für Datums- und Uhrzeitangaben oder Textfelder, in die der Benutzer bestimmte Angaben zu einem Thema machen soll.
250
|
Kapitel 13: Saubere und zugängliche Formulare
legend
Das Element legend validiert nur, wenn es innerhalb eines fieldset-Elements steht. Auf die gleiche Weise, wie label sich auf ein bestimmtes Formularelement bezieht, muss legend einen klaren Bezug zu den entsprechenden Paaren aus label und Formularelement besitzen. Innerhalb eines fieldsets ist jeweils nur ein legend-Element erlaubt. ul und li
Das meiste Formular-Markup tritt paarweise auf. label bezieht sich auf ein bestimmtes Formularelement, während legend für eine Gruppe aus Paaren von label und einem Element zuständig ist. Im ersten Fall muss man das Paar oft mit einem gemeinsamen Elternelement umgeben. Da Formulare beliebige Blockelemente enthalten können, besteht die beste Wahl in einem Listeneintrag (li), der seinerseits in einem ul-Element enthalten sein muss. Der zweite Fall ist etwas widersprüchlich. Einige Implementierer bevorzugen es, die Formularelemente mit einem Element zu umgeben, das sie von den übrigen Teilen des Inhalts unterscheidet. Andere setzen eher darauf, diesen Unterschied implizit zu vermitteln. Hierbei sollte man bedenken, dass Bildschirmlesegeräte und andere Hilfstechnologien Listen mit zusätzlichen Funktionen versehen, wodurch die Benutzer möglicherweise mehr Zeit brauchen, um das Formular zu erfassen. Als direktes Ergebnis dieser Überlegungen könnte der Markup-Code für ein einfaches Anmeldeformular ungefähr so aussehen: <span>Anmelden
Benutzername:
Passwort:
In einem komplizierteren Formular, das beispielsweise eine Reihe von Radiobuttons (input type="radio") enthält, werden diese Formularelemente und das dazugehörige label-Element mit einem eigenen fieldset-Element umgeben. Dieses wird dann im Quellcode an der Stelle eingefügt, an der normalerweise ein schlichtes input type="text"oder select-Element stehen würde, wie in Abbildung 13-1 gezeigt. Außerdem erhält das fieldset sein eigenes label-Element, wie gleich erklärt wird. Online-Beispiele für die zweite Methode finden Sie außerdem auf der Website zu diesem Buch (http://www.htmlcssgoodparts.net) und im Opera Web Standards Curriculum zum Thema fortgeschrittene Formulargestaltung unter http://dev.opera.com/articles/view/34-styling-forms/. Einschätzung und Struktur
|
251
Abbildung 13-1: Die Darstellung typischer Paare aus Beschriftung (»label«) und Formularfeld; Vergleich zu Anwendungsbeispielen für das Element »fieldset«
Im vorigen Beispiel gibt es ein paar Details, die beim einfachen Lesen nicht gleich ins Auge springen: Die Attribute length und maxlength wurden nicht benutzt. Auf den meisten Plattformen kann das Attribut length durch die CSS-Eigenschaft width ersetzt werden. Das Attribut maxlength hat als Sicherheitsmechanismus auch nur beschränkten Nutzen. Andererseits schränkt die Verwendung dieser Attribute die Usability nicht ein, sondern kann sie in manchen Fällen sogar verbessern. Im legend-Element des Formulars befindet sich ein anonymes span-Element. Das legend-Element ist äußerst gestaltungsresistent, span dagegen nicht. Der Quellcode für das Formular ist sorgfältig formatiert, was auf den ersten Blick mit dem Verhalten vieler Inline- und Inline-Block-Elemente nicht vereinbar zu sein scheint. Andererseits ist die Lesbarkeit des Quellcodes gerade bei Formularen wichtig. Zudem wird die Darstellungsrolle der verschiedenen Elemente im Stylesheet sowieso als display: block definiert. Der Submit-Button ist nicht in der Liste für das Formular-Grundgerüst enthalten. Außerdem besitzt er zwei class-Werte, die direkt auf seine Funktion verweisen. Die Funktion dieses Elements und die ausdrückliche Definition seines value-Attributs machen die Verwendung von li und label in diesem Fall überflüssig. Trotzdem werden spezielle Stildefinitionen gebraucht, um Elemente wie dieses an den gemeinsamen Layout-Achsen auszurichten. Außerdem zwingt uns die mangelnde Unterstützung von Attributselektoren in Internet Explorer zu einem ziemlich groben Vorgehen, um ein ideales Bildschirmlayout zu erzeugen. Dem Formular selbst wurde ein id-Wert zugewiesen. Das für das Formular definierte id-Attribut ist wahrscheinlich nicht nötig. Wenn Sie allerdings Ajax einsetzen oder mehr als ein Formular auf der gleichen Seite verwen-
252
|
Kapitel 13: Saubere und zugängliche Formulare
den, kann die Verwendung von id die Entwicklungszeit verkürzen und überflüssigen Code vermeiden helfen. In vielen Arbeitsumgebungen kann es außerdem sinnvoll sein, auch die Listeneinträge (li) und den Abschicken-Button mit eigenen id-Werten zu versehen. Dies gilt besonders dann, wenn für die clientseitige Fehlerbehandlung des Formulars komplexe Stilregeln nötig sind. Wird im Formular zwischen notwendigen und optionalen Feldern unterschieden, sollten die einzelnen Listeneinträge, die als Container dienen, ebenfalls mit den entsprechenden class-Attributen und Werten versehen werden. Wenn Sie die Struktur und das Markup für ein Formular festlegen, sollten Sie die folgenden drei Ziele nicht aus dem Auge verlieren: • Stellen Sie sicher, dass jedes Paar aus label und Formularfeld genügend Referenzpunkte zur Kaskade, der DOM-API und den Erfordernissen besitzt, die für die Kompatibilität mit Hilfstechnologien nötig sind. • »Überladen« Sie das Formular, um Darstellungsfehlern im Internet Explorer, speziell in Version 6, vorzubeugen. • Machen Sie es den Applikationsentwicklern so einfach wie möglich, einheitliche, modulare Ausgaben zu erzeugen. Das letzte Ziel ist besonders schwer zu erreichen. Der Aufwand kann sich trotzdem lohnen, wenn es um die Erstellung einer kompletten Webapplikation geht. Vereinheitlichter und modularer Markup-Code ist deutlich leichter mit objektorientierten Skriptprogrammen zu verarbeiten als konzeptloser Elementesalat. Bevor wir uns mit den Darstellungsaspekten von Formularen beschäftigen, gibt es noch ein paar Details – einige sind nicht so offensichtlich, andere wichtig –, die direkt mit dem Markup und Verhalten von Formularen zu tun haben.
Grundsätzliche Struktur, Darstellung und Verhalten von Formularen Wenn Sie eher von einem designerischen oder redaktionellen Hintergrund kommen, brennt Ihnen vermutlich eine Frage unter den Nägeln: Was passiert eigentlich nach dem Abschicken mit den Formulardaten, und wie erhält der Benutzer die nötigen Rückmeldungen? (Dies war übrigens meine erste Frage, als ich 1999 an meiner ersten großen Webapplikation arbeitete.) Zudem gibt es beim Markup und Verhalten von Formularen ein paar Eigenheiten, die vielleicht erfahrenen Entwicklern, aber nicht allen Lesern bekannt sind.
Grundsätzliche Struktur, Darstellung und Verhalten von Formularen
|
253
Vom Formular ausgelöste GET-Requests Wenn Sie ein wenig Zeit mit dem Markup von Formularen verbracht haben, ist Ihnen vermutlich aufgefallen, dass jedes form-Element ein action-Attribut und jedes enthaltene Formularelement (Textfeld, Radiobutton usw.) ein name-Attribut besitzt. Das name-Attribut wird mit dem Wert des Formularfelds bzw. dem Inhalt des value-Attributs gekoppelt und vom Browser wie folgt kodiert: inhalt=Hallo+Welt%21
Dies ist die literale Zeichenkette, wie sie an den Webserver übertragen wird. In normaler Sprache steht hier: »Hallo Welt!« Für das Versenden dieser Daten an den Webserver stehen zwei verlässliche Methoden zur Verfügung: GET und POST. Bei der GET-Methode werden die Formulardaten an den URL angehängt, der im action-Attribut des Formulars angegeben ist, zum Beispiel: http://example.com/zeigmeinzeug.php?inhalt=Hallo+Welt%21
Beachten Sie das literale Fragezeichen (?), das den Namen der angeforderten Ressource (hier ein Skript namens zeigmeinzeug.php im Wurzelverzeichnis des Webservers und die Formulardaten voneinander trennt. Weitere Paare aus Name und Wert werden durch literale Ampersand-Zeichen (&) voneinander getrennt: http://example.com/zeigmeinzeug.php?inhalt=Hallo+Welt%21&farbe=rot&groesse=xx-large
Obwohl sich die resultierenden URIs im Prinzip nicht von URIs ohne Formulardaten unterscheiden, hat das Abschicken der Daten per Formular einen Vorteil: Die Kodierung der Daten für die Übertragung muss nicht von Hand vorgenommen werden, sondern wird vom Browser automatisch durchgeführt. Der Benutzer muss sich also nicht die halbe ASCII-Tabelle merken, um daraus die entsprechenden Werte für die Kodierung selbst zu finden. Da Ampersand-Zeichen eine besondere Rolle spielen, müssen sie vor ihrer Verwendung in Werten für href- und src-Attributen selbst kodiert werden, wie hier gezeigt: href="http://example.com/zeigmeinzeug.php?inhalt=Hallo+Welt%21&farbe=rot& groesse=xx-large"
Diese seltsame Notwendigkeit hat in der englischsprachigen Welt zu dem Begriff »damnpersand« (»Verdammtpersand«) geführt. Das Wort hat seinen Ursprung in der Verwendung nicht geschützter Ampersand-Zeichen in Benutzereingaben und den vergleichsweise miserablen Ausgaben von Dritthersteller-Plugins. Dabei stehen die Ampersand-Zeichen oft als Einziges zwischen sorgfältig geschriebenem Markup und der erfolgreichen Validierung eines Dokuments. Wurde das Skript, das die kodierten Daten entgegennimmt, als standardmäßig zurückgegebene Ressource eingerichtet (in Apache mit der Direktive DirectoryIndex) und ist der entsprechende Skriptinterpreter auf dem Webserver richtig konfiguriert, kann der Name des Skripts auch komplett weggelassen werden:
Beachten Sie, dass der Internet Explorer die Länge von URIs auf 2.083 Zeichen beschränkt, von denen höchstens 2.048 auf die Kombination aus Pfadangabe und kodierten Formulardaten entfallen dürfen. Überschreitet ein URI dieses Limit, erhält der Benutzer von IE eine Fehlermeldung.
URL-Kodierung im Detail: ASCII-Entities In den vorigen Beispielen ist Ihnen vermutlich aufgefallen, dass anstelle des Ausrufungszeichens (!), das in RFC 3986 als »reserviertes Zeichen« vermerkt ist, der Code %21 verwendet wurde. Eine vollständige Liste dieser Zeichen sehen Sie in Tabelle 13-2. Tabelle 13-2: Reservierte Zeichen in URIs und die entsprechenden ASCII-Kodierungen Zeichen
Langer Name
Kodierung
Dezimalwert
Leerzeichen
%20
32
Ausrufungszeichen
%21
33
#
Doppelkreuz
%23
35
%
Prozentzeichen
%25
37
&
Ampersand-Zeichen
%26
38
$
Dollar-Zeichen
%24
36
’
Apostroph
%27
39
(
runde Klammer links
%28
40
)
!
runde Klammer rechts
%29
41
*
Asterisk
%2A
42
+
Pluszeichen
%2B
43
,
Komma
%2C
44
/
Schrägstrich
%2F
47
:
Doppelpunkt
%3A
58
;
Semikolon
%3B
59
=
Gleichheitszeichen
%3D
61
?
Fragezeichen
%3F
63
@
At-Zeichen
%40
64
[
eckige Klammer links
%5B
91
]
eckige Klammer rechts
%5D
93
Literale Leerzeichen werden in URI-Pfaden immer als %20 kodiert; in URL-kodierten Pfaden wie den oben gezeigten wird stattdessen das Pluszeichen verwendet. Das führt zu einigen unglücklichen, aber nötigen Verwirrungen. Will jemand beispielsweise die Zeichenkette 2 + 2 = 4 in ein Formular eingeben, würden die Daten vor dem Abschicken als 2+%2B+2+%3D+4 kodiert.
Grundsätzliche Struktur, Darstellung und Verhalten von Formularen
|
255
Einige der in Tabelle 13-2 beschriebenen Zeichen werden in URI-Pfaden literal verwendet, aber kodiert, wenn sie als Teil von Formulardaten verschickt werden. Für die URL-Kodierung der Benutzereingaben ist kein Zutun der Entwickler notwendig. Allerdings enthalten die meisten im Web verwendeten Skriptsprachen die nötigen Funktionen, um Benutzereingaben in das URL-kodierte Format und wieder zurück zu verwandeln.
Die POST-Methode und das Hochladen von Dateien Wird die Request-Methode für ein Formular als POST angegeben, werden die kodierten Formulardaten nicht als Teil des URI, sondern im Request-Body übertragen. Neben der Möglichkeit, die Grenze von 2.083 Zeichen in URIs zu umgehen, lassen sich POST-Requests auch schwerer vom Benutzer manipulieren. Aus diesen Gründen ist für das Hochladen von Dateien per Formular die POST-Methode nötig. Der Standardwert des Attributs enctype für das form-Element lautet application/x-wwwform-urlencoded. Formulare für das Hochladen von Dateien müssen stattdessen den Wert multipart/form-data verwenden. Gestalter haben leider das Problem, dass das Element input type="file" nicht konsistent mit CSS zusammenarbeitet. Der wichtigste Punkt ist hierbei, dass mit diesem Element zwei Objekte im Browserfenster dargestellt werden: ein Textfeld und ein Button. Aus diesem Grund sind die einzigen CSS-Eigenschaften, mit denen sich einigermaßen vorhersagbare Ergebnisse erzielen lassen, color, background-color und die Eigenschaften, die das Layoutverhalten beeinflussen (wie margin-* und position). Bei der visuellen Gestaltung der Formularelemente für das Hochladen von Dateien sollten Sie daher möglichst konservativ vorgehen, indem Sie davon ausgehen, dass sich die Standarddarstellung nicht ändern lässt.
Die Größe und das Aussehen einzelner Formularelemente anpassen Formularelemente verhalten sich etwas anders als die übrigen HTML-Elemente. • Die Werte von Schrift- und Texteigenschaften werden in Formularelementen nicht über die Kaskade vererbt. Stattdessen müssen die Definitionen über Selektoren direkt für die Formularelemente vorgenommen werden. • Im Gegensatz zu anderen Elementen werden die Formularelemente gemäß dem »Quirks-Modus« dargestellt. Das heißt, alle Box-Eigenschaften (außer margin-*) liegen innerhalb der angegebenen Werte für height und width (falls vorhanden). • Formularelemente (außer textarea) tendieren dazu, Werte für line-height zu ignorieren.
256
|
Kapitel 13: Saubere und zugängliche Formulare
• Abgesehen von input type="file" und dem Inhalt von select-Elementen können allen Formularelementen transparente Hintergründe und eigene Hintergrundbilder zugewiesen werden. • Wurde für ein Eingabefeld vom Typ input type="text" ein Wert für das Attribut length definiert, kann dieser sich auf die berechnete Breite des Textfeldes auswirken. Am besten lässt sich die Darstellung steuern, wenn Sie das Attribut length vermeiden und stattdessen im Stylesheet einen Wert für die Eigenschaft width festlegen, wie in den vorigen Quellcodebeispielen gezeigt wurde. • Die scheinbare Größe von Radiobuttons und Ankreuzfeldern wird nicht per width oder height gesteuert, sondern mit font-size. In aktuellen Browsern lässt sich das Boxmodell-Problem recht einfach lösen. Sie alle unterstützen bereits die CSS3-Eigenschaft box-sizing (in Firefox und Safari momentan allerdings nur als browserspezifische Eigenschaften -webkit-box-sizing bzw. -moz-boxsizing). Folgende Werte sind möglich: content-box
Sorgt dafür, dass ein Element nach dem Strict-Boxmodell dargestellt wird: Die Werte von width und height beziehen sich allein auf den Inhaltsbereich. Innenabstände und Rahmen werden nicht dazugerechnet. Sollen Ihre Formularelemente nach dem standardkonformen Boxmodell dargestellt werden, sollten Sie den Wert content-box verwenden. border-box
Elemente mit diesem Wert werden nach dem Boxmodell im »Quirks«-Modus dargestellt. Innenabstände und Rahmen sind Teil der berechneten Breite bzw. Höhe. Außerdem gibt es beim Element select noch ein paar Dinge zu beachten: • Hat width für ein select-Element den Wert auto, so wird unter normalen Umständen seine Breite an das breiteste enthaltene option-Element angepasst. • Ist die definierte Breite eines select-Elements schmaler als das breiteste enthaltene option-Element, wird die Breite des »Aufklappfensters« in den meisten Browsern beim Aktivieren trotzdem an das breiteste option-Element angepasst. • In Safari ist eine Zuweisung der Eigenschaften font-size für select-Elemente möglich. Alle anderen Darstellungsaspekte werden vom Betriebssystem bestimmt und können nicht verändert werden. • option-Elemente können anhand von optgroup-Elementen zusammengefasst werden, wie in Abbildung 13-2 gezeigt. Besonders lange option-Listen sollten optgroup verwenden, um verschiedene Bereiche voneinander zu trennen, anstatt leere option-Elemente für diesen Zweck zu missbrauchen. • Wurde für eine Option kein Wert für das Attribut value angegeben, so wird stattdessen der dem Benutzer angezeigte Inhalt (z.B. Inhalt) kodiert und an den Server geschickt.
Grundsätzliche Struktur, Darstellung und Verhalten von Formularen
|
257
Abbildung 13-2: Darstellung eines »select«-Elements mit »optgroup«-Elementen am Beispiel von IE, Firefox und Safari
Auf der Website zu diesem Buch finden Sie unter anderem eine Testsuite, die das Verhalten detaillierter beleuchtet.
Prototyping und Layout Sind die Funktionen eines Formulars einmal festgelegt und implementiert, besteht der nächste Schritt darin, das Layout festzulegen, damit das Formular als Prototyp getestet werden kann.
Das Einmaleins des Prototyping Der Prototyp einer Webapplikation hat den gleichen Zweck wie ähnliche nicht-virtuelle Produkte aus dem Labor eines Ingenieurs. Es geht darum, sicherzustellen, dass das Produkt so funktioniert, wie die Designer sich das gedacht haben. Der größte Aufwand beim Prototyping einer Applikation wird getrieben, um dafür zu sorgen, dass der ausführbare Code keine Programmierfehler enthält oder andere Probleme macht. Darüber hinaus ist das Prototyping eine gute Gelegenheit, um die Verwendbarkeit der Benutzerschnittstelle zu testen. Beim Testen von Prototypen betreffen einige Fragen den Benutzer direkt: • Sind die Formulare der Applikation für die Zielgruppe einfach genug zu benutzen? • Führt das geplante Design der Formulare zu irgendwelchen typischen Benutzerfehlern? • Werden bestimmte Felder ständig übergangen, oder wird außergewöhnlich viel Zeit für das Ausfüllen verwendet? • Gibt es Teile in der visuellen Gestaltung und im Design der Applikation, bei denen der Arbeitsaufwand im Vergleich zu den dadurch erlangten Vorteilen unverhältnismäßig hoch ist?
258
|
Kapitel 13: Saubere und zugängliche Formulare
Sämtliche Informationen, die beim Prototyping gewonnen werden, können Einfluss auf die Usability haben. Wir konzentrieren uns hier jedoch auf Markup und CSS. Folgende Dinge sollten möglichst vermieden werden: • Die Beziehung zwischen den Formularfeldern und den entsprechenden label-Elementen ist unklar oder unangemessen. • Die Reihenfolge der Felder entspricht nicht den Prioritäten der Benutzer. • Anweisungen und Warnungen sind schlecht angeordnet, schwer verständlich oder enthalten nicht die nötigen Details. • Bestimmte Designanforderungen sorgen für schwerwiegende Darstellungsfehler. Damit ein Formular als effektiver Prototyp dienen kann, muss er die folgenden Darstellungsanforderungen erfüllen: • Das Layout des Formulars sollte den Konventionen des Layougrids und der einzelnen Bausteine folgen. • Visuelle Akzente sind nicht nötig, trotzdem sollten die Schrift- und die Hintergrundfarbe einen ausreichenden Kontrast aufweisen. • Anweisungen und Hinweise auf erforderliche Daten sollten so dargestellt werden wie später auf der fertigen Website. • Soll in der fertigen Webapplikation Ajax verwendet werden, sollte es auch in den Prototypen schon implementiert sein, zumindest an den wichtigsten Stellen. Es ist die Aufgabe des Gestalters, sicherzustellen, dass die Ausgaben von Ajax die hier genannten Anforderungen erfüllen. Im folgenden Abschnitt finden Sie einige Design-Templates für das Layout von Formularen.
Design-Templates, Grundstile und Formular-Layout Standardmäßig werden Formularelemente als Inline-Block-Elemente dargestellt, die Beschriftungen (label) dagegen als Inline-Elemente. Da diese Elemente oftmals als Float (float: left/float: right) definiert werden und das Vorhandensein von WhitespaceZeichen Auswirkungen auf die Darstellung von Inline-Block-Elementen haben kann, ist es in der Regel einfacher, die Darstellungsrolle per display: block anzupassen. Sobald andere Elemente ins Spiel kommen, könnten die folgenden konservativen Grundstile zum Zurücksetzen der Darstellung verwendet werden: form, form ul, form li, fieldset, textarea { label, input, select, textarea, form li span { form ul, form li { form li { fieldset {
Die empfohlenen Layout-Templates für Formulare sehen Sie unten, in der Reihenfolge ihrer Attraktivität geordnet. Die Stil-Beispiele beziehen sich jeweils auf den im Abschnitt »Einschätzung und Struktur« auf Seite 247 gezeigten Markup-Code. Die Angaben für width in den folgenden Beispielen dienen nur der Demonstration. Beachten Sie, dass die margin-Werte für die Formularfelder zu den width-Werten der entsprechenden label-Elemente passen sollten.
Wie das vorige Beispiel, allerdings werden Beschriftungen und Formularfelder zusätzlich an einer gemeinsamen rechten Achse ausgerichtet label, form li span { text-align: right; }
Beschriftungen rechts neben den Formularfeldern Sie können die gleichen Stile wie für die Darstellung der Beschriftungen links der Formularfelder verwenden. Allerdings müssen die Werte für float und margin hierfür umgekehrt werden. Mehrspaltige Anordnung von Paaren aus label- und Formularelementen Trennen Sie die label/Element-Gruppen in die benötigte Anzahl von Listen auf, und verwenden Sie die bereits gezeigten Layout-Templates, um die Darstellung für die einzelnen Spalten zu steuern. Die besten Ergebnisse erzielen Sie, wenn Sie die Grundstile um die folgenden Regeln ergänzen: form { height: 1%; overflow: auto; } form ul { float: left; width: 45%; margin-right: 5%; }
Wenn Sie versuchen, diese Beispiele auf einen funktionierenden Prototyp anzuwenden, werden Sie merken, dass die Ergebnisse nicht exakt auf das Layoutraster passen. Dies gilt besonders für Radiobuttons und Ankreuzfelder. Die Darstellung dieser Elemente wird meist vom verwendeten Betriebssystem übernommen. Die damit verbundenen Probleme werden in Kapitel 14 besprochen. Beim ersten Stylesheet-Entwurf scheinen die Dinge nie hundertprozentig nach Plan zu laufen. Das hat oft mit der Position der Formulare in der Kaskade zu tun. Um Probleme zu vermeiden, sollten Formulare möglichst weit oben in der Hierarchie der Elemente definiert
260
|
Kapitel 13: Saubere und zugängliche Formulare
werden. Um die Darstellung der Formularelemente anzupassen, werden Sie ihre Werte für width und height individuell anpassen müssen. Wollen Sie em-basierte Mikrogrids (siehe im Abschnitt »Layouttypen und Hilfslinien-Raster« auf Seite 108) verwenden, müssen Sie außerdem für jedes Formular einen eigenen Wert für font-size festlegen. In der Praxis werden Sie auf dem Weg zum fertigen Formular-Layout immer wieder testen und die entsprechenden Anpassungen vornehmen müssen. Sie werden eine Vielzahl von class-Werten definieren, eine Menge von Box-Eigenschaften verwenden und viele Feinabstimmungen für einzelne Formularelemente vornehmen müssen. Besonders komplexe Formular-Layouts erfordern möglicherweise feinste Änderungen an einzelnen Feldern, zum Beispiel: form#supportTicket li#schwere input { padding-top: .333em; }
In diesem Fall lässt sich die Funktion des dazugehörigen Formularfelds an seinem Selektor ablesen. Es handelt sich um ein Formular zum Anfordern eines Support-Tickets. Es enthält mehrere Kontrollelemente, mit denen der Besucher auswählen kann, wie schwerwiegend (schwere) sein Problem ist. Dies wird sehr wahrscheinlich über eine Reihe von Radiobuttons (ggf. auch mit select-Elementen) realisiert. Der Versuch, jedes mögliche Layout-Szenario zu beschreiben, würde zu einem sehr dicken Buch führen. Zusätzliche Testsuiten, Regel-Bibliotheken und Tipps finden Sie auf der Website zu diesem Buch.
Einheitliche Gestaltung von gleichen Formularelementen Einige Layout-Probleme bei Formularen tauchen sehr häufig auf: • input type="text", textarea und select-Elemente müssen unterschiedlich lange Eingaben entgegennehmen können, z.B. Straßen- und Ortsnamen. • input type="submit" am Ende von Formularen • Regeln wie input { border: 1px solid rgb(0,0,0); ... }, die später für Ankreuzfelder (input type="checkbox") und Radiobuttons (input type="radio") wieder zurückgesetzt werden müssen • Nicht oder missverständlich beschriftete Kontrollelemente, wie Datumsangaben, Bewertungsskalen und Telefonnummern werden in ihre Einzelteile aufgeteilt (z.B: Vorwahl, Telefonnummer oder Tag, Monat, Jahr). • Zurücksetzen der Außenabstände für Radiobuttons und Ankreuzfelder Die mangelnde Unterstützung von Attribut-, Nachfahren- und Kindselektoren im Internet Explorer ist einer der »Schlechten Seiten«. Die Folgen sind im Bezug auf die Erstellung von Stylesheet-Regeln für Formulare besonders ungünstig.
Prototyping und Layout
|
261
Den gerade erwähnten Problemen begegnet man am besten durch die Verwendung von Klassennamen, die sich an der Länge der erwarteten Eingabedaten für bestimmte Felder orientiert. Für die Breite von Text- und select-Feldern bieten sich folgende Klassennamen an: – .kurz – .mittel – .lang – .klein – .gross Die Ausmaße von select-/option-Elementen sollten gut überlegt sein. Zu schmale Felder verbergen möglicherweise den Inhalt von Auswahllisten, was die Benutzung in manchen Fällen unmöglich machen kann. Für Submit-Buttons und grafische Buttons können die folgenden Klassennamen helfen: – .zuruecksetzenButton – .abschickenButton Um zwischen Elementen zur Texteingabe und input-Elementen zu unterscheiden, die z.B. mit dem Mauszeiger aktiviert werden, können die folgenden class-Werte benutzt werden: – .textfeld – .button – .bool_wert – .auswahlliste Nicht sichtbare Formularelemente Das Verstecken oder Weglassen von label-Elementen ist eine schlechte Idee. Sollen die Beschriftungen für die Benutzer von bildschirmbasierten Medien nicht sichtbar sein, können Sie sie mit einer Kombination aus position: absolute und einem negativen Wert für left aus dem sichtbaren Bereich bewegen. Gelegentlich wird der Benutzer über ein legend-Element gebeten, mehrere Wahlmöglichkeiten selbst in eine Reihe von Textfeldern einzugeben (z.B. die drei Lieblingsbücher, -filme etc.). In diesem Fall ist es empfehlenswert, im Inhalt der label-Elemente eine entsprechende Nummerierung anzugeben (1., 2. 3., …), unabhängig davon, ob die Beschriftung tatsächlich dargestellt wird oder nicht. In vielen der beschriebenen Fälle taucht das Element fieldset auf. Verwenden Sie es im Markup so wie in Ihren Stylesheets mit Bedacht.
Erforderliche Formularfelder und Eingabeformate In manchen Fällen ist das Ausfüllen bestimmter Formularfelder auf jeden Fall erforderlich. Such- und Anmeldeformulare sind hier offensichtliche Beispiele. 262
|
Kapitel 13: Saubere und zugängliche Formulare
In den meisten Fällen ist es nur dem Entwickler klar, dass bestimmte Felder vor dem Abschicken des Formulars ausgefüllt werden müssen. Das gilt selbst für so offensichtliche Fälle wie die Eingabe von E-Mail-Adressen. In diesen Fällen müssen die entsprechenden Formularfelder als »erforderlich« gekennzeichnet werden. Natürlich darf auch die Überprüfung der notwendigen Eingaben nicht fehlen. In anderen Fällen müssen die vom Benutzer eingegebenen Daten ein bestimmtes Format haben, z.B. Telefonnummern und ganz besonders E-Mail-Adressen. Hierfür werden die eingegebenen Zeichen oftmals mit speziellen Funktionen für Zeichenketten, aber auch mit regulären Ausdrücken überprüft. Gestalter haben hierbei eigene Aufgaben: Die erforderlichen Felder und Eingabeformate müssen entsprechend gekennzeichnet und erklärt werden. Das Gleiche gilt für Fehlermeldungen, die prinzipiell eine kurze Begründung enthalten sollen (z.B. »Postleitzahlen bitte immer als fünfstellige Zahlenfolge angeben«).
Erforderliche Felder hervorheben Nehmen wir zum Beispiel eines der in Abbildung 13-1 beschriebenen Paare aus label und Formularelement. Hier bestimmen fieldset-, label- und die eigentlichen Formularelemente die Größe des umgebenden li-Elements. Angenommen, Sie verwenden für die Darstellung des Formulars die in diesem Abschnitt gezeigten Stildefinitionen, dann könnten Sie das Stylesheet zum Hervorheben der erforderlichen Felder um die folgenden Regeln erweitern: .erforderlich { position: relative; padding-right: 3.3em; } .erforderlich label span.warnung { position: absolute; right: 0; width: auto; color: rgb(192,0,0); }
Die oben gezeigten Regeln passen beispielsweise auf das folgende Markup: ...
Postleitzahl<span > [erforderlich]:
...
Als Resultat wird rechts neben dem Paar aus label und Formularelement die Zeichenkette »[erforderlich]« angezeigt. Die Farbe entspricht einem HSB-Wert von 0 /100%/63% (Rotbraun). Die Stilregeln für den Hinweistext sind so definiert, dass sie für alle erforderlichen Felder verwendet werden können. Gleichzeitig wird das »Überlaufen« zumindest teilweise verhindert. Voraussetzung hierfür ist, dass die Breite von li und fieldset als width: auto berechnet wird. Der Nachteil dieser Technik besteht darin, dass sie mit bestimmten Werkzeugen zur Bildvergrößerung nicht immer funktioniert. Dies gilt besonders für alle Windows-Versionen. Um dieses Problem zu berücksichtigen, sollten die »[erforderlich]«-Markierungen stattdessen unter- oder oberhalb des benötigten Feldes und bündig mit dessen linkem
Erforderliche Formularfelder und Eingabeformate
|
263
Rand angezeigt werden. Das Ergebnis ist ein Layoutraster mit deutlich weniger vertikalem Leerraum, als es auf den ersten Blick scheint. Oftmals können erforderliche Felder mit einem deutlich »natürlicheren« Fluss der Elemente markiert werden. Ist das einmal nicht möglich, wissen Sie zumindest, dass der Positionierungskontext (siehe im Abschnitt »CSS-Eigenschaften für die Positionierung« auf Seite 99) für Sie da ist, wenn Sie ihn brauchen.
Eingabefehler aufspüren und identifizieren Der nächste Schritt besteht darin, die Benutzereingaben auf mögliche Fehler zu überprüfen. Hierfür ist eine Kombination aus client- und serverseitiger Logik am besten geeignet. Die Arbeitsschritte könnten wie folgt aussehen: 1. Auf der Clientseite werden die Eingaben mit den passenden Kombinationen aus .length, indexOf(), parseInt() und RegExp -Objekten überprüft. 2. Ist JavaScript aktiviert, werden fehlerhafte Benutzereingaben durch das Validierungsskript markiert. Die entsprechenden li- oder fieldset-Elemente werden um einen passenden class-Wert (z.B. fehler) erweitert. Zusätzlicher Inhalt wird eingefügt, der den Fehler beschreibt. Entsprechen die Eingaben den Anforderungen, können zusätzliche Transaktionen zwischen Client und Server vermieden werden. 3. Die Formulareingaben werden an den Server übergeben. Hier werden die Daten »gesäubert«, um das Einfügen von Schadcode (SQL-Injection, XSS-Angriffe etc.) zu verhindern. 4. Die »gesäuberten« Eingaben werden auf der Serverseite, ähnlich dem Test im Client, erneut auf mögliche Fehler überprüft. Wurden Eingabefehler gefunden, wird das gleiche veränderte Markup verwendet wie bereits bei der Überprüfung durch den Browser in Punkt 2. 5. Die Schritte 1, 3 und 4 werden wiederholt, bis die Benutzereingaben fehlerfrei sind. Die Fehlerbeschreibung sollte entweder zu Beginn des Formulars oder am Anfang des li-Elements eingefügt werden, das den Fehler enthält. Am besten verwenden Sie beide Positionen oder nur die zweite. Werden die Fehlerbeschreibungen nur am Anfang des Formulars angezeigt, muss der Benutzer möglicherweise zwischen der Beschreibung und dem fehlerhaften Formularfeld hin- und herscrollen, sofern er die Fehler überhaupt als solche erkennt. Für die Fehlerbeschreibung könnten Sie beispielsweise die folgenden Regeln verwenden, um die bereits gezeigten Stile für .erforderlich span.warnung zu erweitern: .fehler .warnung { display: block; background-color: rgb(160,0,0); color: rgb(255,255,255); font-weight: bold; } .fehler input { border: 1px solid rgb(160,0,0); background-color: rgb(255,160,160); }
Zusätzlich zu diesen Stilen (die hier nur der Illustration dienen sollen) können Werte für clear, width und margin definiert werden, um sicherzustellen, dass die Fehlermeldungen horizontal an dem dazugehörigen Formularelement oder fieldset ausgerichtet werden. 264
|
Kapitel 13: Saubere und zugängliche Formulare
Die Attribute »disabled« und »readonly« Wenn Sie jemals ein Betriebssystem installiert haben, speziell eines, bei dem ein Lizenzschlüssel eingegeben werden muss, sollten Sie mit deaktivierten Kontrollelementen bereits vertraut sein. Die Installation von Software geschieht oft in mehreren Schritten. Jeder Schritt muss erst vollständig durchgeführt werden, damit der nächste ausgeführt werden kann. Bis dahin erscheint der »Weiter«-Button oft »ausgegraut«. Ähnliche Beschränkungen können Sie auch in Webformularen verwenden, indem Sie das Attribut disabled (oder seltener auch readonly) verwenden. Welche Formularelemente diese Attribute unterstützen, sehen Sie in Tabelle 13-3. Tabelle 13-3: Unterstützung für die Attribute »disabled« und »readonly« Attribut
button
input
option
select
textarea
disabled
✓
✓
✓
✓
✓
readonly
✓
✓
Dadurch. dass der Benutzer bestimmte Formularelemente erst verwenden kann, wenn bestimmte Voraussetzungen erfüllt sind, lässt sich eine elegantere Benutzerführung erreichen. Dies funktioniert allerdings nur durch den Einsatz von JavaScript. Daher sollten Sie bei Verwendung dieser Attribute immer auch eine Alternative bereithalten, mit der die erforderlichen Felder überprüft werden, wenn clientseitige Skripte nicht funktionieren. Wenn Sie sich entscheiden, auszufüllende Felder zu verstecken, um Abhängigkeiten zwischen mehreren Formularen gerecht zu werden, sollten Sie den Platz für diese Felder freihalten, indem Sie sie per Ajax laden oder mit einer anderen CSS-Eigenschaft als display verändern. Wenn Sie sich nur auf display verlassen, können die Ergebnisse verwirren und die Benutzbarkeit beim Einsatz von Hilfstechnologien stark verringern.
Zugängliche Formulare erstellen Viele kommerzielle Websites würden ohne Formulare überhaupt nicht funktionieren. Deshalb muss bedacht werden, dass ein nicht unerheblicher Teil Ihrer Besucher aufgrund körperlicher oder mentaler Einschränkungen Schwierigkeiten bei der Benutzung Ihrer Website haben könnte. Die Behinderungen, die sich auf das Design von Websites auswirken können, lassen sich in mehrere Kategorien unterteilen und werden hier mit einigen Beispielen erläutert: Motorische Einschränkungen Benutzer mit eingeschränkter Bewegungsfähigkeit haben möglicherweise Probleme bei der Benutzung von Tastatur und/oder Maus. Beispiele wären: – gebrochene Arme oder Finger – chronische Sehnenscheidenentzündung oder RSI-Syndrom
Zugängliche Formulare erstellen
|
265
– periphere Neuropathie – Querschnittslähmung und Lähmung aller vier Gliedmaßen Eingeschränkte Sehfähigkeit Um die Benutzerschnittstellen von PCs und Mobilgeräten erfolgreich benutzen zu können, sind meist ein funktionierender Seh-, Hör- und Tastsinn des Benutzers notwendig. Hierbei ist der Sehsinn für die Benutzung von Websites besonders wichtig. Dies gilt speziell für Sites, die Formulare einsetzen. Können Benutzer die Formulare oder die einzugebenden Daten nicht sehen, ist ihre Fähigkeit, diese Websites zu benutzen, deutlich eingeschränkt. – Kurzsichtigkeit – Astigmatismus (»Schielen«) – altersbedingte Degeneration der Sehfähigkeit – Makulardegeneration – Glaukom (»grüner Star«) – Farbenblindheit – Blindheit Eingeschränkte Wahrnehmung Die Wahrnehmung von Medieninhalten, inklusive des Webs, ist eine reine Funktion des Gehirns und Verstandes. Ein Benutzer, der sich nicht auf eine Site konzentrieren kann oder ihren Wert nicht schnell genug erkennt, wird vermutlich nicht lange bleiben. Daher ist Kürze hier besonders wichtig. – Aufmerksamkeitsdefizit – Legasthenie – Störungen der auditiven Wahrnehmung – symptomatische Hirnverletzungen – akuter Vitamin B-Mangel Neben den hier genannten gibt es noch viele andere Einschränkungen, die die Fähigkeit, eine Website zu benutzen, beeinflussen können. Zeitmangel gehört zwar nicht zu den oben genannten Einschränkungen, tritt aber trotzdem recht häufig auf. Sehr wahrscheinlich kennen Sie oder Ihre Bekannten wenigstens ein paar der hier genannten Probleme. Mit dreien dieser Einschränkungen habe ich persönliche Erfahrungen, mit zweien davon habe ich täglich zu tun. Trotzdem benutze ich das Web. Was sagen Sie nun?
Zugängliche Formulare implementieren Wenn Sie die folgenden Dinge beachten, können Sie Ihre Website für praktisch alle Besucher benutzbar machen:
266
|
Kapitel 13: Saubere und zugängliche Formulare
Halten Sie sich beim Design und Testen jedes Projekts an die Zugänglichkeitsrichtlinien (WCAG) für Webinhalte des W3C. Diese Empfehlung hat mehr mit guten Angewohnheiten als mit konkreten Arbeitsschritten zu tun. Wenn Sie sich bei der Umsetzung einer Website prinzipiell an die Anforderungen der WCAG (eine deutsche Übersetzung finden Sie auf der Website des W3C (http://www.w3c.de/Trans/WAI/webinhalt.html)) halten, wird der Aufwand für die Implementierung schnell geringer. Verlassen Sie sich nie auf eine einzige Möglichkeit, um den Kontext anzuzeigen, oder Benutzereingaben entgegenzunehmen. Bei der Verwendung von Text sollte auch ein rein visueller Hinweis vorhanden sein (und umgekehrt). Stellen Sie sicher, dass Ihre Website auch benutzbar ist, wenn nur eine Maus (Trackpad usw.) oder eine Tastatur verwendet wird, ohne sich auf eines der beiden Geräte zu beschränken. Strukturieren Sie die Reihenfolge der Elemente im Quellcode so, dass die Inhalte auch ohne die Verwendung von CSS noch gut lesbar sind. Hierfür ist es vor allem wichtig, die wichtigen Dinge prinzipiell an den Anfang des Dokuments zu stellen. Sobald Sie von Ihren Benutzern mehr erwarten als »Gehen Sie, wohin Sie wollen« und »Geben Sie einfach irgendwelche Daten ein«, sollten Sie Ihre Anforderungen klar und verständlich formulieren. Geben Sie knappe Anweisungen. Sie wollen die Intelligenz der Benutzer respektieren, aber nicht auf die Probe stellen. Reden Sie mit Ihren Besuchern nicht »von oben herab«. Gleichzeitig kann die Usability schnell leiden, wenn Sie davon ausgehen, dass Ihre Besucher auf dem gleichen Wissens- und Erfahrungsstand sind wie Sie. Vermeiden Sie die Regeln display: none und visibility: hidden, es sei denn, Sie wollen die dazugehörigen Inhalte vor Benutzern mit Sehschwierigkeiten verbergen. Da viele Hilfstechnologien auf der Annahme basieren, dass Stildefinitionen nur für bildschirmbasierte Medien gelten, signalisieren diese Anweisungen, dass der Inhalt der entsprechenden Elemente ignoriert werden soll. Tun Sie alles, was möglich ist, damit die Benutzer ihre eigenen Eingaben lesen können. Das Ignorieren dieser Anforderung führt beim Benutzer zu unnötigem Schielen, Scrollen und zur Benutzung des Cursors. Diese Dinge sind gerade für Menschen mit motorischen Einschränkungen schwer durchzuführen. Konsistenz macht Ihre Site vorhersagbarer; handeln Sie beim Design und bei der Implementierung Ihres Layouts entsprechend. Richten Sie die Formularelemente an gemeinsamen Achsen aus, und sorgen Sie dafür, dass ihre Größe möglichst wenig variiert. Platzieren Sie Paare aus label- und Formularelementen in Spalten, so dass die Formularelemente genauso aufeinander folgen wie die Zeilen im Haupttext von oben nach unten angeordnet sind.
Zugängliche Formulare erstellen
|
267
Wenn Sie Techniken wie Ajax oder das Aktivieren und Deaktivieren von display-Werten verwenden, sollten Sie ein JavaScript-Framework verwenden, um die Richtlinien der WAIARIA (W3C Web Accessibility Initiative Accessible Rich Internet Applications) umzusetzen. Weitere Informationen zur WAI-ARIA finden Sie auf der Website zu diesem Buch. Deutschsprachige Informationen und weiterführende Links finden Sie außerdem im entsprechenden Artikel der Wikipedia: (http://de.wikipedia.org/wiki/Accessible_Rich_ Internet_Applications). Folgen Sie den HTML- und CSS-Spezifikationen beim Schreiben Ihres Markup-Codes eher sinngemäß als buchstabengetreu. Hierzu gehört, dass Sie table-Elemente nicht für das Layout der Seiteninhalte verwenden und dass Sie Ihre Bilder prinzipiell mit alt-Attributen versehen. Gibt es spezielle Elemente für Ihre Aufgabe und werden sie ausreichend unterstützt, sollten Sie sie auch benutzen. Gibt es keine Elemente für Ihren Zweck, verwenden Sie die Attribute class und id, um den Kontext klarzustellen, anstatt damit nur die Präsentation zu steuern.
Formulare über die Tastatur steuern Speziell Formularelementen und Links kann mit der Tabulartortaste der »Fokus« zugewiesen werden. Über die Enter-Taste können Links aktiviert (»angeklickt«) und Formulare abgeschickt werden. Auf der Strukturebene wird diese Funktionalität über das Attribut tabindex implementiert. Hiermit können Sie die Reihenfolge festlegen, nach der die einzelnen Elemente mit der Tabulatortaste »fokussiert« werden. Normalerweise verwenden Sie die Tabulatortaste, um den Fokus von einem Element zum nächsten zu bewegen. Hat ein Element einen passenden Wert für das tabindex-Attribut, ändert sich diese Reihenfolge. Das Element mit dem niedrigsten tabindex-Wert wird zuerst angesprungen, das mit dem höchsten Wert zuletzt. Wurde zwei Elementen der gleiche Wert für tabindex zugewiesen, erhalten sie den Fokus gemäß ihrer Reihenfolge im Quelltext. Allerdings hat tabindex auch zwei Nachteile. Wurde das Attribut auf langen Seiten schlecht implementiert, wird möglicherweise über große Entfernungen gescrollt, was zu Desorientierung führen kann. Außerdem werden die Werte für tabindex bei einer Revision der Website nur selten mit aktualisiert. Andererseits kann eine Seite mit einer vernünftigen Quellcode-Reihenfolge auch davon profitieren, wenn wichtige Elemente um die Formulierung tabindex="0" erweitert werden. Hierdurch erhalten diese Elemente den Fokus im Verlauf des Besuchs relativ früh. (In manchen Fällen ist tabindex die einzige Möglichkeit, einem Element den Fokus zu geben.) Verwenden Sie für tabindex einen negativen Wert, so wird es von der Tabulator-Reihenfolge des Dokuments ausgenommen. Das Attribut accesskey ermöglicht es dem Benutzer, mit einem festgelegten Tastaturkürzel direkt auf ein Element zuzugreifen und so die Tabulator-Reihenfolge komplett zu umgehen. Als Werte für accesskey kann ein beliebiges druckbares Zeichen verwendet 268
|
Kapitel 13: Saubere und zugängliche Formulare
werden, das ohne Hilfstasten (Shift etc.) auf der Tastatur erreicht werden kann. Das entsprechende Element erhält den Fokus, wenn der Benutzer die Taste in Kombination mit einer der in Tabelle 13-4 genannten Sondertasten drückt. Tabelle 13-4: Verwendung von »accesskey« in den wichtigsten Browsern Browser
Tastenkombination
Firefox/Windows
Alt+Shift+accesskey
Internet Explorer
Alt+accesskey
Safari und Firefox/Mac
Ctrl+accesskey
Zwei der hier genannten Plattformen haben bezüglich der Benutzererwartungen spezielle Implikationen. Die erste der beiden ist Mac OS X. Hier wird anstelle der Befehlstaste (Cmd), die Taste Ctrl für das accesskey-Tastaturkürzel verwendet. Da die Befehlstaste für die Ausführung von Programmbefehlen reserviert ist und Ctrl außerhalb der Kommandozeile nur wenige Funktionen hat, ist diese Zuweisung sinnvoll und wenig riskant. Im Gegensatz zu dieser glücklichen Situation steht die Implementierung im Internet Explorer. Viele Windows-Programme werden mithilfe der Alt-Taste gesteuert, der gleichen Taste, die auch für accesskey zuständig ist. So öffnet Alt-D das Menü Datei, Alt-A das Menü Ansicht und so weiter. Kommt es zu Überschneidungen zwischen den Werten für accesskey und reservierten Zeichen, erhält der Wert für accesskey normalerweise den Vorrang. Die entsprechende Tastenkombination für die Menüsteuerung steht dann nicht mehr zur Verfügung. Angesichts des hohen Marktanteils des Internet Explorers, sollte die Verwendung der »reservierten« Buchstaben als Wert für accesskey nach Möglichkeit vermieden werden. Manche Werkzeugleisten und Browser-Erweiterungen können den Ausschluss weiterer Tasten in verschiedenen Windows-Browsern bedeuten.
Neue Merkmale in HTML 5 Das Hauptaugenmerk von HTML 5 lag anfangs darauf, HTML-Formulare mit neuen Funktionen zu versehen. Dies ist der Bereich, in dem die größten Unterschiede zu Vorgängerversionen zu erwarten sind. Allerdings befindet sich HTML 5 noch in der Entwicklungsphase. Dieser Abschnitt bietet einen Überblick über die neuen Formularfunktionen sowie Details zu einigen Merkmalen, die – auch wenn sie noch nicht sehr bekannt sind – große Auswirkungen auf die Benutzer haben können.
Neue Eingabeelemente HTML 5 verbessert die HTML 4-Formulare durch 13 neue input-Elemente: •
datetime (globale Angabe von Datum und Uhrzeit inkl. Zeitzone)
•
datetime-local (lokale Angabe von Datum und Uhrzeit)
Neue Merkmale in HTML 5
|
269
•
date (Datum)
•
month (Jahr und Monat)
•
time (Uhrzeit)
•
week (Jahr und Woche)
•
number (numerische Eingaben)
•
range (Zahlenbereich)
•
email (E-Mail-Adressen)
•
url (URLs)
•
search (Suchfeld)
•
tel (Telefonnummern)
•
color (Anzeige einer Farbpalette)
Diese neuen Eingabeelemente stellen für Autoren eine deutliche Verbesserung dar. Ist für die Eingabeelemente eine spezielle Benutzerschnittstelle nötig, wird diese nativ vom Browser bereitgestellt, ohne dass hierfür JavaScript-Code oder -Bibliotheken nötig wären. Für den Typ color erzeugt der Browser beispielsweise eine Farbpalette, aus der Besucher durch Zeigen und Klicken eine Farbe auswählen können; für den Typ date wird ein Minikalender angezeigt, aus dem der Benutzer das gewünschte Datum auswählen kann, und so weiter. Da diese Elemente über ein eingebautes (statt über eine selbstgezimmertes) GUI-Element zugänglich gemacht werden, ist außerdem sichergestellt, dass nur gültige Werte eingegeben werden können. Ein weiterer großer Vorteil dieser automatischen Überprüfung auf der Clientseite besteht für Endbenutzer darin, dass keine ungültigen Werte eingegeben werden oder die Benutzer schnell von einer fehlerhaften Eingabe informiert werden können. (In HTML 5 ist die automatische Überprüfung von Formulareingaben standardmäßig aktiviert. Sie kann nur durch eine Änderung der Benutzereinstellungen oder explizit durch den Autor, und dann nur für die entsprechende Seite, vorgenommen werden. Hierfür muss der Autor das Formular oder ein bestimmtes Element mit dem Attribut formnovalidate versehen.)
Das Attribut »required« Das Attribut required ist ein weiteres neues Merkmal in HTML 5-Formularen. Der Zweck ist recht einfach, dafür aber umso mächtiger. Wird für ein input- oder textarea-Element das Attribut required angegeben, wird festgelegt, dass der Benutzer in diese Felder auf jeden Fall eine Eingabe vornehmen muss, damit das Formular abgeschickt werden kann. In manchen Formularen müssen bestimmte Werte unbedingt eingegeben werden, damit sie korrekt verarbeitet werden können. Bei einem Anmeldeformular wäre dies beispielsweise die Angabe eines Benutzernamens. Danach muss der Formularinhalt überprüft werden und der Benutzer ggf. informiert werden, wenn versucht wird, das Formular mit leeren oder falsch ausgefüllten Feldern abzuschicken. Diese Überprüfung findet normalerweise auf eine von zwei Arten statt. Die erste Möglichkeit besteht in einer Überprüfung
270
|
Kapitel 13: Saubere und zugängliche Formulare
auf der Serverseite, nachdem das Formular abgeschickt wurde. Dies ist allerdings nicht optimal, weil hierfür zusätzliche Daten über das Netzwerk geschickt werden müssen, was die Wartezeit verlängert. Die zweite und bessere Methode besteht darin, die Formulareingaben auf der Clientseite zu überprüfen. Das geht im Moment allerdings nur mit eigenem JavaScript-Code oder bestimmten JavaScript-Bibliotheken. Und hier kommt das Attribut required ins Spiel. Es sorgt dafür, dass Sie als Autor keinen JavaScript-Code mehr für die clientseitige Überprüfung der erforderlichen Formularfelder benötigen. Die Validierung wird stattdessen vom Browser übernommen. Das Attribut hat aber auch Vorteile für den Endbenutzer, weil es Zeit spart und Schwierigkeiten vermeidet. Die Benutzererfahrung ist in allen Webapplikationen konsistent, da der Benutzer bei fehlenden oder fehlerhaften Werten für die erforderlichen Felder informiert wird. Diese Meldungen erscheinen außerdem in der bevorzugten Sprache des Benutzers und sich nicht mehr auf die verfügbaren Sprachen der Webapplikation beschränkt.
Neue Merkmale in HTML 5
|
271
KAPITEL 14
Die schlechten Seiten
Das Web ist ein Wunder der modernen Zivilisation. Wie noch in keiner anderen Zeit zuvor können Menschen ihre Werke veröffentlichen, ohne hierfür eine Zustimmung von außen zu brauchen. Dabei spielt das Web eine entscheidende Rolle. Leider hat das Web, wie jedes System, seine Macken, Makel und Malaisen. Dies sind die Dinge, die wir in diesem Buch als die schlechten Seiten bezeichnen. Einige davon werden wir in diesem Kapitel besprechen – natürlich inklusive der Gründe. Außerdem zeigen wir Ihnen, wie Sie mit den schlechten Seiten umgehen müssen, wenn es mal nicht anders geht. Das Kapitel endet mit im Abschnitt »Die furchtbaren Seiten« auf Seite 296, die quasi ohne Ausnahme vermieden werden sollten.
Die schlechten Manieren des Internet Explorers (speziell IE 6) Das Problem mit dem Internet Explorer ist weniger ein Problem von HTML und CSS, sondern eher von ihrer Implementierung. Diese Schwächen werfen lange Schatten. Als der Internet Explorer 6 im Jahre 2001 veröffentlicht wurde, war er mit Abstand der beste verfügbare Browser. Warum? • Er bot mehr und bessere Unterstützung für Webstandards als seine Vorgänger, und er hatte die damals beste Unterstützung für die DOMAPI. • Die Firefox zugrunde liegende Rendering-Technologie namens Gecko war noch zwei Jahre von ihrer Reife entfernt. • Der Internet Explorer 5 für Macintosh beanspruchte für sich, die am weitesten entwickelte CSS-Unterstützung zu bieten. Allerdings benutzte er hierfür seine eigene Rendering-Engine und litt unter einem geringen Marktanteil und schlechtem internen Support. • Netscape lag im Sterben. Nach Netscape 4 passierte einfach nicht mehr viel. • Safari war damals noch gänzlich unbekannt und sollte seine volle Reife erst Jahre später erreichen. Es dauerte ein weiteres Jahr, bis Safari in Sachen Darstellungsfähigkeit den gleichen Funktionsumfang erreichte wie die anderen Browser.
|
273
Das heißt, der Internet Explorer 6 war bei seiner ersten Veröffentlichung gar nicht mal so schlecht und hatte zudem einen recht großen Marktanteil. Angespornt von Netscapes anfänglicher Dominanz im Web, machte Microsoft seine Sache ziemlich gut und veröffentlichte in vier aufeinanderfolgenden Jahren hervorragende Webbrowser. Am Ende ruhte man sich dann leider doch zu lange auf den eigenen Lorbeeren aus. Apple, Inc. und der Mozilla Foundation kam gemeinsam die Aufgabe zu, diese Lücke zu schließen. Schritt für Schritt entwickelten sie ihre eigenen Browser weiter und stellten sie den Nutzern zur freien Verfügung. Spätestens 2005 gab es keinen Zweifel mehr, dass der Internet Explorer langsam in die Jahre kam.
Browserkrieg 2.0 Mitte 2005 empfahl die US-Regierung aus Gründen der Sicherheit, ganz auf die Verwendung des Internet Explorers zu verzichten. Befürworter offener Software und andere Kämpfer gegen die Monokultur beschworen enthusiastisch die Vorteile alternativer Browser. Die Ergebnisse nagten Monat für Monat am Marktanteil des Internet Explorers. Aufgerüttelt aus seinem Schlummer, hat Microsoft seitdem zwei neue Versionen des Internet Explorers auf den Markt gebracht, die ihren gemeinsamen Vorfahren um Längen übertreffen. Und trotzdem scheint dieser inzwischen über acht Jahre alte Dinosaurier nicht totzukriegen zu sein. Abgesehen von einfachen Netzwerkeffekten, sind hier ein paar Gründe, warum der Internet Explorer 6 immer noch benutzt wird: • Bei der ersten Veröffentlichung war die Menüleiste des Internet Explorers 7 standardmäßig versteckt, was viele Gelegenheitsbenutzer verwirrte und abschreckte. • Da IT-Firmen (eine von Microsofts wichtigsten Einnahmequellen) trotz der Effizienz, die sie ermöglichen, das Aktualisieren von Browsern häufig nur als Kostenstelle betrachteten, wurden die besten Absichten von der Maxime »was nicht kaputt ist, muss auch nicht repariert werden« wieder zunichte gemacht. Aus diesem Grund werden Aktualisierungen des Internet Explorers häufig als unnötiger Aufwand betrachtet. • Seit seinem Erscheinen hat Windows XP, dem Internet Explorer 6 standardmäßig beilag, mehr Benutzer an sich gebunden als jedes der neueren Microsoft-Betriebssysteme. Windows 7 ist seit Oktober 2009 auf dem Markt, und es ist zu erwarten, dass es Windows XP den Rang abläuft. Allerdings wird sein Marktanteil noch für einige Zeit unter dem seines Vorgängers liegen. • Es ist relativ einfach, »Low-Pass«-Filter für CSS zu verwenden, die viele der Fehler des Internet Explorers 6 vor seinen Benutzern verbergen – zumindest in einem gewissen Maße. • Zwischen 2001 und 2005 stellte eine Reihe von Anbietern, insbesondere Banken, Websites ins Netz, die speziell für den Internet Explorer für Windows programmiert waren. Jedenfalls machten sie diesen Eindruck, weil die für die Seiten zuständigen
274
|
Kapitel 14: Die schlechten Seiten
Leute es einfach nicht besser wussten. Dieser Überfluss an plattformspezifischen Diensten sorgte ungewollt für ein hohes Maß an Furcht, Unsicherheit und Zweifel, was die Glaubwürdigkeit anderer Browser anging. • Lässt man Sicherheit, Filter und plattformspezifische Programmierung außer Acht, ist es den meisten Gelegenheitsbenutzern vollkommen egal, welchen Browser sie benutzen, solange er einigermaßen benutzbar ist und zu funktionieren scheint. In diesem Sinne ist der Internet Explorer 6 eigentlich schon selbst ein »Bad Part« – nicht wegen seiner Benutzerunfreundlichkeit, sondern weil er einfach nicht totzukriegen ist. Sobald etwas nicht unterstützt wird, wird allen Webbenutzern der Zugang zu neuen Webtechnologien verweigert, weil die meisten Geschäftskunden nicht einsehen, Geld für etwas auszugeben, das nur ein Bruchteil des Zielpublikums tatsächlich nutzen kann. In anderen Fällen bietet der Internet Explorer Unterstützung für bestimmte Funktionen, aber nur mit Methoden, die so verworren sind, dass ihre Implementierung von Entwicklern als große Belastung empfunden wird. In den folgenden Abschnitten finden Sie eine Untersuchung der Mängel des Internet Explorers. Wo es Hilfslösungen gibt, werden diese ebenfalls beschrieben.
Fehlende oder schlechte Unterstützung für Selektoren Tabelle 14-1 beschreibt die mangelhafte Unterstützung von Selektoren im Internet Explorer. Tabelle 14-1: Mängel in der Unterstützung von Selektoren im Internet Explorer Selektor
Unterstützt seit Version
Anmerkungen
> (Kindselektor)
7
[foo] (Attribut)
8
:first-child, :last-child
8
:nth-child()
vorr. 9
:before
8
:after
8
.foo.bar
7
IE 6 liest diesen Selektor als .bar.
:hover
3
Die Pseudoklasse :hover wurde in Version 7 nur auf Elemente angewandt, die keine a-Elemente waren.
Einfache Attributselektoren funktionieren in IE 8. Versuche, ihren Gültigkeitsbereich weiter einzuschränken, zeigen aber keine Ergebnisse.
Zähler (counter) werden ignoriert.
Damit eine Website möglichst umfassend mit IE6 kompatibel ist, sollten Sie diese Selektoren möglichst vermeiden. Alternativ kann ihr Verhalten mithilfe von JavaScript nachgebaut werden. Hierfür ist allerdings Code nötig, der die gewünschten Ergebnisse nur mit roher Gewalt erreicht.
Die schlechten Manieren des Internet Explorers (speziell IE 6)
|
275
Das Urteil: Verwenden Sie diese Selektoren dort, wo es nicht anders geht, aber informieren Sie Ihre Auftraggeber und Designer darüber, was sie zu erwarten haben. Ersetzen Sie die Pseudoelemente :first-child und :last-child sowie den Kindselektor > bei Bedarf durch class-Attribute und -Selektoren. Folgende Ressourcen können helfen, die durch Darstellungsfehler im Internet Explorer verursachten Layoutprobleme zu lösen: • »Position Is Everything«, http://www.positioniseverything.net/ • die Mailingliste css-discuss, sowie das dazugehörige Wiki und Archiv, http://css-discuss.incutio.com/
»hasLayout« hasLayout ist ein spezieller Parameter im Internet Explorer. Wird er über die DOMAPI abgefragt, hat er entweder den Wert true (wahr) oder false (falsch). Hat hasLayout für ein bestimmtes Element den Wert true, wird seine Präsentation durch die Logik der Rendering Engine definiert. Ansonsten bleiben viele CSS-Eigenschaften mysteriöserweise wirkungslos. Viele der Layoutprobleme, die Gestaltern beim Testen ihrer Arbeit im Internet Explorer 6 begegnen, haben hier ihren Ursprung.
Allerdings können Sie auch erzwingen, dass ein Element »Layout hat«, beispielsweise um ein Layoutproblem zu lösen. Hierfür muss die Rendering Engine von IE 6 davon überzeugt werden, dass für das Element zumindest die Breite oder die Höhe bekannt ist. Meistens gibt man hierfür position und height einen anderen Wert als static bzw. auto. Diese Technik ist auch als »Holly Hack« bekannt. Sie wurde benannt nach Holly Bergevin, dem Entwickler, der diese Methode bekannt gemacht hat. Eine andere Möglichkeit, um ein Element mit »Layout« zu versehen, besteht in der Definition zoom: 1. Sie wird von vielen Entwicklern bevorzugt, weil sie Probleme mit positionierten Elementen vermeidet (siehe im Abschnitt »Stapelung« auf Seite 103). Wird weiter oben in der Kaskade außerdem die Eigenschaft font-size mit einem Pixelwert definiert, können diese Probleme durch flexible oder gridbasierte Layouts größtenteils umgangen werden (siehe im Abschnitt »Layouttypen und Hilfslinien-Raster« auf Seite 108). Dies kann allerdings einen großen Nachteil für IE6-Benutzer mit Sehproblemen bedeuten, da sich die Textgrößen im Menü Ansicht in dieser Version nicht ändern lassen, wenn die Textgröße in Pixeln angegeben wurde. Das Urteil: Probleme lassen sich nicht ganz vermeiden. Hier heiligt der Zweck die Mittel. Diese Mittel sind am besten Conditional Comments für die betroffene(n) Version(en) des Internet Explorers. Unter Umständen hilft auch der »Star-html«-Hack (* html) als Low-Pass-Filter weiter.
276
|
Kapitel 14: Die schlechten Seiten
Verdoppelte Außenabstände: Der »Double Margin Bug« Sehen Sie sich einmal die folgende Stildefinition an: #irgendeinDiv { display: block; float: left; width: 20em; margin-left: 10em; }
Hier beziehen sich die Werte für float und margin-left auf die gleiche Seite des Elternelements, und aus irgendeinem unerfindlichen Grund meint der Internet Explorer 6 deshalb, den Wert von margin-left auf 20em verdoppeln zu müssen. Die Hälfte der Lösung für dieses Problem wird vom W3C in Abschnitt 9.7 der Spezifikation von CSS 2.1 dokumentiert. Die andere Hälfte der Lösung ist alles andere als intuitiv: Setzen Sie den Wert von display für das Element auf inline. Dies funktioniert, weil das Dokument durch die Werte von width und float trotzdem als Block-Element dargestellt wird. Eine ausführliche Diskussion dieser Lösung, die übrigens Steve Clason zugesprochen wird, finden Sie auf der Website von Positioniseverything.net (http://www.positioniseverything.net/explorer/doubled-margin.html).
Das Urteil: Zwar ist die Lösung für das Problem der doppelten Außenabstände ziemlich seltsam und wenig intuitiv. Allerdings ist dies genau die Art von unauffälligen Lösungen, die man sich für alle Hilfslösungen wünschen würde. Bitte gehen Sie weiter, hier gibt es nichts zu sehen.
»expression()«-Werte Wussten Sie, dass man in Stylesheets JavaScript-Code einbauen kann und dass der Internet Explorer ihn auswertet? Wenn Sie als Wert einer CSS-Eigenschaft ein expression()-Objekt angeben und für dieses als einziges Argument einen gültigen JavaScript-Ausdruck angeben, wird der Internet Explorer diesen Ausdruck ausführen und das Ergebnis als Wert für die Eigenschaft verwenden. Diese Funktion kann äußerst praktisch sein. Gleichzeitig läuft sie aber auch dem Geist des »progressive enhancement« zuwider. Daher kann ich vom Gebrauch von expression() nur abraten. Gegen die Verwendung von expression() spricht außerdem, dass Sie in einer expression()-Anweisung keine Dokumentenknoten referenzieren können. Das geht nur, wenn Sie das Skript mit einem defer-Attribut versehen, das dann das Stylesheet mit dem expression()-Objekt lädt. Dies ist gleichbedeutend mit einer absichtlichen Implementierung eines »Flash of Unstyled Content«, bei dem für kurze Zeit der Inhalt ohne die Gestaltung durch die Stylesheet-Regeln angezeigt wird. Das Urteil: Vermeiden Sie die Verwendung von expression() um die Struktur Ihres Dokuments nicht durcheinanderzubringen und die Sicherheit nicht zu gefährden. Ist das nicht
Die schlechten Manieren des Internet Explorers (speziell IE 6)
|
277
möglich, sollten Sie sie auf die kleinstmögliche Anzahl von Browsern beschränken. (Dies gilt nur deshalb nicht als »Awful Part«, weil es Ihnen vermutlich eines Tages den Hals rettet.)
ActiveX-Filter, Transparenz und Farbverläufe Die ActiveX-Plattform ermöglicht dem Internet Explorer den Zugriff auf eine Reihe von Filtern und Übergängen. Hierzu gehört vor allem der Alpha()-Filter, der im IE analog zur CSS 3-Eigenschaft opacity (gegenwärtig in Firefox und Safari als -moz-opacity bzw. -webkit-opacity implementiert) eingesetzt werden kann. Ein verwandter Filter ist zudem wichtig, um den Alphakanal von PNG-Dateien im Internet Explorer 6 richtig darzustellen, wie im folgenden Abschnitt besprochen wird. Um ein Element im Internet Explorer mit verschiedenen Arten von Transparenz zu versehen, können Sie eine Stildefinition wie diese verwenden: #foo { filter: progid:DXImageTransform.Microsoft.Alpha(opacity=xxx); }
In diesem Fall übernimmt opacity einen ganzzahligen Wert zwischen 0 und 100. Im Gegensatz dazu übernimmt die CSS3-Eigenschaft opacity einen Fließkommawert zwischen 0 und 1. Das Urteil: Die Verwendung dieses Merkmals (und seiner CSS3-Entsprechung) sollte im Moment noch auf zwei Fälle beschränkt bleiben: auf Übergänge, die mit einem Skript über DOM-API realisiert werden, und Layout-Situationen, in denen zwei sich überlappende Hintergrundbilder nicht im Hintergrund eines Vorfahren-Elements kombiniert werden können. In allen anderen Fällen sollte dieses Merkmal vermieden werden, bis die CSS3-Eigenschaft opacity gemäß ihrer Definition von einem Großteil der Browser unterstützt wird.
PNG-Unterstützung (oder ihr Fehlen) Tatsächlich können alle verwendeten Versionen des Internet Explorers PNG-Dateien darstellen. Beim IE6 gibt es da jedoch einen kleinen Haken. Bei voller Farbtiefe unterstützen PNG-Bilder Farbdaten mit 24 Bit pro Pixel (8 Bit pro Kanal, wie JPEG, Photoshop, Webfarben und sRGB). Außerdem kann in PNG die Transparenz für ein Pixel ebenfalls mit 8 Bit (256 Abstufungen) angegeben werden. Findet der Internet Explorer 6 ein Pixel, das nicht vollständig transparent ist (also einen anderen Alphawert hat als FF), stellt er dieses Pixel stattdessen grau dar. Um dieses Problem zu lösen wurde die »prozedurale Oberfläche« AlphaImageLoader eingeführt. In diesem Fall funktioniert das, indem die Beziehung des eingebetteten Bildes zum übrigen Stapelkontext verändert wird. Damit das auch für Hintergrundbilder funktioniert, ist eine Menge DOM-API-Hacking nötig.
278
|
Kapitel 14: Die schlechten Seiten
Die beste Lösung dieses Problems (zumindest aus Sicht des Gestalters) besteht in der Verwendung einer HTML-Component-Datei, die von Angus Turnbull (http://www.twinhelix.com/) erstellt wurde. Die Dokumentation ist (zusammen mit diversen Alternativen, inklusive JavaScript-basierten Lösungen) auf der Website zu diesem Buch (http://www. htmlcssgoodparts.net). verlinkt. Das Urteil: In den meisten Fällen lässt sich dieses Problem mit anderen Bildformaten umgehen. Glücklicherweise lösen Urheberrechtskonflikte nicht mehr den Aufruhr aus, den es bei der Einführung des Internet Explorers 6 gab. Warten Sie einfach, bis der Marktanteil des IE 6 unter fünf Prozent sinkt (vermutlich geschieht das Mitte bis Ende 2010). Danach benutzen Sie Ihre PNG-Dateien einfach wie gewünscht und sehen, was passiert, wenn Ihre PNGs mit Alphakanal ohne Stützrad fahren lernen. (Wenn genug Browserhersteller das tun, werden auch die Entscheider irgendwann merken, dass der Internet Explorer 6 seine Lebensspanne längst überschritten hat.)
Schlecht unterstützte CSS-Eigenschaften Es gibt eine Reihe von Eigenschaft/Wert-Paaren, die für geschickte Gestalter schon seit längerer Zeit besonders interessant sind. Nur zu dumm, dass der IE 6 diese Werte nicht so unterstützt, wie er sollte. Leider kann man da nicht viel machen. Das Urteil: Schreiben Sie nach Möglichkeit spezielle Stilregeln, ohne hierfür zusätzliche Elemente zu verwenden, die auf allen Plattformen zu den gewünschten Ergebnissen führen, ohne dass hierfür Filter oder andere Hirnakrobatik zum Einsatz kommt. Wenn Ihnen die Verwendung von position: fixed wichtig ist, haben Sie beim IE 6 schlicht Pech gehabt.
Probleme mit XHTML und XML Die mangelnde Unterstützung für korrekt ausgeliefertes XHTML ist ziemlich ärgerlich, weil es viele der praktischen Vorteile von XHTML zunichte macht. Und damit die Ironie gegenüber dem Frust die Oberhand behält, sei gesagt, dass der Internet Explorer der erste weitverbreitete Browser war, der XML überhaupt unterstützte. Obwohl XHTML nicht auf allen Plattformen richtig unterstützt wird, hat es einen positiven Einfluss auf die Arbeitsgewohnheiten von Entwicklern. Dennoch sollten Sie bei ganz normalen Webprojekten davon ausgehen, dass bei Ihren Besuchern nicht alle Merkmale von XHTML unterstützt werden. Wenn es Ihnen wichtig ist, können Sie das User-Agent-Feld des Request-Headers auslesen und dann einen passenden Content-Type in der Serverantwort verwenden. Allerdings hat dieser Ansatz seine eigenen Konsequenzen (z.B. wenn der falsche Content-Type an Benutzer geschickt wird, die sich auf der anderen Seite eines Proxy-Servers befinden).
Die schlechten Manieren des Internet Explorers (speziell IE 6)
|
279
Ein weiterer Nachteil bei der Auslieferung Ihrer Inhalte als XML besteht darin, dass die XML-Spezifikation falsch formatiertes Markup im Benutzerprogramm absolut nicht verzeiht. Sobald Ihre Website Inhalte von Drittanbietern einbindet und Sie für Ihre Dokumente text/xhtml+xml als Inhaltstyp angeben, sind Schwierigkeiten vorprogrammiert. Das Urteil: In einer idealen Umgebung bietet XHTML ungeahnte Möglichkeiten. Leider ist das Web von heute nicht diese ideale Umgebung. Mist! Verwenden Sie XHTML 1.0, und liefern Sie es als Content-Type: text/html aus – oder verwenden Sie einfach HTML.
Ein hässliches System Bis zu einem gewissen Grad haben sich die Leute an das Design des Webs und des Internets im Allgemeinen gewöhnt. Das Web ist jedoch deutlich größer als die subjektiven Welten, in denen die meisten Benutzer leben. Tatsächlich umspannt es die ganze Welt, was zu einigen interessanten Eigenheiten im System führt.
Zerbrechliche Templates und Inhalte von Drittanbietern Wenn Sie sich die Webwerbung, Blog-Kommentare, Schnipsel von sozialen Netzwerken und die Lawine an Inhalten von Drittanbietern ansehen, wird Ihnen schnell klar, dass Sie sich kaum darauf verlassen können, dass Ihre Dokumente so makellos bleiben wie am Tag ihrer Veröffentlichung. Nicht jeder ist schließlich so mutig wie Sie. Leider lässt sich dieses Problem weder vermeiden noch umgehen, selbst wenn Sie als DOCTYPE nicht Strict, sondern Transitional verwenden. Manchmal landet eben auch Müll auf Ihrer Site. So ist das Leben. Das Urteil: Versuchen Sie, so viele Besucher und Drittanbieter von Inhalten wie möglich dazu zu bringen, sich an Ihre Standards zu halten, ohne hierbei Ihren Arbeitsablauf oder gar Ihre Lebensweise zu ändern. In der Zwischenzeit verwenden Sie die bestmöglichen Werkzeuge, um Dinge wie Benutzerkommentare von überflüssigem Markup zu befreien.
Markup-Validierung als Voraussetzung für korrekte Stylesheet-Implementierung Hiermit kommen wir zu einer der schlimmsten schlechten Seiten, und zwar nicht, weil diese Methode vermieden werden sollte, sondern weil sie einen der größten Mängel im System von HTML und CSS aufzeigt. Sobald Sie ein schließendes Tag vergessen oder einen id/class-Wert falsch schreiben, sorgen Sie automatisch dafür, dass die Kaskade nicht mehr so funktioniert wie vorgese-
280
|
Kapitel 14: Die schlechten Seiten
hen. Auch wenn sich die Browserhersteller nach Postels Gesetz (siehe im Abschnitt »HTML-Syntax« auf Seite 7) richten und dadurch manche Fehler in der Kaskade verbergen, können Sie nicht davon ausgehen, dass das in allen Fällen funktioniert. Sobald Ihr Markup auch nur einigermaßen komplex ist, finden Sie die Fehler in der Kaskade am besten, indem Sie Ihren Code validieren. Das Urteil: Dies ist eines der notwendigen Übel, das einige strikte Konstruktionisten als eine der wenigen Barrieren loben, die angehenden Webentwicklern im Wege stehen.
»Optimiert für …« Der Fokus auf bestimmte Browserplattformen, der in den Kindertagen des Webs üblich war, ist heute kein Thema mehr. Damals war Netscape besser als Mosaic, wurde aber bald vom Internet Explorer 3.0x überflügelt, dessen Darstellung deutlich besser war als alles, was Netscape damals zu bieten hatte. Heutzutage ist es wichtig, auf welcher Plattform Sie entwickeln. Wenn Sie nicht gerade für ein Publikum arbeiten, das ausschließlich den Internet Explorer einsetzt, sollten Sie Firefox verwenden (dank seiner unvergleichlich guten Unterstützung der Webstandards). Die gute Nachricht ist, dass sich niemand dafür interessiert, welche Entwicklungsplattform Sie verwenden, und dass das auch niemand tun muss. Gelegentlich werden Ihnen trotzdem Entscheider oder Auftraggeber begegnen, die wollen, dass die Dinge genau so aussehen wie auf ihrem Rechner, selbst wenn sie uralte Hardware verwenden und am Nachmittag mit der Sonne im Rücken arbeiten. Das Urteil: Es lohnt sich, diese Auseinandersetzung zu führen. Erziehen Sie. Schleifen Sie die Entscheider persönlich von ihrem Schreibtisch weg, und fordern Sie sie auf, Ihre Arbeit einmal in einer anderen Umgebung zu betrachten. Gehen Sie bei Bedarf diplomatisch vor. Machen Sie sich für die abgestufte Unterstützung stark (im folgenden Abschnitt besprochen). Lassen Sie nicht auf sich herumtrampeln.
Abgestufte Unterstützung Wenn Sie gut aufgepasst haben, oder Ihnen Apples Designentscheidungen wirklich wichtig sind, ist Ihnen vermutlich aufgefallen, dass die meisten Personal Computer inzwischen mit 64-Bit-Systemen arbeiten. Dies ist der erste große Entwicklungsschritt im Softwaredesign seit vielen Jahren. Andererseits müssen Webentwickler heutzutage deutlich weniger Umgebungen berücksichtigen als noch vor zehn Jahren. Damals konnte eine zwei Jahre alte Workstation schon als Auslaufmodell gelten. Die größte Vielfalt müssen Gestalter mit ziemlicher Sicherheit bei den verschiedenen Bildschirmauflösungen berücksichtigen. Zwar gibt es immer noch einige Leute, die Ihre Website per Modem oder über das Handy aufrufen; die meisten Benutzer werden aber in der Lage sein, einigermaßen aktuelle Software zu benutzen. Ein hässliches System
|
281
Aufgrund der Apathie vieler gelegentlicher Webbenutzer und des vergleichsweise langsamen Fortschritts bei der Unterstützung neuer Funktionen werden Sie jedoch nicht umhin können, eine große Zahl verschiedener Browserplattformen zu unterstützen. Hierbei haben es einige Gestalter schwerer als andere. Leute, die an einem Intranet arbeiten, auf das nur mit Windows-Rechnern zugegriffen wird, brauchen sich überhaupt keine Sorgen zu machen, es sei denn, sie verwenden Software von der Stange, die von kleinen Herstellern stammt. Die Namen der Firmen, die sich mit der Browservielfalt auseinandersetzen müssen, kennt man in jedem Haushalt: Yahoo!, Amazon, Nachrichten-Websites, soziale Netzwerke wie Facebook und Diensteanbieter wie Banken und andere Zahlungsdienstleister. Yahoo! wurde hier absichtlich zuerst genannt. Yahoo! war die erste Firma, die ein Testund Klassifizierungssystem entwickelt, implementiert und bekannt gemacht hat, das auf allen Browsern angemessene Standards einhält. Jede Kombination aus Browser und Betriebssystem wird dabei von Yahoo!s Qualitätssicherungsteam in eine von drei Leistungsstufen eingeteilt: Klasse »A« Diese Browser sind aktuell, weit verbreitet und unterstützen beliebte, aber nicht veraltete Merkmale. Sie bieten sehr gute Unterstützung für standardkonforme Implementierungstechniken. Die Benutzererfahrung entspricht mehr oder weniger genau den Zielen des ursprünglichen Site-Designs. Klasse »C« Diese Plattformen profitieren am meisten vom progressive enhancement. Möglicherweise können nicht alle Funktionen so verwendet werden, wie eigentlich geplant, aber Besucher können die Site immer noch effektiv benutzen. Klasse »X« Diese Plattformen sind absichtlich nicht Teil der anderen Klassen. Viele dieser Browser sind zumindest teilweise in der Lage, die Website richtig darzustellen. Der größte Teil dieser Browser wurde gerade neu veröffentlicht. Die anderen haben einfach einen zu geringen Marktanteil. Support-Tickets für diese Plattformen werden meist ignoriert, bis der Marktanteil groß genug ist, um normale Tests zu rechtfertigen. Zusätzlich zur Klassifizierung von Yahoo! verwende ich noch eine Klasse »B«. Diese Browser unterstützen nicht das gesamte Verhalten, sind aber in der Darstellung noch sehr nah am Optimum. In manchen Fällen ist es sinnvoll, diese Prioritäten umzukehren. Da ich meistens allein arbeite und beim Testen nur wenig Unterstützung von außen bekomme, landen bei mir weit mehr Plattformen in der Kategorie »X« als bei großen Webschmieden. In meinen Projektbeschreibungen gibt es einen Punkt, der in Yahoo!s Beschreibung der abgestuften Unterstützung zu fehlen scheint: Die Benutzererfahrung sollte für jeden Besucher in einer bestimmten Klasse konsistent sein. Für die Klasse »A« sollte die Konsistenz unabhängig von der verwendeten Plattform sehr hoch sein. 282
|
Kapitel 14: Die schlechten Seiten
Jetzt fragen Sie sich vielleicht, warum das eine schlechte Seite sein soll. Für diese Einordnung gibt es mehrere Gründe. Der wichtigste lautet: Der abgestufte Support rechtfertigt die Marktposition von »Ferner liefen«-Browsern wie Internet Explorer 6 (und davor Netscape 4). Diese Browser sind nur aufgrund von Netzwerkeffekten und Beharrlichkeit noch so beliebt – jedenfalls mit Sicherheit nicht wegen ihrer Verdienste. Der zweite Grund ist, dass die Tests zur Qualitätssicherung am ehesten mit der Herstellung von Würstchen vergleichbar sind. Die Kunden wollen das Endprodukt haben, aber auf keinen Fall sehen, wie es hergestellt wird. Das Urteil: Verwenden Sie abgestuften Support gut und häufig. Behalten Sie bei den Testergebnissen die Interessen Ihrer Besucher im Auge. Das gefällt Ihnen vielleicht nicht – bestimmt aber Ihren Besuchern.
»embed« oder »object« Das andauernde Überleben des embed-Elements ist vermutlich eines der schlimmsten Beispiele für angewandte Netzwerk-Effekte. Zu den Zeiten, als Windows Media Player ein nachträglicher Einfall war, kannte man Flash am ehesten durch die Gabocorp-Website. Während der Real Networks Player half, einen Sitz im US-Senat zu bezahlen, war Netscape der erste Browser, der die Verwendung von Audio- und Video-Plugins unterstützte. Dass dabei die Arbeit des W3C an HTML 4 komplett ignoriert wurde, interessierte dabei nur wenig. Gleichzeitig versuchte Microsoft mit aller Macht, wieder Boden gutzumachen. Microsoft übernahm selbst die Rolle, das object-Element zu unterstützen, das das W3C für die Einbindung von Multimedia-Plugins vorgesehen hatte. Die Nachzügler wurden kalt erwischt. Da Netscapes Browser überall waren, konzentrierten sich Mozilla und Apple darauf, dem Rest der Bevölkerung die beste Unterstützung für die Einbindung über das embed-Element zu ermöglichen. Diese Wahl konnte selbst von Microsofts späterem Marktanteil nicht wieder rückgängig gemacht werden. Eine ausführliche Diskussion zur Verwendung von Plugin-Markup finden Sie in Kapitel 11. Das Urteil: Um mit späteren Browsern kompatibel zu bleiben, sollte object auf jeden Fall Vorrang vor embed haben. Wenn Sie die Wahl haben, verzichten Sie ganz auf den Einsatz von embed. Mittlerweile wird object so gut unterstützt, dass es in allen wahrscheinlichen Anwendungsszenarien als zuverlässig gilt.
Formularelemente, Plugins und der Stapelkontext Das Problem mit Plugin-Inhalten und Formularelementen besteht darin, dass sie unabhängig von absoluter Positionierung oder dem Wert für z-index »vor« allen anderen
Ein hässliches System
|
283
Elementen dargestellt werden. Dieses Problem ist zwar nicht mehr so dramatisch wie früher, kann aber immer wieder einmal auftreten. Diese ungewollte Prominenz von Formularelementen und Plugin-Inhalten hängt damit zusammen, wie diese Elemente vom Browser dargestellt werden. Oftmals werden diese Elemente nicht von der Rendering Engine des Browsers, sondern direkt von den entsprechenden Teilen des Betriebssystems eingefügt. Im Falle des Internet Explorers sind dies das .NET-Framework und ActiveX. Letzteres fügt object-Elemente in die Seite ein, als seien sie modale Eingabefenster. Dieses Problem ist fast schon ein »Awful Part«, weil diese Situation sich kaum lösen lassen. z-index hilft hier nicht weiter. Da hilft offenbar nur noch rohe Gewalt. Folgende Lösungen gibt es: • Überarbeiten Sie Ihr Layout, so dass es zu keinen Überschneidungen mit dem betreffenden Element kommt. • Platzieren Sie den obersten Inhalt in einem iframe, der im Quellcode nach dem störrischen Element definiert wird. Das Urteil: Dieses Problem ist im Internet Explorer deutlich schlimmer als in anderen Browsern. Wie bei vielen der IE-bezogenen schlechten Seite gibt es hierfür keine einfache Lösung, solange die Browserhersteller Ihre Software nicht anpassen.
Obskure Gründe für ungültiges Markup Der schlechteste Grund für nicht validierenden Markup-Code ist die falsche Verwendung des Ampersand-Zeichens (siehe Kapitel 13). Daneben gibt es aber noch weit frustrierendere Gründe. Mein Lieblingsbeispiel für die seltsamen Anforderungen von HTML stammt aus dem Jahre 2002, als ich gerade als offizielles »Mädchen für alles« bei Webstandards.org zu arbeiten begann. Ich verfasste gerade im Blog der Website eine Antwort auf eine eingegangene E-Mail und wollte die Seite nur noch kurz validieren. Die Seite validierte nicht und der »obskure Grund« zeigte sich. Webstandards.org verwendet für die Validierung einen DOCTYPE vom Typ Strict. Mein Artikel enthielt ein blockquote-Element. Was ich nicht wusste (ich bevorzugte Dokumente mit dem Typ Transitional), war, dass blockquote bei der Verwendung von Strict mindestens ein Blockelement enthalten muss, um gültig zu sein, zum Beispiel einen Absatz oder ein div-Element. Ein weiteres seltsames Validierungsproblem trat auf, als dieses Buch von den technischen Sachverständigen begutachtet wurde. Damit ein Dokument gültig ist, müssen die Elemente thead und tfoot im Quellcode vor tbody erscheinen und nicht erst danach. Diese und andere seltsamen Anforderungen finden Sie zusammengefasst in einem Diagramm auf der Website zu diesem Buch. 284
|
Kapitel 14: Die schlechten Seiten
Das Urteil: Sobald Sie es auf sich nehmen, gültigen Markup-Code zu schreiben, bekommen Sie es mit einigen sehr seltsamen Anforderungen zu tun. Hierzu gehören Einschränkungen für Kind-, Eltern- und Nachkommenelemente, Attribute, Werte und Inhalte. Regen Sie sich nicht darüber auf – bringen Sie es einfach in Ordnung.
Sackgassen und die bösen Nachbarn von HTML HTML ist in seiner heutigen Form mittlerweile 20 Jahre alt und war ursprünglich dazu gedacht, akademische Aufsätze und anderes geschriebenes Material auszutauschen. Den ganzen Zirkus um Flash, Ajax, Podcasts und soziale Medien konnte sich damals niemand vorstellen. Als Ergebnis wurde die Sprache nach und nach um neue Merkmale erweitert. Bis Ende 1997 konnte man den »offiziellen« Status der gegenwärtigen Erweiterungen bestenfalls als provisorisch bezeichnen. Im Laufe der Evolution von HTML, der zugrunde liegenden Infrastruktur, über die die Inhalte übertragen werden, und der Benutzererwartungen haben sich eine Menge Dinge angesammelt, die zu ihrer Zeit noch sinnvoll erschienen. Sie finden diese verkümmerten Reste im Abschnitt »Die furchtbaren Seiten« auf Seite 296. Zu den Teilen, die gelegentlich sogar nützlich sein können, kommen wir jetzt.
Frames Die Frameset-DTD bezieht sich auf zwei Elemente, die 1996 groß in Mode waren, heutzutage aber schnell peinlich wirken können: frameset und frame. frameset ist ein Ersatz für das body-Element. Es kann die Attribute rows und cols enthalten. Jede der Zeilen und Spalten bezieht sich auf ein bestimmtes frame-Element im
Dokument. Die Werte werden als Pixel- oder Prozentwerte angegeben. Mehrfache Werte werden als kommagetrennte Liste definiert. Jedes der frame-Elemente besitzt ein src-Attribut, das definiert, welches Dokument im betreffenden Frame angezeigt werden soll. Das abhängige Dokument kann hierbei entweder eine typische HTML-Seite oder ein weiteres Frameset sein. Zudem kann jedem Frame ein name-Attribut zugewiesen werden. Wird dieser Wert im Attribut target eines Links angegeben, wird das Dokument, auf das der Link verweist, im Frame mit diesem Namen angezeigt. Auf diese Weise konnte der Inhalt eines Frames den Inhalt eines anderen Frames verändern. Eine grafische Darstellung eines verschachtelten Framesets und der eingebundenen Dokumente sehen Sie in Abbildung 14-1.
