Das Beste an HTML & CSS: Best Practices für standardkonformes Webdesign 3897216175, 9783897216174


237 75 5MB

German Pages 360 Year 2010

Report DMCA / Copyright

DOWNLOAD PDF FILE

Table of contents :
Buchcover......Page 1
Das Beste an HTML & CSS: Best Practices für standardkonformes Webdesign......Page 5
ISBN 13 978-3-89721-617-4......Page 6
Inhalt......Page 7
Was ist das Beste an HTML und CSS......Page 17
Der ideale Leser......Page 18
Eine Warnung zum Thema (mangelnde) Kenntnis......Page 19
Ziele dieses Buches......Page 20
Was Sie nicht in diesem Buch finden......Page 21
Über Webstandards......Page 23
Nomenklatur......Page 24
»Read the Source, Luke!«......Page 26
Die Verwendung der Codebeispiele......Page 27
Danksagungen......Page 28
Das Web ohne Links......Page 31
URIs......Page 32
Den Anwenderkomfort durch Links verbessern......Page 33
Herausforderungen bei der Implementierung von Hypertext......Page 34
HTML-Syntax......Page 37
Tags, Elemente und Attribute......Page 38
Darstellungsmodi, Varianten von HTML und Dokumenttyp-Deklarationen......Page 40
Strict, Transitional oder Frameset?......Page 41
Die Geschichte der zwei Boxmodelle......Page 42
Die schönen Seiten: universelle Attribute......Page 43
Stylesheet-Anweisungen per »class« und »id« einbinden......Page 44
Inhalt beschreiben mit »title« und »lang«......Page 45
Das Attribut »contenteditable« in HTML 5......Page 46
Die Trennung von Inhalt, Strukur, Präsentation und Verhalten......Page 47
Mit Dokumentenbäumen arbeiten......Page 48
Browser, Parsing und Rendering......Page 50
Dynamisches HTML, Ajax und Rendering......Page 51
Ein Stylesheet per »link«-Element einbinden......Page 53
Conditional Comments zum Ansprechen verschiedener Versionen des Internet Explorers......Page 54
Die Verwendung von »@import«......Page 55
Regeln für bestimmte Medientypen......Page 56
Eltern, Kinder und Geschwister: Beziehungen zwischen Elementen......Page 58
Einfache Selektoren......Page 59
Gruppierte Selektoren und Selektoren für Nachfahrenelemente......Page 60
Priorität der Selektoren......Page 61
Regelkonflikte vermeiden......Page 62
Vererbte Werte......Page 63
Medienübergreifende Längen- und Maßeinheiten......Page 64
Pixelwerte und Punktdichte......Page 65
Druckfreundliche Längeneinheiten......Page 66
Farbwerte......Page 67
Die wichtigsten CSS-Eigenschaften für das Layout......Page 68
Viele Standards fürs Web......Page 71
Wozu Webstandards?......Page 72
Zugänglichkeit......Page 73
Altlasten als Bremse......Page 74
Der Mittelweg: Standardfreundlichkeit......Page 75
Die Regeln für standardfreundliche Entwicklung......Page 76
Die vier wichtigsten Angewohnheiten für effektive Stylesheets......Page 79
Angewohnheit 1: In der Kürze liegt die Würze......Page 80
Schlichtheit bei sehr großen Sites......Page 82
Angewohnheit 2: Flexibilität......Page 83
Flexibilität, eigene Bibliotheken und die Wiederverwendung von Code......Page 84
Angewohnheit 3: Konsistenz......Page 85
Konsistenz durch Template-Verwaltung......Page 87
Angewohnheit 4: Auf Kurs bleiben......Page 88
Produktdokumentation als »Kompass«......Page 89
Die Funktionsprinzipien des CSS-Zen......Page 90
Informationsarchitektur und Usability des Webs......Page 91
Mehrdimensionalität......Page 92
Navigation: Ortsbestimmung und Orientierungshilfen......Page 94
Besucherstrategien......Page 95
Richtlinien für die Erstellung benutzbarer Schnittstellen......Page 96
Links auf das aktuelle Element deaktivieren......Page 97
Szenarios und Benutzertests zur Vorhersage von Besucherverhalten......Page 98
Taxonomie und Nomenklatur......Page 99
Taxonomie auf die Kaskade anwenden......Page 100
Neue Strukturelemente (HTML 5)......Page 103
Das CSS-Boxmodell und die Größe von Elementen......Page 105
auto-Werte......Page 106
Die Eigenschaft »overflow«......Page 107
Länge und Breite für Elemente anstelle expliziter Werte nur begrenzen......Page 109
Mit Unwägbarkeiten umgehen......Page 110
Negative Außenabstände......Page 111
Zusammengefasste Außenabstände......Page 112
Rahmen......Page 113
Das Box-Verhalten der Wurzelelemente des Dokuments......Page 114
Darstellungsrollen......Page 115
Block-Elemente......Page 116
Das Flussverhalten eines Elements mit »display« ändern......Page 117
Die Eigenschaft »display«......Page 118
Das Verhalten von Floats......Page 119
Das »float«-Verhalten mit der Eigenschaft »clear« steuern......Page 120
Mehrspaltige Layouts implementieren......Page 121
Ein zweispaltiges Tabellen-Layout nach CSS portieren......Page 122
Die Regeln für das zweispaltige Layout......Page 124
Vorteile der Beschränkung von Layout-Anweisungen auf Stylesheets......Page 125
Zwei Spalten auf drei Spalten erweitern......Page 126
Semantisch leere Container für mehrspaltige Layouts......Page 128
Wie die Positionierung funktioniert......Page 129
Positionierte Elemente begrenzen......Page 131
Stapelung......Page 133
Die Liste ausrichten......Page 135
Navigationslisten genau platzieren......Page 136
Feste, proportionale und flexible Layouts......Page 138
Hilfslinien definieren......Page 141
Die Drittelregel, der Goldene Schnitt und die Fibonacci-Folge......Page 143
Implementierung eines flexiblen Layoutrasters......Page 144
Browser-Standarddarstellung für geordnete und ungeordnete Listen......Page 147
Die Eigenschaft »list-style-type« und das Attribut »type«......Page 148
Das »nav«-Element (HTML 5)......Page 149
Überlegungen zu Zugänglichkeit und Usability......Page 150
Kürzere Wellenlängen......Page 151
Aufzählungen......Page 152
Aufzählungszeichen als Hintergrundbild?......Page 153
Platzierung der primären Navigation in der Quellcode-Reihenfolge......Page 154
Rezept für die primäre Navigation......Page 155
Rezept für die Navigation im Fußteil......Page 156
Stile für Definitionslisten......Page 157
Wörterbuch-Beispiel......Page 158
Beispiel für einen Dialog......Page 160
Überschriften und gutes Schreiben......Page 163
Gedruckte Überschriften......Page 164
Größe und Schriftart......Page 165
Die Größen von Überschriften anpassen......Page 166
Link-Attribute......Page 167
Virtuose Verwendung des »href«-Attributs......Page 168
Effektiver Inhalt für Links und Werte für das »title«-Attribut......Page 169
Pseudoklassen für Links......Page 171
Mit »display: block« den anklickbaren Bereich von Links vergrößern......Page 172
Die Eigenschaft »text-decoration«......Page 173
Semantische Bedeutung durch Inline-Elemente......Page 174
Zitate......Page 176
Farbenlehre und Webfarben......Page 177
Usability, Zugänglichkeit und Farbe......Page 178
Das subtraktive Farbmodell......Page 179
Design, Kontrast und Komplementärfarben......Page 180
Farben identifizieren, Kurzfassung......Page 181
Monitore und die »websichere« Farbpalette......Page 183
Eigene Farbpaletten erstellen......Page 184
Die richtigen Werte für »background-position«......Page 185
Hintergrundbilder erstellen......Page 187
»Faux Columns«......Page 188
Gekachelte Hintergrundtexturen und -muster......Page 190
Größere Hintergrundtexturen und nicht wiederholte Embleme......Page 191
Grafische Schriften und das Fahrner Image Replacement......Page 192
Nachteile der FIR-Methode......Page 194
Die Serverlast mit Sprites verringern......Page 195
Quellcode-Reihenfolge: Die Quadratur des Kreises......Page 197
Die unvermeidliche Abhängigkeit von Templates......Page 198
Bestandteile einer Datentabelle......Page 199
Beispiel: Die volle Packung Tabellen-Markup......Page 200
Tabellenzellen anlegen......Page 203
Tabellen- und Datenanordnung......Page 204
Tabellenkopf- und -fußteil und ihre Zellen......Page 206
Attribute und Kindselektoren......Page 207
Den Kontrast für Kopf- und Fußteil reduzieren......Page 208
Rollover-Effekte für Tabellen......Page 209
Ersetzte Elemente......Page 211
Bilder vorbereiten......Page 212
Bildgrößen und Rahmen......Page 213
Beschneiden......Page 214
»Matting«: Ein virtuelles Passepartourt......Page 215
Skalieren: Die absolute Bildgröße ändern......Page 216
Tonwert und Kontrast anpassen......Page 217
Mit Farbprofilen arbeiten......Page 219
Die goldene Mitte zwischen Dateigröße und Bildqualität......Page 221
Bilder richtig ordnen......Page 222
Bilder mit einem CMS verwalten und veröffentlichen......Page 223
Etikette beim Veröffentlichen von Bildern......Page 224
Bildbeschriftungen......Page 225
Vorschaubilder für Galerien und Diaschauen (Slideshows)......Page 227
Lightbox: Vorschaubilder, Galerien und Diaschauen......Page 228
SlideShowPro......Page 229
Integration von Videos und Präsentationen im Flash-Format mit SWFObject......Page 230
Multimediadaten integrieren......Page 231
Flash als möglicher Ausweg......Page 232
Probleme mit Stilen für Plugin-Inhalte......Page 233
Eine offene Haltung bewahren......Page 234
Unterstützung für alternative Videoformate......Page 235
Die »CanvasRenderingContext2D«-API......Page 236
SVG als Alternative zu »canvas«......Page 237
Eine kurze Geschichte der Schrift......Page 239
Gutenbergs Druckerpresse und die Kunst der Typografie......Page 240
Verschiedene Beschränkungen, aber keine veränderten Erwartungen......Page 241
Ein kurzes Glossar der Typografie......Page 242
Schriftenglättung: Aliasing und Anti-Aliasing......Page 245
Stildefinitionen zum Erhöhen der Erkennbarkeit......Page 248
Der »Knick« und kleine Schriften......Page 249
Die richtigen Längeneinheiten für Schriftgrößen......Page 251
Berechnung der Werte für em-Einheiten und Prozentangaben......Page 252
Das Problem der geringen Auswahl......Page 253
Eigene Schriften definieren: Die Eigenschaft »font-family«......Page 256
Die richtigen Schriftnamen finden......Page 257
Überblick über die Zeichenkodierung......Page 259
ASCII, ISO 8859-1, Unicode und UTF-8......Page 260
Das richtige Kodierungsschema wählen......Page 261
Zeichen-Entities zur Definition von Nicht-ASCII-Zeichen......Page 262
Ausgewogene Schriftgestaltung......Page 264
Die Grenzen von Inhalten ermitteln......Page 265
Schrift unterscheiden: Schriftschnitt, Größe, Gewicht, Stil und Farbe......Page 266
Das »Überlaufen« von Text verhindern......Page 268
Stile für Textpassagen mit gleicher Priorität......Page 269
Verschiedene typografische Aspekte von CSS......Page 270
Die Eigenschaften »font-variant« und »text-transform«......Page 271
Gute Webtypografie in der Praxis......Page 272
Webapplikationen, Benutzerperspektive und Design-Entscheidungen......Page 273
Benutzerschnittstellen nach Funktion ordnen......Page 274
Zehn Regeln für effektive Webformulare und -applikationen......Page 275
Einschätzung und Struktur......Page 277
Anforderungen ermitteln......Page 278
Markup und Struktur......Page 280
Grundsätzliche Struktur, Darstellung und Verhalten von Formularen......Page 283
Vom Formular ausgelöste GET-Requests......Page 284
Die Größe und das Aussehen einzelner Formularelemente anpassen......Page 286
Das Einmaleins des Prototyping......Page 288
Design-Templates, Grundstile und Formular-Layout......Page 289
Einheitliche Gestaltung von gleichen Formularelementen......Page 291
Erforderliche Formularfelder und Eingabeformate......Page 292
Erforderliche Felder hervorheben......Page 293
Eingabefehler aufspüren und identifizieren......Page 294
Zugängliche Formulare erstellen......Page 295
Zugängliche Formulare implementieren......Page 296
Formulare über die Tastatur steuern......Page 298
Neue Eingabeelemente......Page 299
Das Attribut »required«......Page 300
Die schlechten Manieren des Internet Explorers (speziell IE 6)......Page 303
Browserkrieg 2.0......Page 304
Fehlende oder schlechte Unterstützung für Selektoren......Page 305
»hasLayout«......Page 306
»expression()«-Werte......Page 307
PNG-Unterstützung (oder ihr Fehlen)......Page 308
Probleme mit XHTML und XML......Page 309
Markup-Validierung als Voraussetzung für korrekte Stylesheet-Implementierung......Page 310
Abgestufte Unterstützung......Page 311
Formularelemente, Plugins und der Stapelkontext......Page 313
Obskure Gründe für ungültiges Markup......Page 314
Frames......Page 315
Das Attribut »name«......Page 317
Semantische Verrenkungen und der begrenzte Wortschatz von HTML......Page 318
Präsentationselemente und wie Sie sie vermeiden......Page 319
CSS-Travestien......Page 320
Berechnete Werte und Rundungsunterschiede......Page 321
Der Wert »inherit«......Page 322
Dinge verstecken: »z-index« und »clip«......Page 323
Regeln für den Fluss der Elemente......Page 324
Unicode-Werte und die Eigenschaft »content«......Page 325
Eigenschaften der Benutzeroberfläche (IE)......Page 326
Div-itis......Page 327
Attribute für Event-Handler......Page 328
Das Attribut »http-equiv«......Page 329
Das Puzzle wieder zusammensetzen......Page 330
Anhang – URIs, Client-Server-Architektur und HTTP......Page 331
Glossar......Page 337
Index......Page 343
Recommend Papers

