Webdesign mit Webstandards

Der folgende Text ist eine Übersetzung von Developing With Web Standards von Roger Johansson.
Hinweis: Der Text beinhaltet viele Verweise auf weiterführende Quellen. Diese sind fast ausschließlich in englischer Sprache. In den Fällen, da ich für diese Dokumente eine deutsche Übersetzung kenne, habe ich sie in [eckigen Klammern] beigefügt (ebenso weitere Übersetzungsanmerkungen).
Falls sie für eine der Quellen eine Übersetzung oder eine gleichwertige deutsche Site kennen, würde ich mich über einen Hinweis freuen.

Einführung

Dieses Dokument erklärt, wie und warum die Berücksichtigung von Webstandards es ihnen ermöglicht, als Webdesigner Zeit und Geld zu sparen und ihren Besuchern bessere Websites zu bieten. Außerdem werden Methoden, Richtlinien und sinnvolle Techniken vorgestellt, die ihnen helfen werden, qualitativ hochwertige Websites zu erstellen, die so vielen Besuchern wie möglich zugänglich sind.

[Anm. d. Übers.: Im Englischen werden Web Standards getrennt geschrieben, während sich im Deutschen die Schreibweise in einem Wort (Webstandards) durchgesetzt hat.]

Geschichte

Als das Internet und das World Wide Web in der zweiten Hälfte der neunziger Jahre zu Mainstreammedien wurden, hatten die Browserhersteller CSS (Cascading Style Sheets) noch nicht so weit in ihre Software intergriert, dass Webdesigner diese Sprache zur visuellen Gestaltung ihrer HTML-Dokumente nutzen konnten. Diese fehlende Umsetzung von CSS in den Browsern ist teilweise nachvollziehbar wenn man bedenkt, dass die CSS Level 1 Spezifikation 1996, die CSS Level 2 Spezifikation 1998 veröffentlicht wurde.

Einerseits hatten die Browser große Defizite in der CSS-Unterstützung, andererseits waren Grafikdesigner aus den Printmedien ein hohes Maß an Kontrolle über die visuelle Erscheinung ihrer Produkte gewohnt und wollten diese auch für ihre Website umsetzen. Dies führte dazu, dass HTML auf jede erdenklich Art missbraucht wurde, um die optische Erscheinung von Websites zu kontrollieren. Ein Beispiel hierfür: als Designer entdeckten, dass man das Attribut border="0" verwenden konnte, um die Ränder von Tabellen unsichtbar zu machen, bedeutete das einen Durchbruch. Man konnte nun ein unsichtbares Raster für das Layout eines Dokuments erstellen. Ein weiteres Beispiel ist die Verwendung von transparenten und damit unsichtbaren gif-Grafiken (spacer gifs), um beispielsweise Abstände zu erzwingen.

Da HTML aber nie dazu gedacht war, die Darstellung eines Dokuments zu kontrollieren, wurden Hacks, nicht-valides Markup und herstellerspezifische HTML-Elemente (Tags) und Attribute verwendet. Die Validierung von Dokumenten war nur wenigen geläufig. „Tag-Suppe“ (tag soup) ist für das so entstandene Markup ein treffender Name.

Mit der Veröffentlichung neuer Browserversionen wurde die CSS-Unterstützung verbessert und erweitert, allerdings nicht so schnell wie es nötig gewesen wäre. Trotz dieser schleppenden Umsetzung haben wir inzwischen einen Punkt erreicht, an dem Webbrowser mit vernünftiger CSS-Unterstüztung von einer überwältigenden Mehrheit benutzt werden. Es gibt mithin keinen Grund mehr, HTML nicht so zu verwenden, wie es ursprünglich gedacht war: um die Struktur eines Dokuments und nicht seine Darstellung zu beschreiben. Für die visuelle Darstellung können wir nun Cascading Stylesheets (CSS) benutzen, die genau hierfür konzipiert wurden.

Webstandards

Was sind Webstandards?

Webstandards sind Technologien vom W3C oder anderen Standards-Organisationen bereitgestellte Technologien für die Erstellung und Darstellung webbasierter Inhalte. Diese Technologien haben das Ziel, die Nutzbarkeit von Dokumenten im Web auch in Zukunft sicherzustellen und diese Dokumente so vielen Nutzern wie möglich zugänglich zu machen.

Struktursprachen

• HTML (Hypertext Markup Language) 4.01
• XHTML (Extensible Hypertext Markup Language) 1.0
• XHTML 1.1
• XML (Extensible Markup Language) 1.0

Präsentationssprachen

• CSS (Cascading Style Sheets) Level 1
• CSS Level 2 revision 1
• CSS Level 3 (noch in der Entwicklung)
• MathML
• SVG

Objektmodelle

• DOM (Document Object Model) Level 1
• DOM Level 2
• DOM Level 3 Core

Skriptsprachen

• ECMAScript 262

Dieses Dokument behandelt hauptsächlich XHTML 1.0 Strict für die Struktur, CSS Level 1 und Level 2 für die Präsentation und ECMAScript 262 als Skriptsprache (allerdings wird es nicht allzuviele Skript-Beispiele geben).

Wenn ein Dokument auf der Grundlage von Webstandards erstellt ist, bedeutet das (abgesehen von der Verwendung der oben genannten Sprachen), dass es…

• … aus validem XHTML aufgebaut ist
• … CSS anstatt Tabellen für das Layout verwendet
• … sinnvoll strukturiert ist und semantisch korrektes Markup verwendet
• … in jedem Webbrowser funktioniert

Der letzte Punkt, „funktioniert in jedem Webbrowser“, bedeutet ausdrücklich nicht, „sieht in jedem Webbrowser gleich aus“. Ein Dokument so zu erstellen, dass es in jedem Webbrowser auf jedem Betriebssystem identisch aussieht, ist praktisch unmöglich. Nicht einmal, wenn man ausschließlich Bilder verwenden würde, sähe ein Dokument überall gleich aus. Im Web publizierte Dokumente werden mit einer breiten Palette unterschiedlicher Software auf verschiedenen Betriebssystemen betrachtet. Die Monitore, auf denen die Dokumente angezeigt werden, unterscheiden sich in Größe und Qualität oder es gibt gar keinen Monitor. Die Nutzer haben unter Umständen die Standardeinstellungen des Browsers für die Textgröße und andere Eigenschaften verändert. Diese Tatsache zu akzeptieren, wird Ihnen als Webentwickler eine Menge Frust ersparen. Wer Websites erstellt, muss wissen, dass es technischen Einschränkungen zu berücksichtigen gibt, genauso wie jemand der für den Druck arbeitet oder Filme macht andere technische Einschränkungen zu bedenken hat.

Warum sollte man Webstandards beachten

Manche Webentwickler und -designer wehren sich gegen den Einsatz von Webstandards. Bekannte Argumente sind „Das ist zu schwierig“, „Es funktioniert doch trotzdem“ und „Die Programme, die ich verwende, produzieren nicht-validen Code“.

Wenn man etwas Neues lernen und altvertraute Techniken aufgeben soll, reagiert man allzu leicht emotional und abwehrend. Wenn man sich die Situation aber nüchtern betrachtet, stellt man fest, dass es viele Vorteile bringt, Webstandards zu lernen und einzusetzen. Hier einige Beispiele:

• Entwicklung und Pflege einer Site werden einfacher: semantisch korrektes und sinnvoll strukturiertes HTML ist leichter und schneller zu verstehen — auch wenn es von jemand anderem erstellt wurde
• Kompatibilität mit zukünftigen Webbrowsern: wenn man definierte Standards und valides Markup benutzt, reduziert man das Risiko, dass künftige Browser mit dem verwendeten Code nicht zurecht kommen
• Schnellerer Download und schnellere Darstellung von Webseiten: weniger Markup bedeutet kleinere Dateien und schnellerer Download. Im Standards-Modus stellen moderne Browser Webseiten schneller dar als wenn sie im rückwärtskopatiblen Modus arbeiten
• Bessere Zugänglichkeit (Barrierefreiheit bzw. Barrierearmut): semantisches HTML, bei dem Struktur und Präsentation getrennt sind, ist für Vorlesesoftware (Screenreader) und andere alternative Anzeigegeräten leichter zu verstehen
• Besseres Suchmaschinenranking: die Trennung von Inhalt und Präsentation räumt dem Inhalt im Vergleich zur Darstellung einen größeren Anteil an der Dateigröße ein. In Kombination mit semantisch korrektem Markup verbessert dies die Position der Site im Suchmaschinenranking.
• Einfachere Anpassung: ein semantisch korrekt ausgezeichnetes Dokument kann problemlos für das Ausdrucken oder für alternative Anzeigegeräte (z.B. Handys, PDAs) optimiert werden, indem einfach eine alternative CSS-Datei eingebunden wird. Außerdem können Änderungen an der Darstellung einer kompletten Website durch das Verändern einer einzigen CSS-Datei erreicht werden.

