Webdesign

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
Präsentationssprachen
Objektmodelle
Skriptsprachen

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…

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:

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

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:

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

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

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

Hauptüberschrift

Unterüberschrift

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

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec risus. Ed rhoncus sodales metus. Donec adipiscing mollis neque. Aliquam in nulla.

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</l i>
  5. </ul>
  6. Code-Download: /code/webstandards-03.txt
  • Punkt 1
  • Punkt 2
  • Punkt 3
  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. Punkt 1
  2. Punkt 2
  3. Punkt 3
  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
Website
Eine Sammlung von Webseiten, die eine Firma oder eine Person repräsentieren.
Webseite
Die grundlegende Informationseinheit im Web, enthält Text, Grafiken oder andere Medien.

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

The W3C says that The presentation of phrase elements depends on the user agent..

  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

The W3C says that „The presentation of phrase elements depends on the user agent.„.

  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

„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.“

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

Emphasized text is normally displayed in italics, while strongly emphasized text is usually displayed in bold.

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

Annual population increase in Sweden, 1999–2003
  1999 2000 2001 2002 2003
Population 8861426 8882792 8909128 8940788 8975670
Increase 7104 21366 26368 31884 34882

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

(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:

Weiterführende Lektüre

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

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

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

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

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

Ü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.

  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.

10px + 20px + 300px + 20px + 10px = 360px

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

300px - 10px - 20px - 20px - 10px = 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

/* Dies ist ein Kommentar */

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

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.

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

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

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 (&amp;) 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

Nachschlagen und Weiterlesen

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

Bücher

CSS

Webdesign allgemein

HTML

Barrierearmut/Barrierefreiheit

Webstandards

XHTML

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

1Jörg Petermann schrieb am 19. April 2005, 20:50 h    # 

Toll, dass es diesen Artikel nun auch in Deutsch zu lesen gibt. Danke Andreas!

2Julian schrieb am 21. April 2005, 18:28 h    # 

Hast du Roger Johansson schon mitgeteilt, dass du Designing with webstandards schon übersetzt hast oder kann er den Link zur deutschen Übersetzung noch nicht hinzugefügt haben, weil er noch nicht von der Existenz dieser weiß?
Vielen Dank auch von mir!

3ak schrieb am 21. April 2005, 18:52 h    # 

Er weiß davon. Allerdings hatte ich versäumt, es ihm vorher zu sagen, so dass ein zweiter Übersetzer ebenfalls gerade eine deutsche Fassung erstellt. Wir warten alle mit der Ankündigung, bis auch die zweite Fassung fertig ist.

4Thomas S. schrieb am 26. April 2005, 23:29 h    # 

Hallo. Das ist eine gute Seite hier, sogar für Nichtanfänger. Hab dieses PHP “content negotiation” Script getestet. Es funktioniert, nur hab ich 2 Fehler gefunden (bei error_reporting(E_ALL) und set_error_handler mit mail()).
1) $_SERVER[HTTP_ACCEPT] sollte $_SERVER[“HTTP_ACCEPT”] heißen mit Anführungszeichen und
2) es sollte mit isset($_SERVER[“HTTP_ACCEPT”]) vorher geprüft werden, sonst bekommt man eine Notice beim Aufrufen des W3C-Validators mit dem Inhalt “Undefined index: HTTP_ACCEPT”.
Grüße aus Österreich!

5ak schrieb am 27. April 2005, 10:15 h    # 

Thomas, ich werde Deine Anregungen an Roger Johansson weiterleiten. Danke für die Tipps.

6Michel B. schrieb am 11. Juli 2005, 16:43 h    # 

Ich find den Artikel bzw. die Übersetzung klasse. Bin selber sehr an Webstandards interessiert und lese so ziemlich alles, was mir davon zwischen den Mauszeiger kommt.

Ich hab diesen Artikel auch schon oft weiter empfohlen und auch in meinem Weblog erwähnt (ist aber schon was her).

Es ist auch eine klasse Sache, wenn sich jemand die Mühe macht und die Zeit nimmt, Artikel zu übersetzen.

Gruß
Michel