Das Beste an HTML & CSS: Best Practices für standardkonformes Webdesign
 3897216175, 9783897216174

  • 0 0 0
  • Like this paper and download? You can publish your own PDF file online for free in a few minutes! Sign Up
File loading please wait...
Citation preview

Effizientes Design, sauberer Code

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.

Inhalt

Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XV 1 Hypertext von innen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Das Web ohne Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . URIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mit Links umgehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Den Anwenderkomfort durch Links verbessern . . . . . . . . . . Herausforderungen bei der Implementierung von Hypertext

1

.............

1

.............

2

.............

3

.............

3

.............

4

2 Mit HTML-Markup arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

HTML-Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tags, Elemente und Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Seitenstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Darstellungsmodi, Varianten von HTML und Dokumenttyp-Deklarationen HTML oder XHTML? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Strict, Transitional oder Frameset? . . . . . . . . . . . . . . . . . . . . . . . . . . . . Die Geschichte der zwei Boxmodelle . . . . . . . . . . . . . . . . . . . . . . . . . . Der richtige Dokumenttyp für Ihr Projekt . . . . . . . . . . . . . . . . . . . . . . . Die schönen Seiten: universelle Attribute . . . . . . . . . . . . . . . . . . . . . . . . . Stylesheet-Anweisungen per »class« und »id« einbinden . . . . . . . . . . . . Inhalt beschreiben mit »title« und »lang« . . . . . . . . . . . . . . . . . . . . . . . Das Attribut »contenteditable« in HTML 5 . . . . . . . . . . . . . . . . . . . . . . Die Trennung von Inhalt, Strukur, Präsentation und Verhalten . . . . . . . . . Die Trennung in der Praxis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mit Dokumentenbäumen arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . Browser, Parsing und Rendering. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dynamisches HTML, Ajax und Rendering . . . . . . . . . . . . . . . . . . . . . .