Webstandards können Webentwicklern Zeit und Geld sparen und machen die Website für Besucher besser zugänglich. Außerdem sind Webstandards die Zukunft. Falls nicht schon mit Webstandards arbeiten, ist jetzt der richtige Zeitpunkt damit anzufangen — oder sie riskieren, mit Ihren Fähigkeiten ins Hintertreffen zu geraten.

Weiterführende Lektüre

• My Web site is standard! And yours?
  Ein Dokument des W3C über die Optimierung von Markup im Sinne von Webstandards
• Fighting for Standards
  Absichtserklärung des Webstandards Project
• What are web standards and why should I use them?
  Eine ausführlicher Erklärung, was Webstandards sind und warum man sie beachten sollte
• The Business Benefits of Web Standards
  Ein Artikel bei Netscape DevEdge über die betriebswirtschaftlichen Vorteile von Webstandards für Firmensites
• Web Standards for Business
  Ein Artikel des Webstandards Project, der sich an Entscheidungsträger aus den Marketing-, PR- und IT-Abteilungen von Firmen richtet

Validierung

Ein Dokument zu „validieren“ bedeutet zu kontrollieren, ob es die Regeln der Sprache einhält in der es geschrieben ist — vergleichbar mit dem Durchsehen eines Textes auf Fehler in Rechtschreibung und Grammatik.

Das Validieren ist ein wichtiger Aspekt bei der Erstellung von Websites. Schwer zu findende Fehler im Markup treten beim Validieren zu Tage. Ein Fehler kann ein einfacher Tippfehler sein oder ein Element, das auf nicht-erlaubte (nicht valide) Art verwendet wird.

Leider validieren viele Entwickler ihre Dokumente nicht. Manchen wissen nichts davon, andere vergessen es und wieder andere vermeiden das Validieren bewusst. Diese Situation muss den Browserherstellern angelastet werden. Die meisten Browser versuchen, nicht-valides HTML so gut wie möglich darzustellen und dabei zu „erraten“, was der Webdesigner wohl meinte, anstatt eine Fehlermeldung auszugeben. Dies hat dazu geführt, dass nachlässig geschriebenes Markup heute so verbreitet ist. Das Problem mit solchem Markup ist, dass die Darstellung nicht vorhersagbar ist und dass sie sich auf die Fehlerhandlung der Webbrowser verlässt.

Es gibt keinen Grund, Ihr HTML und CSS nicht zu validieren. Im Gegenteil. Es hat nur Vorteile.

In Why we won’t help you erläutert Mark Pilgrim sehr anschaulich die Vorteile des Validierens. Der Artikel erklärt auch, warum man nicht so schnell Hilfe in Foren und Mailinglisten bekommt, wenn man sein Markup nicht validiert hat, bevor man um Hilfe fragt.

Verschiedene HTML-Editoren, wie z.B. BBEdit und Homesite, haben eingebaute Validierungstools. Falls Ihre Entwicklersoftware keine eingebaute Möglichkeit zu validieren hat, können sie den Validierungsservice des W3C nutzen:

• (X)HTML: W3C Markup Validation Service
• CSS: W3C CSS Validation Service

Manchmal sind die Fehlermeldungen des Validators schwer zu verstehen. Ein Fehler, der weit oben in einem Dokument liegt, kann weitere Fehlermeldungen weiter unten auslösen. Man sollte daher stets des ersten Fehler beheben und dann erneut validieren — das reduziert die Fehlerzahl in der Regel beträchtlich. Einige häufige Fehlermeldungen sind in Common XHTML Validation Errors bei Black Widow Web Design erklärt.

Es ist in jedem Fall sinnvoll sicherzustellen, dass das Markup vollständig valide ist. Allerdings gibt es einige Situationen, in denen das schwierig ist. Das häufigste Problem ist die Verwendung von Flash oder andern Inhalten, die ein Plugin erfordern. Weiter Informationen über die Probleme mit Flash gibt es in den folgenden beiden Artikeln

• Flash Satay: Embedding Flash While Supporting Standards
• Embedding flash without <embed>

Struktur und Präsentation

Wenn man über Webstandards spricht, wird häufig die Trennung von Struktur und Präsentation betont. Den Unterschied zwischen diesen beiden Konzepten zu verstehen kann anfangs schwierig sein, besonders dann, wenn man nicht gewohnt ist, über die semantische Struktur eines Dokuments nachzudenken.

Es ist aber sehr wichtig, diese Trennung zu verstehen, denn die Kontrolle der Präsentation mit CSS ist sehr viel leichter, wenn Struktur und Präsentation klar getrennt sind.

Die Struktur besteht aus den obligatorischen Teilen eines Dokuments (head, body, title etc.) und dem semantischen und strukturierten Markup des Dokumentinhalts.

Die Präsentation ist die Gestaltung, die sie dem Inhalt geben. In den meisten Fällen beschreibt die Präsentation, wie ein Dokument aussieht aber sie kann auch beschreiben, wie es klingt — nicht jeder benutzt einen grafischen Browser.

Trennen sie die Struktur von der Präsentation so konsequent wie möglich. Im Idealfall sollten sie ein HTML-Dokument haben, das nur die Struktur und den Inhalt enthält und die Präsentation ausschließlich mit CSS kontrollieren.

Die Trennung von Struktur und Präsentation ist im Web gegenwärtig noch nicht sehr verbreitet. Dem HTML-Markup der meisten Sites fehlt es sowohl an Struktur als auch an Semantik.

Tabellen für das Layout

Struktur und Präsentation zu trennen bedeutet auch, CSS anstatt Tabellen für das Layout eines Dokuments zu verwenden. Wenn sie gewohnt sind, Tabellen für das Layout zu verwenden, kann das am Anfang problematisch sein. Doch es ist nicht so schwierig wie es sich zunächst anfühlt. Im Web gibt es reichlich Hilfe zu diesem Thema und die Umstellung auf CSS bringt so viele Vorteile, dass es sich in jedem Fall lohnt, die andere Denkweise zu erlernen, die dafür notwendig ist.

Weiterführende Lektüre

• Why tables for layout is stupid
  Die Folien einer Präsentation, die bei der Seybold 2003 gehalten wurde. (deutsche Übersetzung)

Semantisches HTML

Ein weiterer wichtiger Punkt bei der Trennung von Struktur und Präsentation ist semantisches Markup zum Strukturieren des Inhalts eines Dokuments. Wenn es ein XHTML-Element (ein „Tag“) gibt, das dem Sinn nach dem Teil des Inhalts entspricht, den man gerade auszeichnen will, sollte man dieses auch verwenden. Mit anderen Worten: benutzen sie CSS nicht, um ein HTML-Element wie ein anderes aussehen zu lassen, indem sie z.B. <span>-Elemente für Überschriften einsetzen und diese mit CSS dann wie <h1>-Elemente aussehen lassen.

Durch den Einsatz von semantischem Markup geben sie den verschiedenen Teilen eines Dokuments eine Bedeutung, die jeder Webbrowser versteht — egal, ob das nun der neueste grafische Browser auf einem modernen PC, ein alter Browser, der kein CSS versteht oder aber ein textbasierter Browser in einer Unix-Umgebung ist.

Überschriften

Überschriften zeichnet man mit <h1>, <h2>, <h3>, <h4>, <h5> und <h6> aus, abhängig von der Strukturebene der Überschrift. <h1> entspricht der höchsten Ebene.

Beispiel:

1. <h1>Haupt�berschrift</h1>
2. <h2>Unter�berschrift</h2>
3. Code-Download: /code/webstandards-01.txt

Textabsätze

Benutzen sie das <p>-Element, um Textabsätze auszuzeichnen. Benutzen sie nicht das <br /> Element, um Abstände zwischen Absätzen zu schaffen. Abstände (Ränder, margin) werden mit CSS kontrolliert, was sauber ausgezeichnete Absätze voraussetzt.

Beispiel:

1. <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec risus. Ed rhoncus sodales metus. Donec adipiscing mollis neque. Aliquam in nulla.</p>
2. Code-Download: /code/webstandards-02.txt

Listen

Eine Liste von Dingen sollte als Liste ausgezeichnet werden. In XHTML gibt es drei verschiedene Arten von Listen: ungeordnete Listen, geordnete (nummerierte) Listen und Definitionslisten.

Ungeordnete Listen beginnen mit <ul> und enden mit </ul>. Jeder Listenpunkt in ein <li>-Element eingeschlossen.

Geordnete (nummerierte) Listen beginnen mit <ol> und enden mit </ol>.

Definitionslisten sind etwas anders und werden dazu benutzt, eine Liste mit Begriffen und dazugehörige Definitionen auszuzeichnen. Eine Definitionsliste beginnt mit <dl> und endet mit </dl>. Jeder Begriff ist in ein <dt>-Element (definition term) eingeschlossen, jede Begriffserklärung in ein oder mehrere <dd>-Element(e) (definition definition).

Beispiel:

1. <ul>
2. <li>Punkt 1</li>
3. <li>Punkt 2</li>
4. <li>Punkt 3</li>
5. </ul>
6. Code-Download: /code/webstandards-03.txt