7Sonja schrieb am 3. September 2005, 08:30 h    # 

Ich bin schwer beeindruckt. Endlich eine Seite, die Anfängern einen fundierten Start ermöglicht.

Einziges Verständnisproblem bisher: Wozu die Quellenangabe “cite”, die in der Browseransicht doch garnicht erscheint?

8T:-)M schrieb am 24. September 2005, 18:48 h    # 

Toll gemachte Seite. Ein großes DANKESCHÖN an dich.

9gsyi schrieb am 24. Oktober 2005, 16:41 h    # 

Toller Artikel, übrigens auch nettes Blog, gleich abboniert :-)

10Robert Hartl schrieb am 20. Januar 2006, 14:35 h    # 

Schöner, verständlicher Artikel / Übersetzung. Wäre ich bloß früher darauf gekommen. Danke!

11ak schrieb am 20. Januar 2006, 14:50 h    # 

Einziges Verständnisproblem bisher: Wozu die Quellenangabe “cite”, die in der Browseransicht doch garnicht erscheint?

Sonja, auf die Schnelle würde ich sagen, dass diese Angabe ein Vorgriff ist auf das sog. “semantische Web”, d.h. eine Form von Metadaten, die es erlaubt, Inhalte besser als bisher zu kategorisieren und auch automatisch auszulesen.

12Grishan schrieb am 1. März 2006, 13:50 h    # 

Hallo, bin gerade auf der Suche nach der in deutsch gebräuchlichen Schreibweise von Webstandards versus Web Standards hier hängengeblieben – und positiv überrascht angesichts der Mühe und Klarheit mit der Deine Ausführungen dargelegt werden !
Lohnenswert zu lesen sowohl für Einsteiger als auch für fortgeschrittene Webworker.

13Boda schrieb am 4. März 2006, 23:09 h    # 

Wirklich tolles Seite und super Tutorial.
Danke für die tolle Arbeit.

14flix schrieb am 4. April 2006, 10:46 h    # 

vielen dank für das geniale Tut.
Werd ich gleich mal zu meinen Favoriten hinzufügen :)

15Günter schrieb am 14. April 2006, 23:22 h    # 

Servus,

Erstmal DANKE für dieses / deine Tutorial(s).
Zum leidigen Thema “cite” (siehe Kommentar 7 u.11): Wenn ich die Sache richtig verstehe (bin grad am lernen!) kann man cite als Attribut (cite="...) und als Element (cite.../cite) verwenden. Schöner aussehen, semantischer und zugänglicher ist, denke ich die 2. Möglichkeit.

Der gleichen Meinung ist auch Vorsprung durch Webstandards

Schöne Grüße aus Wien

16Bertram schrieb am 11. Mai 2006, 19:32 h    # 

Hallo,

habe die Seite www.ahr-eifel-rhein.de in Javascript verfassen lassen und wundere mich nun, daß die Suchmaschinen meine Seiten nicht finden.

Wie kann ich sie doch trotz javascript auf die seiten bringen um einen besseren respond zu haben. kann mir jemand ein beispiel für einen textlink oder einen noscript-tag angeben und mir sagen wo diese zu installieren sind?
Danke
M.Bertram

17ladon schrieb am 18. Juli 2006, 15:59 h    # 

Ich habe folgende Fehlermeldung:

Attributwerte, die keine alphanumerische Zeichen enthalten, müssen in Anführungszeichen gesetzt werden
/href=news.php?id=5 …/

Aber wie soll ich auf ”?” im PHP-Script verzichten?

...

18ak schrieb am 18. Juli 2006, 16:06 h    # 

In welchem Zusammenhang bekommst du diese Fehlermeldung? Aus der URL wird auch nicht klar, wie genau sie verwendet wird.

Eine mögliche Lösung: href="news.php?id=5" (mit Anführungszeichen nach dem Gleichheitszeichen).

19Suchmaschinenmarketing - Webdesign & Multimedia Anwendungen schrieb am 7. September 2006, 04:37 h    # 

Hmmm,

das hat leider bei mir nicht funktioniert.
Oder liegt es an meinem Browser Opera 7?

Gruss
TP