....

7

....

8

....

10

....

10

....

11

....

11

....

12

....

13

....

13

....

14

....

15

....

16

....

17

....

18

....

18

....

20

....

21

|

V

3 CSS-Überblick

................................................

23

Stylesheets und HTML-Dokumente verbinden . . . . . . . . . . . . . . . . . . . . . . . . . Ein Stylesheet per »link«-Element einbinden . . . . . . . . . . . . . . . . . . . . . . . . . Conditional Comments zum Ansprechen verschiedener Versionen des Internet Explorers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . »link« durch »style« ersetzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Die Verwendung von »@import« . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Finger weg vom »style«-Attribut! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Regeln für bestimmte Medientypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Selektoren für Elemente, die mit Stilen versehen werden sollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Eltern, Kinder und Geschwister: Beziehungen zwischen Elementen . . . . . . . . Einfache Selektoren. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gruppierte Selektoren und Selektoren für Nachfahrenelemente . . . . . . . . . . . Kindelemente direkt auswählen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Regelkonflikte, Priorität und Präzedenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Priorität der Selektoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Regelkonflikte vermeiden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vererbte Werte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Untersuchung von CSS-Eigenschaften und -Werten . . . . . . . . . . . . . . . . . . . . . . CSS-Maßeinheiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Medienübergreifende Längen- und Maßeinheiten . . . . . . . . . . . . . . . . . . . . . Pixelwerte und Punktdichte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Druckfreundliche Längeneinheiten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Schriftgrößen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Farbwerte. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Die wichtigsten CSS-Eigenschaften für das Layout . . . . . . . . . . . . . . . . . . . . . . .