1. <ol>
2. <li>Punkt 1</li>
3. <li>Punkt 2</li>
4. <li>Punkt 3</li>
5. </ol>
6. Code-Download: /code/webstandards-04.txt

1. <dl>
2. <dt>Website</dt>
3. <dd>Eine Sammlung von Webseiten, die eine Firma oder eine Person repr&auml;sentieren.</dd>
4. <dt>Webseite</dt>
5. <dd>Die grundlegende Informationseinheit im Web, enth&auml;lt Text, Grafiken oder andere Medien.</dd>
6. </dl>
7. Code-Download: /code/webstandards-05.txt

CSS macht es möglich, Listen auch dann zu verwenden, wenn man die Darstellung als traditionelle Liste gar nicht möchte. Eine Navigationsleiste ist im Grunde eine Liste mit Links und ist somit ein gutes Beispiel. Listen für Navigationsmenüs zu verwenden, hat den Vorteil, dass das Menü auch in Browsern sinnvoll dargestellt wird, die CSS nicht unterstützen.

Zitate

Das <q>-Element sollte man für kürzere Zitate innerhalb einer Zeile verwenden. Webbrowser sollen vor und nach dem <q>-Element automatisch Anführungszeichen einfügen. Leider tut dies Internet Explorer nicht und in manchen Fällen kann das <q>-Element sogar Probleme bei der Barrierearmunt machen. Daher wird bisweilen empfohlen, auf das <q>-Element ganz zu verzichten und die Anführungszeichen manuell einzufügen. Zitate in <span>-Elemente mit einem geeigneten class-Attribut einzuschließen, erlaubt es zwar, die Zitate mit CSS zu gestalten, hat aber keinen semantischen Wert. Mark Pilgrims Artikel The Q Tag liefert eine detaillierte Erklärung der Probleme mit dem <q>-Element.

Längere Zitate, die einen oder mehrere Absätze umfassen, sollten mit den <blockquote>-Element markiert werden. Die Gestaltung kann dann wiederum mit CSS erfolgen. Es ist zu beachten, dass es nicht erlaubt ist, Text direkt in das <blockquote>-Element einzuschließen. Der Text muss in einem Element eingeschlossen sein, in der Regel wird das ein <p>-Element sein.

Das Attribut cite kann sowohl mit <q> als auch mit <blockquote> verwendet werden, um als Quellenangabe des Zitats eine URL zu nennen. Wenn sie <span> anstatt <q> für Zitate verwenden, können sie das cite Attribut nicht verweden.

Beispiele:

1. <p>The W3C says that <q cite="http://www.w3.org/TR/REC-html40/struct/text.html#h-9.2.1">The presentation of phrase elements depends on the user agent.</q>.</p>
2. Code-Download: /code/webstandards-06.txt

1. <p>The W3C says that <span class="quote">&#8220;The presentation of phrase elements depends on the user agent.&#8221;</span>.</p>
2. Code-Download: /code/webstandards-07.txt

1. <blockquote cite="http://www.w3.org/TR/1999/REC-html401-19991224/struct/text.html">
2. <p>&#8220;The following sections discuss issues surrounding the structuring of text. Elements that present text (alignment elements, font elements, style sheets, etc.) are discussed elsewhere in the specification. For information about characters, please consult the section on the document character set.&#8221;</p>
3. </blockquote>
4. Code-Download: /code/webstandards-08.txt

Betonung

<em> wird zur Betonung, <strong> zur starken Betonung verwendet. Die meisten Browser stellen betonten Text kursiv und stark betonten Text fett dar. Dies ist allerdings nicht vorgeschrieben, so dass man CSS verwenden sollte, um diese Art der Darstellung sicher zu stellen. Vermeiden sie den Einsatz von Betonungen, wenn sie lediglich einen visuellen Effekt erzielen wollen.

Beispiel:

1. <p><em>Emphasized</em> text is normally displayed in italics, while <strong>strongly emphasized</strong> text is usually displayed in bold.</p>
2. Code-Download: /code/webstandards-09.txt

Tabellen

XHTML Tabellen sollten nicht für das Layout verwendet werden. Wenn sie jedoch tabellarische Daten darstellen möchten, sind Tabellen die richtigen Markupelemente. Um Tabellen mit Daten so barrierearm wie möglich zu machen, ist es wichtig, die verschidenen Komponenten zu kennen, aus denen eine Tabelle aufgebaut sein kann. Einige Beispiele sind Tabellen-Header (<th>), Zusammenfassungen (das summary-Attribut) und Tabellenunterschriften (das <caption>-Element).

Beispiel:

1. <table class="example" summary="This table shows the annual population increase in Sweden during the years 1999 to 2003.">
2. <caption>Annual population increase in Sweden, 1999-2003</caption>
3. <thead>
4. <tr>
5. <td>&#160;</td>
6. <th scope="col">1999</th>
7. <th scope="col">2000</th>
8. <th scope="col">2001</th>
9. <th scope="col">2002</th>
10. <th scope="col">2003</th>
11. </tr>
12. </thead>
13. <tbody>
14. <tr>
15. <th>Population</th>
16. <td scope="row">8861426</td>
17. <td scope="row">8882792</td>
18. <td scope="row">8909128</td>
19. <td scope="row">8940788</td>
20. <td scope="row">8975670</td>
21. </tr>
22. <tr>
23. <th>Increase</th>
24. <td scope="row">7104</td>
25. <td scope="row">21366</td>
26. <td scope="row">26368</td>
27. <td scope="row">31884</td>
28. <td scope="row">34882</td>
29. </tr>
30. </tbody>
31. </table>
32. Code-Download: /code/webstandards-10.txt

Wenn sie eine detailliertere Beschreibung von Tabellen und ihrem korrekten Einsatz suchen, empfehle ich Tables in HTML documents und HTML Techniques for Web Content Accessibility Guidelines 1.0

Weiterführende Lektüre

• SimpleQuiz
  Eine exzellente Quelle, wenn sie verstehen möchten wie man Dokumente semantisch korrekt auszeichnet.

(X)HTML

Es ist durchaus möglich, HTML 4.01 für die Erstellung moderner, strukturierter und standardkonformer Websites zu benutzen. Um jedoch zu sauberem, semantischem Markup überzugehen und sich auf den potentiellen Übergang zu XML und anderen zukünftigen Auszeichnungssprachen vorzubereiten, empfehle ich XHTML 1.0 Strict. Dieser Dokumenttyp wird auch in diesem Dokument verwendet [Anm. d. Übers.: Ich benutze im Gegensatz zu Roger Johansson XHTML 1.0 transitional]

XHTML 1.0 ist eine Neuformulierung von HTML 4 innerhalb vom XML und wurde entwickelt, um HTML zu ersetzen. XHTML 1.0 Strict erlaubt kein präsentationsbezogenes Markup (übrigens ist dies auch in HTML 4.01 Strict nicht erlaubt, aber ich möchte mich hier auf XHTML konzentrieren). Durch das Verbot präsentationsbezogenen Markups erzwingt XHTML 1.0 Strict die Trennung von Struktur und Präsentation.

XHTML 1.1, die aktuelleste Version von XHTML, ist in technischer Hinsicht etwas komplizierter, da die Spezifikation verlangt, dass XHTML 1.1 Dokumente mit dem MIME-Type application/xhtml+xml gesendet werden sollen und nicht mit dem MIME-Type text/html. Es ist streng genommen nicht verboten, text/html zu verwenden, doch es wird nicht empfohlen. Im Gegensatz dazu sollte XHTML 1.0 zwar als application/xhtml+xml gesendet werden, kann aber ebenso den MIME-Type text/html verwenden, wenn dieser HTML-kompatibel ist. Die W3C Abhandlung XHTML Media Types enthält einen Überblick der MIME-Types, die vom W3C empfohlen werden.

Leider erkennen einige ältere Browser und Internet Explorer den MIME-Type application/xhtml+xml nicht und zeigen entweder den Quellcode oder überhaupt nichts.

Wenn sie application/xhtml+xml verwenden möchten, sollten sie den Server überprüfen lassen, ob der Browser, von dem die jeweilige Anfrage kommt, mit diesem MIME-Type umgehen kann oder nicht. Falls ja, wird application/xhtml+xml verwendet, falls nein wird das Dokument als text/html an den Browser gesendet.

Falls sie PHP auf der Serverseite verwenden, können sie folgendes Skript für diese sogenannte content negotiation einsetzen. Es schickt unterschiedliche MIME-Types an die verschiedenen Browser.

1. <?php
2. if (stristr($_SERVER["HTTP_ACCEPT"], "application/xhtml+xml") || stristr($_SERVER["HTTP_USER_AGENT"],"W3C_Validator")) {
3. header("Content-Type: application/xhtml+xml; charset=iso-8859-1");
4. header("Vary: Accept");
5. echo("<?xml version=\"1.0\" encoding=\"iso-8859-1\"?>\n");
6. } else {
7. header("Content-Type: text/html; charset=iso-8859-1");
8. header("Vary: Accept");
9. }
10. ?>
11. Code-Download: /code/webstandards-11.txt

Das Skript überprüft, ob das „Benutzergerät“ (user agent, in diesem Fall der Browser) einen Accept HTTP Header sendet, der den Wert „application/xhtml+xml“ enthält oder ob das Benutzergerät der W3C Validator ist (dieser sendet zwar den betreffenden Header nicht richtig, kann aber mit application/xhtml+xml umgehen). Falls eine dieser beiden Bedingungen zutrifft, wird das Dokument als application/xhtml+xml ausgeliefert. In diesem Fall wird zusätzlich ein XML Prolog gesendet. Andere Browser (einschließlich aller Versionen des Internet Explorer, IE) erhalten das Dokument als text/html und ohne XML Prolog, denn dieser würde IE/Win in den Quirks-Mode umschalten lassen, was wir nicht möchten.

Nach dem Content-Type Header wird ein Vary Header geschickt, der zwischengeschalteten Caches, wie z.B. Proxy-Servern, mitteilt, dass der MIME-Type des Dokument abhängig von den Fähigkeiten des Benutzergeräts variiert.

Wenn sie ein noch ausgereifteres PHP Skript für die content negotiation suchen, können sie sich Serving up XHTML with the correct MIME type ansehen. Dieses Skript zieht das sogenannte q-rating des Browsers zu Rate (das ist eine Aussage darüber, wie gut dieser mit bestimmten MIME-Types umgehen kann) und konvertiert XHTML zu HTML 4 bevor das Dokument als text/html ausgeliefert wird.

Hier ist ein ähnliches Skript für Server, die ASP und VBScript einsetzen.

1. <%
2. If InStr(Request.ServerVariables("HTTP_ACCEPT"), "application/xhtml+xml") > 0
3. Or InStr(Request.ServerVariables("HTTP_USER_AGENT"), "W3C_Validator") > 0
4. Then
5. Response.ContentType = "application/xhtml+xml"
6. Response.Write("<?xml version=""1.0"" encoding=""iso-8859-1""?>" & VBCrLf);
7. Else
8. Response.ContentType = "text/html"
9. End If
10. Response.Charset = "iso-8859-1"
11. %>
12. Code-Download: /code/webstandards-12.txt

Beachten sie, dass manche Browser (z.B. Mozilla) ein Dokument mit dem MIME-Type application/xhtml+xml nicht anzeigen, wenn es Fehler enthält. Das kann während der Entwicklungsphase nützlich sein, aber es kann auch zu Problemem führen, wenn eine Site online ist und von Leuten aktualisiert wird, die keine XHTML-Experten sind. Man sollte mit diesem MIME-Type also sicherstellen, dass das Markup valide bleibt. Falls sie das nicht können, sollten sie überlegen, ob HTML 4.01 Strict nicht ein besserer Dokumenttyp ist.

Hier ist eine Liste der wichtigsten Aspekte, die es bei der Verwendung von XHTML 1.0 Strict anstelle von HTML zu beachten gibt:

• Elemente (Tags) immer klein und Attribute mit Anführungszeichen: sie müssen alle Elementnamen klein schreiben und die Werte von Attributen immer in Anführungszeichen setzen.
  falsch: <A HREF="index.html" CLASS=internal>
  richtig: <a href="index.html" class="internal">
• alle Elemente schließen: In HTML müssen nicht alle Elemente geschlossen werden, sondern werden automatisch geschlossen, wenn das nächste Element beginnt. XHTML erlaubt das nicht. Alle Elemente müssen geschlossen werden, sogar diejenigen, die keinen eigentlichen „Inhalt“ haben wie z.B. das <img>-Element.
  falsch: <li>Punkt 1
  richtig: <li>Punkt 1</li>
  falsch: <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
  richtig: <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</p>
  falsch: <br>
  richtig: <br />
  falsch: <img src="image.jpg" alt="">
  rightig: <img src="image.jpg" alt="" />
• keine minimierten Attribute: In HTML könne bestimmte Attribute minimiert werden, XHTML erlaubt das nicht
  falsch: <input type="checkbox" id="checkbox1" name="checkbox1" checked>
  richtig: <input type="checkbox" id="checkbox1" name="checkbox1" checked="checked" />
• keine missbilligten (deprecated) Elemente verwenden: manchen Elemente und Attribute, die in HTML 4.01 Transitional und XHTML 1.0 Transitional erlaubt sind, werden in XHTML 1.0 Strict als „missbilligt“ (deprecated) eingestuft. Beispiele sind <font>, <center>, aling, align, width, height (für einige Elemente) und background.

Weiterführende Lektüre

• HTML Versus XHTML
  Das Webstandards Project fragt das W3C ob man HTML oder XHTML benutzen sollte und warum
• Better Living Through XHTML <br /> Ein Artikel bei A List Apart über den Übergang von HTML zu XHTML.
• The New York Public Library Online Style Guide
  Eine gute Erklärung der Benutzung von XHTML und CSS.
• XHTML 1.0 Differences with HTML 4
  Das W3C erklärt die Unterschiede zwischen XHTML 1.0 und HTML 4
• XHTML: Differences between Strict & Transitional
  Eine Zusammenfassung der Unterschiede zwischen XHTML 1.0 Strict und Transitional
• Serving XHTML with the Right MIME Type
  Das Webstandards Project fragt das W3C, welchen MIME-Type man für HTML und XHTML benutzen sollte und warum.
• XHTML Media Types
  Erkläert, welche MIME-Types für welche XHTML Dokumente verwendet werden sollten.
• Bad Tags
  HTML Dog’s Übersicht darüber, welche Elemente und Attribute sie in XHTML nicht benutzen sollten
• Specifying a MIME Type
  Ein Dokument über MIME-Types und wie man content negotiation mit unterschiedlichen server-seitigen Skriptsprachen einsetzt.
• Serving XHTML 1.0
  Ein W3C Dokument über MIME-Types und XHTML

DOCTYPE

Gegenwärtig haben noch sehr wenige HTML Dokumente einen korrekten und vollständingen DOCTYPE oder DTD (Document Type Declaration). Meist war dessen Verwendung eher dekorativ als funktional. Doch vor einigen Jahren begann das Vorhandenseine eines DOCTYPE die Darstellung einer Website stark zu beeinflussen, weil verschiedene Browser unterschiedliche Darstellungsmodi für Dokumente mit und ohne DOCTYPE wählen.

Alle HTML und XHTML Dokument müssen eine Dokument Type Deklaration haben, wenn sie valide sein sollen. Der DOCTYPE sagt aus, welche Version von HTML oder XHTML im Dokument verwendet wird und teilt somit dem Validator mit, mit welchem Modell er das Dokument vergleichen soll. Webbrowser erfahren durch den DOCTYPE, welchem Darstellungsmodus sie folgen sollen. Falls ein korrekter und vollständiger DOCTYPE vorhanden ist, schalten viele Browser in den sogenannten „Standards-Modus“, d.h. sie folgen der CSS-Spezifikation genauer. Zusätzlich wird die Darstellung der Dokumente beschleunigt, da der Browser das Dokument nicht „interpretieren“ oder für fehlerhaftes HTML eine Darstellungslösung finden muss. Dies verringert auch die Darstellungsunterschiede zwischen verschiedenen Browsern.

Die folgende Document Type Declaration weist das darauffolgende Dokument als XHTML 1.0 Strict aus und veranlasst Webbrowser, die das sogenannte DOCTYPE switching einsetzen, in den Standards-Modus zu wechseln.

1. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
2. "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
3. Code-Download: /code/webstandards-13.txt

Weiterführende Lektüre

• Fix Your Site With the Right DOCTYPE!
  Ein Artikel bei A List Apart über die richtige Verwendung des DOCTYPE
• Activating the Right Layout Mode Using the Doctype Declaration
  Eine Zusammenstellung der Darstellungsvarianten in Browsern mit DOCTYPE switching
• List of valid DTDs you can use in your document
  Die offizielle W3C Liste der korrekten Document Type Declarations

Zeichencodierung

Alle XHTML-Dokumente sollten ihre Zeichencodierung explizit angeben.

Die beste Methode, die Zeichencodierung anzugeben ist, den Webserver so zu konfigurieren, dass er einen HTTP content-type Header sendet, der die Zeichencodierung enthält. Detaillierte Anweisung dazu finden sie in der Dokumentation ihrer Serversoftware.

Wenn sie den Apache Webserver benutzen, können sie die Zeichencodierung angeben, indem sie eine oder mehrere Zeilen zur Datei .htaccess hinzufügen. Wenn sie z.B. für alle Dateien utf-8 als Kodierung benutzen, fügen sie folgende Zeile hinzu:

1. AddDefaultCharset utf-8
2. Code-Download: /code/webstandards-14.txt

Um die Zeichencodierung nur auf Dateien mit einer bestimmten Dateiendung anzuwenden, benutzen sie Folgendes:

1. AddCharset utf-8 .html
2. Code-Download: /code/webstandards-15.txt