23 23 24 25 25 26 26 28 28 29 30 31 31 31 32 33 34 34 34 35 36 37 37 38

4 Eine gesunde Beziehung zu den Webstandards entwickeln . . . . . . . . . . . . . 41 Viele Standards fürs Web . . . . . . Wozu Webstandards? . . . . . . . . . Interoperabilität . . . . . . . . . . . Die Kräfte des Marktes . . . . . . Vorwärtskompatibilität . . . . . . Zugänglichkeit . . . . . . . . . . . . Prioritäten der Hersteller . . . . . Altlasten als Bremse . . . . . . . . Best Practices (und ihr Fehlen) . Strikte Gesetzesauslegung . . . . VI

|

Inhalt

..................................

41

..................................

42

..................................

43

..................................

43

..................................

43

..................................

43

..................................

44

..................................

44

..................................

45

..................................

45

Der Mittelweg: Standardfreundlichkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vorteile der Standardfreundlichkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Die Regeln für standardfreundliche Entwicklung . . . . . . . . . . . . . . . . . . . . . .

45 46 46

5 Effektive Stylesheets und Dokumentenstrukturen . . . . . . . . . . . . . . . . . . . . 49 Die vier wichtigsten Angewohnheiten für effektive Stylesheets . . . . . . Angewohnheit 1: In der Kürze liegt die Würze . . . . . . . . . . . . . . . Angewohnheit 2: Flexibilität . . . . . . . . . . . . . . . . . . . . . . . . . . . . Angewohnheit 3: Konsistenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . Angewohnheit 4: Auf Kurs bleiben . . . . . . . . . . . . . . . . . . . . . . . . CSS-Zen und die Erfahrung des Gestalters . . . . . . . . . . . . . . . . . . . . Die Funktionsprinzipien des CSS-Zen . . . . . . . . . . . . . . . . . . . . . Informationsarchitektur und Usability des Webs . . . . . . . . . . . . . . . . Mehrdimensionalität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Navigation: Ortsbestimmung und Orientierungshilfen . . . . . . . . . Besucherstrategien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Richtlinien für die Erstellung benutzbarer Schnittstellen . . . . . . . . Szenarios und Benutzertests zur Vorhersage von Besucherverhalten Taxonomie und Nomenklatur . . . . . . . . . . . . . . . . . . . . . . . . . . . Taxonomie auf die Kaskade anwenden . . . . . . . . . . . . . . . . . . . . . Neue Strukturelemente (HTML 5) . . . . . . . . . . . . . . . . . . . . . . . .

6 Lösungen für das CSS-Layout-Puzzle

........

49

........

50

........

53

........

55

........

58

........

60

........

60

........

61

........

62

........

64

........

65

........

66

........

68

........

69

........

70

........

73

..............................

75