Wenn ihr Webserver es ihnen erlaubt, PHP Skripte auszuführen, können sie den folgenden Code benutzen, um die Zeichencodierung anzugeben:

1. <?php
2. header("Content-Type: application/xhtml+xml; charset=utf-8");
3. ?>
4. Code-Download: /code/webstandards-16.txt

Um ihre Dokumente als HTML zu senden, ändern sie application/xhtml+xml in text/html. Wenn sie — aus welchen Gründen auch immer — die Zeichencodierung nicht über den Webserver angeben können, benutzen sie das entsprechende <meta>-Element im <head> des Dokuments. Unabhängig von der Serverkonfiguration kann die Angabe der Kodierung in diesem <meta>-Element nicht schaden.

Das <meta>-Element für die Zeichencodierung ISO-8859-1 würde z.B. folgendermaßen aussehen:

1. <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1" />
2. Code-Download: /code/webstandards-17.txt

Weiterführende Lektüre

• WaSP Asks the W3C: Specifying Character Encoding
  Das Webstandards Project fragt das W3C, wie Autoren die Zeichencodierung angeben sollen
• The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets
  Ein Artikel über verschiedene Zeichenkodierungen
• Using national and special characters in HTML
  Eine Eklärung der Verwendung von nationalen und Sonderzeichen in HTML Dokumenten
• Tutorial: Character sets & encodings in XHTML, HTML and CSS
  Ein Tutorial zur Auswahl und Verwendung der richtigen Zeichencodierung

CSS

Anfangs wurde CSS hauptsächlich dazu benutzt, Schrifteigenschaften festzulegen. Inzwischen können Cascading Stylesheet aber ohne weiteres dazu eingesetzt werden, das gesamte Layout eines Dokuments zu gestalten. Um das jedoch sinnvoll machen zu können, bedarf es im Vergleich zu Tabellenlayouts eines anderen Denkansatzes.

Strukturiertes, semantisches XHTML Markup ist notwendig, um ein Seitenlayout mit CSS effektiv zu gestalten.

Browserunterstützung

Wie bereits erwähnt, hat sich die Browserunterstützung für CSS in den letzten Jahren stark verbessert. Leider scheinen jedoch nicht alle Browserhersteller daran interessiert zu sein, offene Standards zu fördern, so dass der Grad der Unterstützung von Webstandards von Browser zu Browser stark variiert. Zusätzlich gibt es Fehler in der Browsersoftware (bugs), die zu ungeplantem Verhalten führen.

Im Augenblick (2004) sind die Browser mit der besten CSS-Unterstützung Mozilla (und andere Browser, welche die sog. Gecko Rendering Engine verwenden wie z.B. Firefox, Camino, Netcape 6+), Opera und Safari (und andere Browser mit der WebCore Rendering Engine, wie z.B. OmniWeb 4.5 +). Internet Explorer 6/Win hat bei weitem nicht den selben Grad von CSS-Unterstützung, doch kann mit den meisten grundlegenden CSS-Eigenschaften umgehen. Internet Explorer 5/Mac unterstützt CSS Level 1 sehr gut, jedoch kaum CSS Level 2 Eigenschaften. Internet Explorer 5.*/Win unterstützt einige Eigenschaften, hat jedoch bestimmte Macken, die man kennen muss. Frühere Versionen von Internet Explorer haben keine nennenswerte CSS-Unterstützung. Dasselbe gilt für Netscape Versionen vor Netscape 6.

Die Mehrheit der Internetnutzer surft heute mit Internet Explorer für Windows, so dass sie diesen Browser oft als kleinsten gemeinsamen Nenner akzeptieren müssen. Das bedeutet jedoch nicht, dass sie nicht auch die Fähigkeiten der Browser mit besserer CSS-Unterstützung ausnutzen könnten oder sollten.

Nicht alle Browser, die momentan in Verwendung sind, unterstützen CSS so weitgehend, dass sie ein komplett mit CSS erstelltes Seitenlayout grafisch ansprechend darstellen können. Erfreulicherweise surft aber nur ein sehr kleiner Prozentsatz der Besucher mit Browsern, die ein CSS Layout nicht angemessen anzeigen.

Es ist wichtig zu betonen, dass diese Leute nicht ausgesperrt werden. In den neunziger Jahren waren Skripte zur Überprüfung der Browserversion sehr verbreitet. Damit wurden Leute, die den „falschen“ Browser verwendeten (das war meist jeder Browser außer Internet Explorer für Windows), in der Regel auf eine Seite umgeleitet, die ihnen mitteilte, dass sie einen anderen Browser verwenden sollten, um Zugang zu der Site zu erhalten.

Heutzutage kann man mit nicht unterstützten Browsern besser umgehen. Ein großer Vorteil bei der Verwendung von logisch aufgebautem, semantischem XHTML ist, dass die Dokumente auch ganz ohne CSS problemlos zugänglich und lesbar sind. The Präsentation — wie das Dokument aussieht — wird nicht die gleiche sein wie in unterstützten Browsern, aber alle Inhalte werden vorhanden und benutzbar sein. In den meisten Fällen und für die meisten Besucher ist der Inhalte weitaus wichtiger als die Darstellung. Daher ist es besser, eine ungestaltete Seite an nicht unterstützte Browser zu senden als die ganz von der Site auszuschließen.

Es gibt dafür verschiedene Möglichkeiten. Eine der verbreitetsten Methoden ist die Verwendung von @import um die externe CSS Datei einzubinden. Netscape 4 und andere ältere Browser kennen @import nicht und importieren daher überhaupt kein Stylesheet. Es gibt die verschiedensten Möglichkeiten, Stylesheets vor Browsern zu verstecken. Die meisten haben eines gemeinsam: sie nutzen Fehler (bugs) in der CSS Interpretation der Browser aus. Das bedeutet, dass es immer ein Risiko gibt, dass ein Update für den Browser zwar den Fehler behebt, auf dem die „Versteck-Methode“ beruht, nicht aber den Fehler in der CSS Darstellung, aufgrund dessen man das Stylesheet verstecken möchte. Daher sollte man sich so wenig wie möglich auf CSS Hacks verlassen.

Natürlich können sie auch server-seitige Skripte verwenden, um verschiedene CSS Dateien (oder gar keine) an bestimmte Browser zu schicken. Falls sie diese Technik einsetzen, müssen sie sicherstellen, dass die Skripte immer aktuell sind und Browserupdates berücksichtigen.

Weiterführende Lektüre

• Tricking Browsers and Hiding Styles
  Eric Meyer beschreibt vier verschiedene Möglichkeiten, Stylesheets vor bestimmten Browsern zu verstecken
• CSS Filters and Hacks
  Eine umfangreiche Sammlung von Techniken, mit denen man CSS vor Browsern verstecken kann
• Progressive enhancement using CSS
  Ein Dokument, das verschiedene Methoden vorstellt, wie man Sites für Nutzer mit modernen Browsern verbessern kann.

CSS einbinden

Man kann Cascading Stylesheet auf verschiedene Art in ein HTML Dokument einbinden

Extern

Es hat mehrere Vorzüge, alle CSS Regeln in eine einzige Datei zu schreiben. Die HTML Dokumente werden kleiner, CSS Dateien werden im Browser Cache gespeichert und müssen nur einmal heruntergeladen werden, und man muss nur eine einzige Datei bearbeiten, um die Präsentation der gesamten Site zu verändern. Eine externe CSS Datei kann z.B. folgendermaßen aussehen:

1. h1 {
2. font-weight:bold;
3. }
4. Code-Download: /code/webstandards-18.txt

Hinweis: es gibt kein <style>-Element in einem externen Stylesheet.

Ein externes Stylesheet kann mit folgendem <link>-Element in eine HTML Datei eingebunden werden:

1. <link rel="stylesheet" type="text/css" href="styles.css" />
2. Code-Download: /code/webstandards-19.txt

oder mit einer @import-Regel in einem <style>-Element:

1. <style type="text/css">
2. @import url("styles.css");
3. </style>
4. Code-Download: /code/webstandards-20.txt

Inline

Mit dem HTML Attribut style kann man CSS Regeln direkt in ein HTML Element schreiben.

1. <h1 style="font-weight:bold;">Rubrik</h1>
2. Code-Download: /code/webstandards-21.txt

Diese Art der CSS Verwendung sollte vermieden werden, da sie Struktur und Präsentation vermischt.

Intern

Interne CSS Regeln werden in ein <style>-Element eingeschlossen, das wiederum in den <head> eines Dokuments gehört:

1. <style type="text/css">
2. h1 {
3. font-weight:bold;
4. }
5. </style>
6. Code-Download: /code/webstandards-22.txt

Diese Art der Verwendung sollte ebenfalls vermieden werden, da es sinnvoller ist, HTML und CSS getrennt zu verwalten.

Weiterführende Lektüre

• At-Rules
  Eine Eklärung von CSS Import, MIME-Types und anderer Dinge

CSS Syntax

Eine CSS Regel besteht aus einem *Selektor* und einer oder mehreren CSS *Deklarationen*. Der Selektor legt fest, auf welche(s) HTML Element(e) die Regel angewandt wird. Jede Deklaration besteht aus einer *Eigenschaft* und einem *Wert*. Der *Deklarationsblock* ist umgeben von geschwungenen Klammern { } und endet mit einem Semikolon (Strichpunkt) ;

Eine einfache CSS Regel sieht folgendermaßen aus:

1. p {
2. color:#0f0;
3. font-weight:bold;
4. }
5. Code-Download: /code/webstandards-23.txt

In diesem Beispiel ist p der Selektor, was bedeutet, dass diese Regel auf alle <p> Elemente in einem Dokument angewandt wird. Die Regel hat zwei Deklarationen, die zusammen allen Text, der innerhalb von <p> Elementen steht, grün und fett darstellen.

Eine detailliertere Beschreibung von CSS Regeln gibt z.B. CSS Beginner’s Guide, CSS from the Ground Up oder ein CSS Buch.

Weiterführende Lektüre

• CSS Crib Sheet
  Zusammen mit seinen Lesern hat Dave Shea eine Liste praktischer CSS Tipps erstellt; auch als deutsche Übersetzung: CSS Spickzettel
• Writing Efficient CSS
  John Gallant und Holly Bergevin erklären, wie man kompakte Stylesheets schreibt
• Selectutorial – CSS selectors
  Eine sehr gute Erklärung verschiedener CSS Selektoren und ihrer Funktion

Überflüssige Elemente und class Attribute

Wenn man mit Cascading Stylesheet anfängt zu arbeiten, macht man oft den Fehler, unnötige XHTML Elemente, überflüssige class Attribute und zusätzliche <div> Elemente einzusetzen. Das verhindert nicht unbedingt, dass der Code valide ist aber es widerspricht einem der Gründe, warum man Strukture und Design trennt: um einfacheres, sauberes Markup zu erhalten.

Ein Beispiel für ein unnötiges XHTML Element:

1. <h3><em>Headline</em></h3>
2. Code-Download: /code/webstandards-24.txt

Wenn sie eine Überschrift kursiv setzen möchten, verwenden sie CSS um das <h3> Element umzugestalten:

1. h3 {
2. font-style:italic;
3. }
4. Code-Download: /code/webstandards-25.txt

Die Verwendung überlüssiger class Attribute kann so aussehen:

1. <div id="main">
2. <div class="maincontent">
3. <p class="maincontenttext">
4. Lorem ipsum dolor
5. </p>
6. </div>
7. </div>
8. Code-Download: /code/webstandards-26.txt

So reicht es völlig aus:

1. <div id="main">
2. <div>
3. <p>
4. Lorem ipsum dolor
5. </p>
6. </div>
7. </div>
8. Code-Download: /code/webstandards-27.txt

Um die Elemente zu kontrollieren, die innerhalb von div#main stehen, können sie *kontextuelle Selektoren* im Stylesheet verwenden. In diesem Beispiel könnte das so aussehen:

1. div#main p {
2. /* Regeln */
3. }
4. Code-Download: /code/webstandards-28.txt

In den meisten Fällen kann man CSS dazu benutzen, logisch aufgebautes XHTML so zu gestalten, wie man es haben möchte. Man braucht dazu in der Regel kein zusätzliches Markup. Es gibt allerdings einzelne Fälle, in denen das ein oder andere zusätzliche XHTML Element nötig und sinnvoll ist.

CSS Tipps

Natürlich werden sie früher oder später mit Problemen konfrontiert sein, wenn sie CSS im Alltag verwenden. Manche Probleme entstehen aus Missverständnissen, andere durch unklare Spezifikationen oder fehlerhafte Browser. Das CSS Crib Sheet [deutsch: CSS Spickzettel] ist eine von Dave Shea zusammengestellte Sammlung guter Ratschläge. Hier sind einige der wichtigsten Tipps plus einiger mehr, die nicht im Spickzettel enthalten sind.

• Zuerst validieren: Wenn sie Fehler suchen, fangen sie damit an, sowohl das HTML Markup als auch das Stylesheet zu validieren. Probleme können durch nicht-validen Code entstehen.
• Zuerst in den modernsten Browsern testn und dann für die älteren anpassen: Wenn sie in der Testphase einen älteren Browser mit schlechter oder fehlerhafter CSS Unterstützung benutzen, werden sie ihr CSS auf die CSS Umsetzung dieses Browsers anpassen. Wenn sie dann in einem modernen Browser testen, wird das Dokument sehr wahrscheinlich nicht so aussehen, wie sie es sich vorstellen. Es ist sinnvoller, zuerst in einem standards-konformen Browser zu testen und anschließend die Anpassungen für ältere Browser vorzunehmen.
• CSS Box Modell verstehen: Um die tatsächliche Breite und Höhe eines Element zu erhalten, addieren sie seinen Innenabstand (padding) und den Rahmen (border) zum Wert für width oder height. In Internet Explorer 5./Win werden Innenabstand und Rahmen hingegen in den angegebenen Wert für width oder height *eingerechnet. Nehmen wir an, wir haben folgende CSS Regel:

1. div.box {
2. width:300px;
3. padding:20px;
4. border:10px solid;
5. }
6. Code-Download: /code/webstandards-29.txt

Die Gesamtbreite dieses <div> Elements ist 360px.

In Internet Explorer 5./Win ist die *Gesamtbreite 300px und die Breite des Inhaltsbereichs ist 240px.

Um dieses Problem zu umgehen, kann man entweder einen CSS Hack benutzen, um den Browsern, die das Modell richtig interpretieren und denen, die es falsch verstehen, unterschiedliche Werte zu senden oder man kann vermeiden, für ein Element gleichzeitig width oder height und padding oder border anzugeben. Eine gründliche Erklärung des CSS Box Modells gibt das Dokument Box model

• Einheiten für Zahlenwerte angeben, die nicht Null sind: CSS verlangt, dass für Eigenschaften wie width, height oder font-size Einheiten angegeben werden. Eine Ausnahme ist der Fall, dass der Wert einer Eigenschaft Null (0) ist. Dann ist keine Einheit notwendig, da Null immer Null ist, unabhängig von der Maßeinheit.
• Floats verstehen: Das Konzept von Floats ist nicht ganz leicht zu verstehen. Doch da es in CSS-basierten Layouts häufig verwendet wird, ist es wichtig, es zu verstehen. Einige gute Artikel über Floats sind Containing Floats, Floatutorial und Float: the Theory [deutsch: Float: Die Theorie]
• „LoVe/HAte„: Definieren sie Pseudo-Klassen für Links in der Reihenfolge link, visited, hover, active
• „TRouBLed„: Wenn sie die Kurzschreibweise verwenden, um die Eigenschaften margin, padding oder border anzugeben, funktioniert das im Uhrzeigersinn oben beginnend: top, right, bottom, left
• code>class und id Attribute nach ihrer Funktion, NICHT nach ihrer Präsentation bennenen: Wenn sie ein class Attribut .kleinblau nennen und sich später entscheiden, den Text groß und rot darzustellen, wird der Name keinen Sinn mehr machen. Es ist besser, Namen zu verwenden, welche die Funktion oder Struktur des Elements beschreiben, z.B. .copyright oder .wichtig.
• CSS unterscheidet Groß- und Kleinschreibung: Die Werte für die HTML Attribute class und id unterscheiden Groß- und Kleinschreibung, wenn sie sie in Verbindung mit CSS benutzen (siehe CSS2 syntax and basic data types).
• code>id Attribute überprüfen: Nur jeweils ein Element in einem Dokument kann einen bestimmten Wert für das Attribut id haben. Hingegen können sich mehrere Elemente den gleichen Wert für das Attribut class teilen.
• Nur erlaubte Zeichen für class und id benutzen: class und id Namen können nur aus den Zeichen [A-Za-z0-9] und dem Bindestrich (-) bestehen. Sie können nicht mit einem Bindestrich oder einer Zahl beginnen (siehe CSS2 syntax and basic data types)
• Richtig kommentieren: CSS Kommentare beginnen mit /* und enden mit */ :

CSS Layouts

Es gibt viele Beispiele und Schritt-für-Schritt Anleitungen für die Verwendung von CSS Layouts [z.B. Ein CSS Layout erstellen]. Ein Tipp ist, mit einem einfachen Layout zu beginnen, zu verstehen wie es funktioniert und sich dann zu komplexeren Layouts vorzuarbeiten.

Weiterführende Lektüre

• Simple 2 column CSS layout
  Ein Beispiel für die Erstellung eines einfachen Layouts mit Header, zwei Spalten und Footer
• CSS Layouts
  Eine Sammlung von Links zu weiteren Layout Ressourcen
• [CSS Links — Layouts
  Meine Zusammenstellung verschiedener CSS Layout Ressourcen]

Zugänglichkeit (Barrierearmut)