Das CSS-Boxmodell und die Größe von Elementen . . . . . . . . . . . . . . . . . Quirks Mode und Strict Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . auto-Werte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Die Eigenschaft »overflow« . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Länge und Breite für Elemente anstelle expliziter Werte nur begrenzen . Mit Unwägbarkeiten umgehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rahmen, Innen- und Außenabstände . . . . . . . . . . . . . . . . . . . . . . . . . . . Negative Außenabstände . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Zusammengefasste Außenabstände . . . . . . . . . . . . . . . . . . . . . . . . . . Rahmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Innenabstände . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Das Box-Verhalten der Wurzelelemente des Dokuments . . . . . . . . . . . Längenangaben für Box-Eigenschaften und Prozentwerte. . . . . . . . . . . Darstellungsrollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Inline-Elemente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Block-Elemente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

.....

75

.....

76

.....

76

.....

77

.....

79

.....

80

.....

81

.....

81

.....

82

.....

83

.....

84

.....

84

.....

85

.....

85

.....

86

.....

86

Inhalt

|

VII

Inline-Block-Elemente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Das Flussverhalten eines Elements mit »display« ändern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Die Eigenschaft »display« . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Die Eigenschaften »float« und »clear« . . . . . . . . . . . . . . . . . . . . . . . . . . . Das Verhalten von Floats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Das »float«-Verhalten mit der Eigenschaft »clear« steuern . . . . . . . . . . »float«-Kontext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mehrspaltige Layouts implementieren . . . . . . . . . . . . . . . . . . . . . . . . . . Ein zweispaltiges Tabellen-Layout nach CSS portieren . . . . . . . . . . . . . Die Regeln für das zweispaltige Layout . . . . . . . . . . . . . . . . . . . . . . . . Vorteile der Beschränkung von Layout-Anweisungen auf Stylesheets . . Zwei Spalten auf drei Spalten erweitern . . . . . . . . . . . . . . . . . . . . . . . Mehr als drei Spalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Semantisch leere Container für mehrspaltige Layouts . . . . . . . . . . . . . Fortgeschrittenes Layout mit CSS 3 . . . . . . . . . . . . . . . . . . . . . . . . . . CSS-Eigenschaften für die Positionierung . . . . . . . . . . . . . . . . . . . . . . . . Wie die Positionierung funktioniert . . . . . . . . . . . . . . . . . . . . . . . . . . Positionierte Elemente begrenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . Die Eigenschaften »visibility« und »z-index« . . . . . . . . . . . . . . . . . . . . . . Ändern der Sichtbarkeit ohne Auswirkungen auf den Dokumentenfluss Stapelung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Quellcode-Reihenfolge und präzises Layout für die Navigation . . . . . . . . . Die Liste ausrichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Navigationslisten genau platzieren . . . . . . . . . . . . . . . . . . . . . . . . . . . Layouttypen und Hilfslinien-Raster . . . . . . . . . . . . . . . . . . . . . . . . . . . . Feste, proportionale und flexible Layouts . . . . . . . . . . . . . . . . . . . . . . Hilfslinien definieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Die Drittelregel, der Goldene Schnitt und die Fibonacci-Folge . . . . . . . Implementierung eines flexiblen Layoutrasters . . . . . . . . . . . . . . . . . .

7 Listen

|

87

.....

87

.....

88

.....

89

.....

89

.....

90

.....

91

.....

91

.....

92

.....

94

.....

95

.....

96

.....

98

.....

98

.....

99

.....

99

.....

99

.....

101

.....

103

.....

103

.....

103

.....

105

.....

105

.....

106

.....

108

.....

108

.....

111

.....

113

.....

114

......................................................

117