Das Konzept der Zugänglichkeit oder Barrierarmut (auch „Barrierefreiheit“ genannt, obwohl das kaum je der Fall sein wird) richtet sich nicht nur an behinderte Besucher, obwohl die sicherlich der Hauptgrund dafür sind, eine Website barrierearm zu machen. Eine zugängliche Website funktioniert für alle Nutzergruppen besser, behindert oder nicht. Des weiteren kann sie von mehr Leuten mit mehr unterschiedlichen Browsern und anderen Geräten genutzt werden.

Ein verbreitetes Missverständnis ist, dass eine Website, die den Grundsätzen der Barrierearmut folgt, weniger attraktiv oder zumindest anders aussieht als eine nicht-zugängliche Site. Das ist nicht der Fall. Die Zugänglichkeit muss die Präsentation überhaupt nicht beeinflussen.

Hier ein Beispiel dafür, wie Barrierearmut für alle Nutzer einer Site Vorteile bringt: Eine Website hat ein Formular, mit dem man sich für ein Seminar anmelden kann. In dem Formular kann man als Seminarort eine von drei möglichen Städten wählen. Je ein Städtename steht neben einem Radiobutton. Wenn der Entwickler der Site Barrierearmut nicht berücksichtigt, muss jeder Nutzer eines grafischen Browsers den kleinen runden Punkt des Radiobuttons anklicken, um diesen auszuwählen. Wenn aber der Entwickler sich nach den Grundsätzen der Zugänglichkeit richtet, hat er den Text für jeden Radiobutton mit dem Element <label> ausgezeichnet, so dass man eine Stadt auswählen kann, indem man entweder auf deren Namen (der in ein <label> Element eingeschlossen ist) oder auf den Radiobutton selbst klickt. Welche der beiden Methoden macht das Ausfüllen des Formulars einfacher?

Die Benutzung von semantischem, sinnvoll strukturiertem XHTML ist schon ein großer Schritt in Richtung einer zugänglichen Website. Um eine grundlegende Vorstellung davon zu bekommen, wie barrierearm ein Dokument ist, können sie es sich in einem text-basierten Browser wie z.B. Lynx ansehen. Macht der Inhalt noch Sinn? Das ist bei weiterm nicht der einzigen Test für die Barrierearmut, aber es ist ein guter Anfang.

Frames

Viele Webdesigner benutzen gerne Frames, um das Browserfenster in mehrere voneinander unabhängige Bereiche einzuteilen. Jeder dieser Bereiche besteht dann aus einem eigenen HTML Dokument. Das mag z.B. für eine Intranet Anwendung nützlich sein. Auf einer öffentlichen Website gibt es jedoch viele Gründe, die gegen den Einsatz von Frames sprechen.

• Frames verwirren Besucher: Eines der grundlegenden Prinzipien im Web ist, dass jede Seite durch eine spezifische URL repräsentiert wird. Indem sie dieses Prinzip unterlaufen, erschweren sie dem Besucher, die Struktur ihrer Site zu verstehen.
• Frames verursachen Probleme in Suchmaschinen: Damit eine Suchmaschine eine frames-basierte Site indizieren kann, müssen sie Links zu jedem der Inhaltsbereich angeben. Auch Besucher, die über eine Suchmaschine auf ihre Site komme, haben Probleme, da sie mit einiger Wahrscheinlichkeit ein Dokument aufrufen, das nur einen Teil der Seite darstellt — die Navigation fehlt meist. Einige Websites versuchen, dieses Problem zu umgehen, indem sie in der Datei robots.txt angeben, dass Suchmaschinen keine Unterseiten indizieren sollen. Auf anderen Sites wird JavaScript dazu benutzt, jeden Besucher auf die Startseite umzuleiten, der von einer Suchmaschine kommt. Diese Methoden mögen funktionieren — falls das Ziel der Site ist, weniger Besucher zu bekommen.
• Frames sind nicht bookmark-freundlich: Die meisten Browser können ein Dokument innerhalb eines Frames nicht als Lesezeichen speichern. Wenn sie das Lesezeichen öffnen, landen sie auf der Startseite des Framesets.
• Ausdrucke sind schwieriger: Viele Besucher werden Probleme haben, ein Dokument auszudrucken. In vielen Browsern muss man zuerst den zu druckenden Frame aktivieren, um den korrekten Inhalt an den Drucker zu senden.
• Links per eMail zu verschicken wird schwieriger: Frames verhindern praktisch, dass man einen Link auf eine Seite innerhalb des Frames angeben kann. Es gibt zwar Möglichkeiten, dieses Problem zu umgehen, aber sie machen die Site komplizierter.
• Barrierearmut ist schwieriger zu erreichen: Besucher, die keinen grafischen Browser mit Unterstüztung für Frames benutzen, haben Probleme, die Site zu benutzen. Daher raten Richtlinien für die Zugänglichkeit von der Benutzung von Frames ab.

Darüber hinaus machen sie sich selbst auch mehr Arbeit: durch Frames wird eine Website technisch komplexer.

Tabellen

Viele Leute verstehen die Aufforderung „Benutze keine Tabellen für das Layout“ im Sinn von „Benutze überhaupt keine Tabellen“. Diese Interpretation entspricht nicht dem Sinn von Webstandards. Wenn sie tabellarische Daten zu bearbeiten haben, gehören diese in eine Tabelle und daher sollten sie dafür auch eine Tabelle benutzen. Wenn man mit Datentabellen arbeitet, gibt es verschiedene Möglichkeiten, deren Aufbau und Struktur logischer und barriereärmer zu gestalten.

Weiterführende Lektüre

• A table, s’il vous plaît
  Links zu Artikeln über die Erstellung zugänglicher Tabellen
• Tables for Tabular Data
  Ein Artikel über die Verwendung von Tabellen für tabellarische Daten

Formulare

Formulare sind oft unnötigerweise kompliziert zu benutzen, weil sie unlogisch aufgebaut sind oder weil das HTML Markup nicht die Elemente benutzt, welche für Formulare vorgesehen sind und welche die Benutzung der Formulare einfacher und barriereärmer machen. Die Elemente <label>, <fieldset> und <legend> existieren und sollten in Formularen eingesetzt werden.

Eine oft gestellte Frage ist, welche Methode man für das Layout eines Formulars verwenden sollte. Manche sagen, dass man den Inhalte eines Formulars als tabellarische Daten betrachten kann und dass man daher eine Tabelle benutzen sollte. Eine andere Ansicht ist, dass das Layout mit CSS gestaltet werden sollte. Benutzen sie die Methode, die ihnen zusagt aber falls sie eine Tabelle benutzen, stellen sie sicher, dass das Formular darin Sinn macht, wenn die Tabellen in linearisierter Form ausgelesen wird.

Weiterführende Lektüre

• Creating Accessible Forms
  Ein Artikel von WebAIM über zugängliche Formulare.
• Better Accessible Forms
  Dieser Artikel beschreibt die Grundlagen für die Erstelltung besserer, barrierearmer Formulare.

JavaScript und Cookies

Verlassen sie sich nicht auf die Verwendung von JavaScript. Mehr Leute als sie sich vielleicht vorstellen können, haben JavaScript in ihrem Browser ausgeschaltet — entweder aus Sicherheitsgründen oder um Pop-Up Fenster zu vermeiden. Manchen verwenden auch einen Browser, der JavaSript nicht unterstützt. TheCounter.com ermittelt, dass 6% der Benutzer JavaScript ausgeschaltet haben. Laut W3Schools.com sind es 8%.

In den meisten Fällen, in denen JavaScript eingesetzt wird, bringt es dem Benutzer keine Vorteile. Es gibt aber natürlich auch Einsatzmöglichkeiten, die dem Sitebesucher ein besseres user experience ermöglichen, z.B. wenn mit JavaScript Formulareingaben auf Richtigkeit überprüft werden.

Dies bedeutet nicht, dass sie ganz auf JavaScript verzichten sollen. Es bedeutet vielmehr, dass sie vermeiden sollten, dass ihre Site JavaScript unbedingt benötigt, um richtig zu funktionieren.

Das gleiche gilt für Cookies. Verwenden sie Cookies nicht so, dass ihre Site nicht mehr funktioniert, wenn der Nutzer keine Cookies akzeptiert.

URLs

Dieses Kapitel gehört eigentlich nicht zum Thema Webstandards und Zugänglichkeit. Aber die Art, wie eine Webadresse (Uniform Resource Locator, URL) aufgebaut ist, kann einen großen Einfluss darauf haben, wie gut eine Site von Suchmaschinen indiziert wird und wie nutzerfreundlich sie ist.

Die Robots mancher Suchmaschinen folgen keinen Links, die mit einem Abfrage-String enden (string bezeichnet eine Folge von Zeichen). Diese Art von URL ist bei dynamisch generierten Websites sehr verbreitet. Eine solche URL könnte z.B. so aussehen:

1. http://yourdomain.com/products.asp?item=34627393474632&id=4344
2. Code-Download: /code/webstandards-30.txt

Um eine URL sowohl für Suchmaschinen als auch für Benutzer besser lesbar zu machen, kann man sie so aussehen lassen, als ob sie auf ein Verzeichnis zeigen würde. Das obige Bespiel würde dann so aussehen:

1. http://yourdomain.com/products/item/34627393474632/id/4344/
2. Code-Download: /code/webstandards-31.txt

Der Webserver interpretiert sie neue URL und konvertiert sie intern zurück in die ursprüngliche Form mit dem Abfrage-String. Am Ende dieses Kapitels finden sie einige Links zu Sites, auf denen sie hierzu mehr Informationen finden.

Eine noch bessere, wenn auch etwas kompliziertere, Methode schreibt die komplette URL so um, dass sie für Menschen lesbar wird.

1. http://yourdomain.com/produkte/blumen/tulpen/
2. Code-Download: /code/webstandards-32.txt

Diese Methode hat mehrere Vorteile: Suchmaschinen-Robots indizieren diese URLs besser, es wird für Menschen leichter, die URL zu lesen und sie sich zu merken und die URL gibt keinen Hinweis darauf, welche Servertechnologie verwendet wird, da keine Dateinamenerweiterungen wie .asp, .cf .cgi oder .jsp sichtbar sind. Es wird somit einfacher, die Technologie umzustellen (falls das einmal nötig wird), ohne dass URLs dabei ungültig werden. Gleichzeitig machen sie es Hackern schwerer, in ihre Site einzubrechen.

Falls sie Abfrage-Strings in ihren URLs benutzen, sollten sie sicherstellen, dass alle &-Zeichen (kaufmännisches Und, ampersand) korrekt als HTML-Zeichen (&) codiert werden. Falls das nicht der Fall ist, werden manche Browser das & (korrekterweise) als Beginn eines codierten HTML-Zeichens interpretieren und falls der darauffolgende Text einem HTML-Zeichen entspricht, dieses in seine Textentsprechung umwandeln. Das macht mit einiger Sicherheit die Abfrage kaputt.

Ein weiterer Punkt: für die meisten Sites ist die Verwendung der www Subdomain unnötig. http://domain.de sollte anstatt http://www.domain.de verwendet werden. Mehr Informationen hierzu liefert no-www.org. Ob sie die www Subdomain benutzen oder nicht: es macht Sinn, den Server so zu konfigurieren, dass es Anfragen an http://www.domain.de und an http://domain.de an die selbe URL weiterleitet.

Weiterführende Lektüre

• Generating Simple URLs for Search Engines
  Ein Artikel, der die Probleme mit bestimmten URLs erklärt und Möglichkeiten zeigt, wie man diese umgehen kann.
• Slash Forward
  Ein Artikel darüber, warum URLs besser sind, wenn sie mit einem / enden.
• Friendly Lasting URLs
  Eine Linksammlung mit Artikeln und Tutorials über URLs
• Ampersands and validation
  Eine ausführliche Erklärung der Probleme mit nicht-codierten &s (ampersands) in Abfrage-Strings sowie eine Testumgebung dafür.

Nachschlagen und Weiterlesen

Eine Sammlung von empfehlenswerten Büchern, Websites und Mailinglisten.

Bücher

• Eric Meyer on CSS: Eric Meyer, ISBN 0-73571-245-X
  Ein projekt-orientiertes Buch, das die Verwendung von CSS erklärt.
• More Eric Meyer on CSS: Eric Meyer, ISBN 0735714258
  Die Fortsetzung von „Eric Meyer on CSS“.
• Cascading Style Sheets – The Definitive Guide: Eric Meyer, ISBN 0-596-00525-3
  Ein Nachschlagewerk, das gute CSS Praxis vermittelt.
• Designing With Web Standards: Jeffrey Zeldman, ISBN 0735712018
  Standards-basiertes Webdesign, wie es im Alltag angewandt werden kann.
• Building Accessible Websites: Joe Clark, ISBN 073571150X
  Ein gründliches Buch über Barrierearmut/-freiheit und über die Techniken, wie man entsprechende Sites erstellt.

CSS

• CSS (Cascading Style Sheets) Level 1
  Die offizielle Spezifikation des W3C.
• CSS Level 2 revision 1
  Offizielle Spezifikation.
• CSS Level 3 (noch in der Entwicklung)
• css-discuss
  Eine Mailingliste für die praktische Umsetzung und Anwendung von CSS.
• [css-design
  Das deutschsprachige Pendant zu css-discuss].
• HTML Dog
  Eine Website mit vielen Tutorials und Referenzen zu HTML und CSS.
• css Zen Garden
  Unzählige Beispiel dafür, wie man mit CSS dasselbe HTML Dokument völlig unterschiedlich — und grafisch sehr anspruchsvoll — gestalten kann.
• Max Design Presentations and articles
  Mehrere sehr gute Artikel über CSS.
• Position Is Everything
  Artikel, Beispiele und Browser Bugs.

Webdesign allgemein

• A List Apart
  Ein Online Magazin mit Artikeln über Design, Webentwicklung und die Bedeutung von Content im Web. Ein Schwerpunkt liegt auf der Verwendung von Webstandards.
• webdesign-L
  Eine Mailingliste für alle, die sich mit Webdesign beschäftigen. Fast alles, was mit Webdesign und -entwicklung zu tun hat, wird hier diskutiert.

HTML

• HTML 4.01 Specification
  Die offizielle W3C Spezifikation.
• HTML Dog
  Eine Website mit vielen Tutorials und Referenzen zu HTML und CSS.

Barrierearmut/Barrierefreiheit

• Building Accessible Websites Serialization
  Joe Clarks Buch über Barrierearmut im Onlineformat.
• Dive Into Accessibility
  Mark Pilgrim’s Buch über Zugänglichkeit.
• Web Content Accessibility Guidelines 1.0
  Die offiziellen W3C Richtlinien für zugängliche Websites.
• Evaluation, Repair, and Transformation Tools for Web Content Accessibility
  Eine Infosammlung des W3C über Tools zur Beurteilung und Verbesserung der Zugänglichkeit von Websites.

Webstandards

• The Web Standards Project
  „The Web Standards Project is a grassroots coalition fighting for standards that ensure simple, affordable access to web technologies for all.“
• MACCAWS: Making A Commercial Case for Adopting Web Standards
  MACCAWS hat sich zum Ziel gesetzt, Webdesigner mit den nötigen Informationen zu versorgen, um ihren Kunden Webstandards als betribswirtschaftlich lohnende Entscheidung darzustellen. Zwei lohnende Artikel sind What Every Web Site Owner Should Know About Standards: A Web Standards Primer und The Way Forward with Web Standards.
• A Roadmap to Standards
  Dave Sheas Empfehlungen für jeden, der anfängt, sich mit Webstandards zu beschäftigen.

XHTML

• XHTML™ 1.0 The Extensible HyperText Markup Language
  Die offizielle W3C Spezifikation.
• HTML Dog
  Eine Website mit vielen Tutorials und Referenzen zu HTML und CSS.

Glossar

Zugänglichkeit/Barrierearmut/Barrierefreiheit

Eine zugängliche Website ist für jeden benutzbar unabhängig von der Hard- und Software die verwendet wird und mit jeder Art von Navigationsgerät.

CSS (Cascading Style Sheets)

Regeln, welche die Darstellung (Präsentation) eines Dokument beschreiben.

HTML (HyperText Markup Language)

Mit HTML zeichnet man die Struktur eines Dokuments aus (to mark up = auszeichnen)

Präsentation

Die optische (und evtl. auch auditive) Erscheinung einer Website

Struktur

Die vorgeschriebenden Teile eines Dokuments plus des logischesn Markups für den Inhalt

Markup

Durch die Auszeichnung eines Dokuments geben sie dessen Inhalt Struktur und Bedeutung. Im Web werden HTML und XHTML für die Auszeichnung verwendet.

Validierung

Validierung ist der Vorgang, bei dem kontrolliert wird, ob ein Dokument den Regeln entspricht, die für die verwendete Sprache gelten. Die Validierung ist vergleichbar mit der Rechtschreib- und Grammatikprüfung eines Textes.

W3C (World Wide Web Consortium)

Eine Organisation, die Spezifikationen, Richtlinien und Tools für das Web entwickelt.

Webstandards

Webstandards sind Technologien vom W3C oder anderen Standards-Organisationen bereitgestellte Technologien für die Erstellung und Darstellunge webbasierter Inhalte. Diese Technologien haben das Ziel, die Nutzbarkeit von Dokumenten im Web auch in Zukunft sicherzustellen und diese Dokumente so vielen Nutzern wie möglich zugänglich zu machen.

XHTML (eXtensible HyperText Markup Language)

XHTML ist eine Neuformulierung von HTML, so dass es Regeln für XML entspricht

XML (eXtensible Markup Language)

Eine Auszeichnungssprache, die wie HTML aussieht, die es Autoren aber erlaubt, eigene Elemente zu definieren, um Daten zu beschreiben.

Zuletzt geändert am 11.11.2009

Fehler gefunden?

Sagen Sie mir Bescheid!