Geordnete und ungeordnete Listen . . . . . . . . . . . . . . . . . . . . . . . . . . Browser-Standarddarstellung für geordnete und ungeordnete Listen . Gültige geordnete und ungeordnete Listen erstellen. . . . . . . . . . . . . Die Eigenschaft »list-style-type« und das Attribut »type« . . . . . . . . . Das »nav«-Element (HTML 5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . Die Zählweise in geordneten Listen anpassen . . . . . . . . . . . . . . . . .

VIII

.....

Inhalt

.......

117

.......

117

.......

118

.......

118

.......

119

.......

121

Andere Verwendungen für Listen . . . . . . . . . . . . . . . . . . . . . . . . . . . Gliederungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Aufzählungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Das Layout für Links im Fußteil anpassen . . . . . . . . . . . . . . . . . . Aufzählungszeichen als Hintergrundbild? . . . . . . . . . . . . . . . . . . . Stile für Navigationselemente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Platzierung der primären Navigation in der Quellcode-Reihenfolge. Rezept für die primäre Navigation . . . . . . . . . . . . . . . . . . . . . . . . Rezept für die Navigation im Fußteil . . . . . . . . . . . . . . . . . . . . . . Definitionslisten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Stile für Definitionslisten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wörterbuch-Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Beispiel für einen Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

........

122

........

122

........

122

........

123

........

123

........

124

........

124

........

125

........

126

........

127

........

127

........

128

........

130

8 Überschriften, Hyperlinks, Inline-Elemente und Zitate . . . . . . . . . . . . . . . . . 133 Überschriften und gutes Schreiben . . . . . . . . . . . . . . . . . . . . . . . . . . . Gedruckte Überschriften . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Optimale Platzierung für Überschriften . . . . . . . . . . . . . . . . . . . . . Stile für Überschriften . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Größe und Schriftart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Die Größen von Überschriften anpassen . . . . . . . . . . . . . . . . . . . . . Überschriften hervorheben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Markup für Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Link-Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Virtuose Verwendung des »href«-Attributs . . . . . . . . . . . . . . . . . . . Links auf bestimmte Teile eines Dokuments . . . . . . . . . . . . . . . . . . Effektiver Inhalt für Links und Werte für das »title«-Attribut . . . . . . Stildefinitionen für Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pseudoklassen für Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mit »display: block« den anklickbaren Bereich von Links vergrößern Die Eigenschaft »text-decoration« . . . . . . . . . . . . . . . . . . . . . . . . . Die Eigenschaft »cursor« . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Semantische Bedeutung durch Inline-Elemente . . . . . . . . . . . . . . . . . . Zitate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

.......

133

.......

134

.......

135

.......

135

.......

135

.......

136

.......

137

.......

137

.......

137

.......

138

.......

139

.......

139

.......

141

.......

141

.......

142

.......

143

.......

144

.......

144

.......

146

9 Farben und Hintergründe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 Farbenlehre und Webfarben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 Usability, Zugänglichkeit und Farbe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 Das additive Farbmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 Inhalt

|

IX

Das HSB-Farbmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Das subtraktive Farbmodell . . . . . . . . . . . . . . . . . . . . . . . . . . Design, Kontrast und Komplementärfarben . . . . . . . . . . . . . . Farben identifizieren, Kurzfassung . . . . . . . . . . . . . . . . . . . . . Monitore und die »websichere« Farbpalette . . . . . . . . . . . . . . Eigene Farbpaletten erstellen . . . . . . . . . . . . . . . . . . . . . . . . . CSS-Hintergründe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Die richtigen Werte für »background-position« . . . . . . . . . . . . Die CSS-Kurzschrift-Eigenschaft »background« . . . . . . . . . . . . Hintergrundbilder erstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . »Faux Columns«. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gekachelte Hintergrundtexturen und -muster . . . . . . . . . . . . . Größere Hintergrundtexturen und nicht wiederholte Embleme Schattenwürfe, Gel-Effekte und abgerundete Ecken . . . . . . . . . Grafische Schriften und das Fahrner Image Replacement . . . . . . . Die FIR-Stylesheet-Regeln . . . . . . . . . . . . . . . . . . . . . . . . . . . Nachteile der FIR-Methode . . . . . . . . . . . . . . . . . . . . . . . . . . Die Serverlast mit Sprites verringern . . . . . . . . . . . . . . . . . . . . . .

...........

149

...........

149

...........

150

...........

151

...........

153

...........

154

...........

155

...........

155

...........

157

...........

157

...........

158

...........

160

...........

161

...........

162

...........

162

...........

164

...........

164

...........

165

10 (Daten-)Tabellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Nachteile von Layout-Tabellen . . . . . . . . . . . . . . . . Quellcode-Reihenfolge: Die Quadratur des Kreises Vom CSS-Zen bleibt nur ein Mythos . . . . . . . . . . Die unvermeidliche Abhängigkeit von Templates . Positionierung ist bei Tabellen-Layouts wertlos . . . Bestandteile einer Datentabelle. . . . . . . . . . . . . . . . . Beispiel: Die volle Packung Tabellen-Markup . . . . Tabellenzellen anlegen . . . . . . . . . . . . . . . . . . . . . . Tabellen- und Datenanordnung . . . . . . . . . . . . . . Tabellenkopf- und -fußteil und ihre Zellen . . . . . . . . Attribute und Kindselektoren . . . . . . . . . . . . . . . Den Kontrast für Kopf- und Fußteil reduzieren . . . Rollover-Effekte für Tabellen . . . . . . . . . . . . . . . .

....................

167

....................

167

....................

168

....................

168

....................

169

....................

169

....................

170

....................

173

....................

174

....................

176

....................

177

....................

178

....................

179

11 Bilder und Multimedia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Ersetzte Elemente . . . . . . . . Bilder vorbereiten . . . . . . . . Das »alt«-Attribut . . . . . . Bildgrößen und Rahmen . X

|

Inhalt

......................................

181

......................................

182

......................................

183

......................................

183

Bilder erstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Beschneiden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . »Matting«: Ein virtuelles Passepartourt . . . . . . . . . . . . . . . . . . . . . . . . . . Skalieren: Die absolute Bildgröße ändern . . . . . . . . . . . . . . . . . . . . . . . . Tonwert und Kontrast anpassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mehrere Anpassungen auf einmal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mit Farbprofilen arbeiten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bildoptimierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Das richtige Dateiformat wählen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Die goldene Mitte zwischen Dateigröße und Bildqualität . . . . . . . . . . . . . Bilder veröffentlichen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bilder richtig ordnen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bilder mit einem CMS verwalten und veröffentlichen . . . . . . . . . . . . . . . Etikette beim Veröffentlichen von Bildern . . . . . . . . . . . . . . . . . . . . . . . . Stile für Bilder und Plugin-Inhalte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bildlayout innerhalb einer Spalte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bildbeschriftungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vorschaubilder für Galerien und Diaschauen (Slideshows) . . . . . . . . . . . . Lightbox: Vorschaubilder, Galerien und Diaschauen . . . . . . . . . . . . . . . . SlideShowPro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Integration von Videos und Präsentationen im Flash-Format mit SWFObject Multimediadaten integrieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Die Geschichte dreier Firmen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Flash als möglicher Ausweg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Multimedia-Inhalte mit reinem Markup einbinden . . . . . . . . . . . . . . . . . Probleme mit Stilen für Plugin-Inhalte . . . . . . . . . . . . . . . . . . . . . . . . . . Plugin-Probleme mit dem HTTP-Header »Content-Disposition« umgehen Eine offene Haltung bewahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Die Elemente »video« und »audio« (HTML 5). . . . . . . . . . . . . . . . . . . . . Das »canvas«-Element (HTML 5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

...

184

...

184

...

185

...

186

...

187

...

189

...

189

...

191

...

191

...

191

...

192

...

192

...

193

...

194

...

195

...

195

...

195

...

197

...

198

...

199

...

200

...

201

...

202

...

202

...

203

...

203

...

204

...

204

...

205

...

206

12 Web-Typografie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Eine kurze Geschichte der Schrift . . . . . . . . . . . . . . . . . . . . . . . . . . . . Die Herkunft moderner westlicher Buchstabenformen . . . . . . . . . . . Gutenbergs Druckerpresse und die Kunst der Typografie . . . . . . . . . Das Aufkommen des Digitalsatzes . . . . . . . . . . . . . . . . . . . . . . . . . Verschiedene Beschränkungen, aber keine veränderten Erwartungen Ein kurzes Glossar der Typografie . . . . . . . . . . . . . . . . . . . . . . . . . . . Schriftenglättung: Aliasing und Anti-Aliasing . . . . . . . . . . . . . . . . . . .

.......

209

.......

210

.......

210

.......

211

.......

211

.......

212

.......

215

Inhalt

|

XI

Schriftstile, Lesbarkeit und Erkennbarkeit . . . . . . . . . . . . . . . . . . . . . . . Stildefinitionen zum Erhöhen der Lesbarkeit . . . . . . . . . . . . . . . . . . . Stildefinitionen zum Erhöhen der Erkennbarkeit . . . . . . . . . . . . . . . . Der »Knick« und kleine Schriften . . . . . . . . . . . . . . . . . . . . . . . . . . . Schriftgrößen angeben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Die richtigen Längeneinheiten für Schriftgrößen . . . . . . . . . . . . . . . . Berechnung der Werte für em-Einheiten und Prozentangaben . . . . . . Schlüsselwörter für Schriftgrößen . . . . . . . . . . . . . . . . . . . . . . . . . . . Arbeit mit Schriften und Schriftschnitten . . . . . . . . . . . . . . . . . . . . . . . Das Problem der geringen Auswahl . . . . . . . . . . . . . . . . . . . . . . . . . Eigene Schriften definieren: Die Eigenschaft »font-family« . . . . . . . . . Die richtigen Schriftnamen finden . . . . . . . . . . . . . . . . . . . . . . . . . . Mit der Eigenschaft »font« auf Systemschriften zugreifen . . . . . . . . . . Überblick über die Zeichenkodierung . . . . . . . . . . . . . . . . . . . . . . . . . . Was ist Zeichenkodierung? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ASCII, ISO 8859-1, Unicode und UTF-8 . . . . . . . . . . . . . . . . . . . . . Das richtige Kodierungsschema wählen . . . . . . . . . . . . . . . . . . . . . . Zeichen-Entities zur Definition von Nicht-ASCII-Zeichen . . . . . . . . . Ausgewogene Schriftgestaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vorhersagbarkeit und Panik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Die Grenzen von Inhalten ermitteln . . . . . . . . . . . . . . . . . . . . . . . . . Schrift unterscheiden: Schriftschnitt, Größe, Gewicht, Stil und Farbe . Das »Überlaufen« von Text verhindern. . . . . . . . . . . . . . . . . . . . . . . Stile für Textpassagen mit gleicher Priorität . . . . . . . . . . . . . . . . . . . Schriftübersichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verschiedene typografische Aspekte von CSS . . . . . . . . . . . . . . . . . . . . Die Eigenschaft »line-height« . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Die Eigenschaften »font-variant« und »text-transform« . . . . . . . . . . . Die Eigenschaften »letter-spacing« und »word-spacing« . . . . . . . . . . . Die Eigenschaft »white-space« . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gute Webtypografie in der Praxis . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13 Saubere und zugängliche Formulare

|

Inhalt

218 218

......

218

......

219

......

221

......

221

......

222

......

223

......

223

......

223

......

226

......

227

......

229

......

229

......

230

......

230

......

231

......

232

......

234

......

235

......

235

......

236

......

238

......

239

......

240

......

240

......

241

......

241

......

242

......

242

......

242

..............................

243

Effektive Formulare erstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Webapplikationen, Benutzerperspektive und Design-Entscheidungen . Benutzerschnittstellen nach Funktion ordnen . . . . . . . . . . . . . . . . . . Zehn Regeln für effektive Webformulare und -applikationen . . . . . . . Einschätzung und Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Anforderungen ermitteln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XII

...... ......

......

243

......

243

......

244

......

245

......

247

......

248

Markup und Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Grundsätzliche Struktur, Darstellung und Verhalten von Formularen . . Vom Formular ausgelöste GET-Requests . . . . . . . . . . . . . . . . . . . . Die POST-Methode und das Hochladen von Dateien . . . . . . . . . . . Die Größe und das Aussehen einzelner Formularelemente anpassen . Prototyping und Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Das Einmaleins des Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . Design-Templates, Grundstile und Formular-Layout . . . . . . . . . . . . Einheitliche Gestaltung von gleichen Formularelementen. . . . . . . . . Erforderliche Formularfelder und Eingabeformate . . . . . . . . . . . . . . . . Erforderliche Felder hervorheben . . . . . . . . . . . . . . . . . . . . . . . . . . Eingabefehler aufspüren und identifizieren . . . . . . . . . . . . . . . . . . . Die Attribute »disabled« und »readonly« . . . . . . . . . . . . . . . . . . . . Zugängliche Formulare erstellen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Zugängliche Formulare implementieren . . . . . . . . . . . . . . . . . . . . . Formulare über die Tastatur steuern. . . . . . . . . . . . . . . . . . . . . . . . Neue Merkmale in HTML 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Neue Eingabeelemente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Das Attribut »required« . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

.......

250

.......

253

.......

254

.......

256

.......

256

.......

258

.......

258

.......

259

.......

261

.......

262

.......

263

.......

264

.......

265

.......

265

.......

266

.......

268

.......

269

.......

269

.......

270

14 Die schlechten Seiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 Die schlechten Manieren des Internet Explorers (speziell IE 6) Browserkrieg 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fehlende oder schlechte Unterstützung für Selektoren . . . . »hasLayout« . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verdoppelte Außenabstände: Der »Double Margin Bug« . . »expression()«-Werte . . . . . . . . . . . . . . . . . . . . . . . . . . . ActiveX-Filter, Transparenz und Farbverläufe . . . . . . . . . . PNG-Unterstützung (oder ihr Fehlen) . . . . . . . . . . . . . . . Schlecht unterstützte CSS-Eigenschaften . . . . . . . . . . . . . Probleme mit XHTML und XML . . . . . . . . . . . . . . . . . . . Ein hässliches System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Zerbrechliche Templates und Inhalte von Drittanbietern . . Markup-Validierung als Voraussetzung für korrekte Stylesheet-Implementierung. . . . . . . . . . . . . . . . . . . . . . . »Optimiert für …« . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Abgestufte Unterstützung . . . . . . . . . . . . . . . . . . . . . . . . »embed« oder »object« . . . . . . . . . . . . . . . . . . . . . . . . . . Formularelemente, Plugins und der Stapelkontext . . . . . . .

..............

273

..............

274

..............

275

..............

276

..............

277

..............

277

..............

278

..............

278

..............

279

..............

279

..............

280

..............

280

..............

280

..............

281

..............

281

..............

283

..............

283

Inhalt

|

XIII

Obskure Gründe für ungültiges Markup . . . . . . . . . . . . . . . . . . . . . . . Sackgassen und die bösen Nachbarn von HTML . . . . . . . . . . . . . . . . . . . Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Das Element »strike« . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Das Attribut »name« . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Die Elemente »noscript« und »noframes« . . . . . . . . . . . . . . . . . . . . . . Semantische Verrenkungen und der begrenzte Wortschatz von HTML . Präsentationselemente und wie Sie sie vermeiden . . . . . . . . . . . . . . . . Vertikalen Leerraum verändern: »hr« und »br« . . . . . . . . . . . . . . . . . . Das Element »pre« und die Eigenschaft »white-space« . . . . . . . . . . . . . CSS-Travestien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . @-Direktiven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Berechnete Werte und Rundungsunterschiede . . . . . . . . . . . . . . . . . . Herstellerspezifische Präfixe: »-moz« und »-webkit« . . . . . . . . . . . . . . Der Wert »inherit« . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dinge verstecken: »z-index« und »clip« . . . . . . . . . . . . . . . . . . . . . . . Zähler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Regeln für den Fluss der Elemente . . . . . . . . . . . . . . . . . . . . . . . . . . . Unicode-Werte und die Eigenschaft »content« . . . . . . . . . . . . . . . . . . Die furchtbaren Seiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Die Elemente »marquee« und »blink« . . . . . . . . . . . . . . . . . . . . . . . . . Eigenschaften der Benutzeroberfläche (IE) . . . . . . . . . . . . . . . . . . . . . Das Attribut »align« . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Das Attribut »style« . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Div-itis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Attribute für Event-Handler. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Überflüssige Unterstreichungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Das Attribut »http-equiv« . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Das Puzzle wieder zusammensetzen . . . . . . . . . . . . . . . . . . . . . . . . . . . .

.....

284

.....

285

.....

285

.....

287

.....

287

.....

288

.....

288

.....

289

.....

290

.....

290

.....

290

.....

291

.....

291

.....

292

.....

292

.....

293

.....

294

.....

294

.....

295

.....

296

.....

296

.....

296

.....

297

.....

297

.....

297

.....

298

.....

299

.....

299

.....

300

Anhang: URIs, Client-Server-Architektur und HTTP . . . . . . . . . . . . . . . . . . . . . . . 301 Glossar

........................................................

307

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313

XIV

|

Inhalt

Einleitung

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. class="alternativ Handlungsaufforderung". 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

{ { { {

width: auto; } width: 34.5em; } margin-right: 37.5em; } display: none; }

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:

...