Deutsche Übersetzung von Christian Machmeier.

Inhalt

  1. Einleitung
  2. Geschichte
  3. Webstandards
  4. Struktur und Darstellung
  5. (X)HTML
  6. CSS
  7. Zugänglichkeit
  8. URLs
  9. Referenzen
  10. Glossar

1. Einleitung

Dieses Dokument erläutert, wie und warum das Verwenden von Webstandards sie Websites erstellen lassen wird und das in einer Art, die den Entwicklern Zeit und Geld spart und den Besuchern eine bessere Erfahrung verschafft. Darüberhinaus werden weitere Methoden, Richtlinien und bewährte Praktiken diskutiert, die erstklassige Websites zu erstellen helfen, die für so viele wie möglich zugänglich sind.

2. Geschichte

Als das Internet und das Web in der zweiten Hälfte der Neunziger Mainstream wurden, hatten die Browserhersteller CSS, Cascading Style Sheets, noch nicht so gut implementiert, als das Webentwickler in der Lage gewesen wären, CSS zur Steuerung der Darstellung ihrer HTML-Dokumente einzusetzen. Die mangelnde Implementierung wird teilweise verständlich, ruft man sich in Erinnerung, dass die CSS/Level 1-Spezifikation 1996 und die CSS/Level2-Spezifikation 1998 veröffentlicht wurden.

Die mangelnde CSS-Unterstützung von Webbrowsern, kombiniert mit den Bedürfnissen von Grafikdesignern, die an das Maß an Kontrolle, wie sie es bei der Arbeit mit Printmaterialien möglich ist, gewohnt waren, führten zum Missbruch von HTML in jeder Art um die visuelle Darstellung einer Webseite zu kontrollieren. Ein Beispiel ist der große Durchbruch als die Designer entdeckten, dass das Setzen des Attributs border="0" zum Verstecken der Tabellenrahmen, ein unsichtbares Gitter erzeugt wird, mit dem sich das Layout kontrollieren lässt. Ein weiteres Beispiel ist das Gebrauch von transparenten, und daher unsichtbaren Spacer-GIFs zur Layoutkontrolle.

Da HTML nie zur Darstellungskontrolle eines Dokuments gedacht war, wurden Hacks, ungültige Code und herstellerspezifische Elemente (Tags) und Attribute verwendet. Validierung war etwas, von der nur Wenige wussten oder sie benutzten. Tagsuppe wäre ein sehr treffender Begriff für diese Art von Code.

Mit den Veröffentlichungen neuer Webbrowserversionen wurde die CSS-Unterstützung verbessert und ausgeweitet, nicht jedoch in einem Maße, in dem es hätte sein sollen. Trotz der langsamen CSS-Implementierung seitens der Browserhersteller, haben wir heute einen Punkt erreicht, an dem Browser mit nenneswerter CSS-Unterstützung von so vielen genutzt werden, dass es keinen Grund mehr gibt, HTML nicht so zu benutzen, wie es ursprünglich mal gedacht war: Die Struktur eines Dokumentes zu beschreiben und nicht seine Darstellung. Dafür können wir heute CSS benutzen, das speziell zu diesem Zweck entwworfen wurde.

3. Webstandards

Was sind Webstandards?

Webstandards, vom W3C und anderen Gremien eingerichtet, sind Technologien, die zur Erzeugung und Interpretation von Web-basierten Inhalten benötigt werden. Diese Technologien wurden entwickelt um im Web veröffentlichte Dokumente zukunftssicher und so vielen wie möglich zugänglich zu machen.

Struktursprachen

Darstellungssprachen

Objektmodelle

Skriptsprachen

Dieses Dokument konzentriert sich auf XHTML 1.0 Strict bezüglich der Struktur, CSS Level 1 und Level 2 bezüglich der Darstellung und ECMAScript 262 bezüglich des Scriptings (nicht, dass es hier sonderlich viele Scripting-Beispiele gäbe).

Wenn von einem Dokument gesagt wird, es halte sich an Webstandards, dann bedeutet das, dass dieses Dokument, ausser dass es von oben genannten Technologien Gebrauch macht:

Festzustellen bleibt hier, dass “in jedem Webbrowser funktioniert” nicht bedeutet “in jedem Webbrowser gleich aussieht”. Ein Dokument über Browser und Plattformen identisch aussehen zu lassen, ist so gut wie unmöglich. Nicht einmal die ausschliessliche Benutzung von Bildern wird eine Website überall exakt gleich aussehen lassen. Auf im Web veröffentlichte Dokumente wird mit einer Vielzahl unterschiedlicher Geräte auf verschiedenen Betriebssystemen, mit Monitoren unterschiedlicher Größe und Qualität (oder ohne irgendeinen Monitor), von Benutzern, die die Textgröße oder andere Einstellungen in ihrem Browser geändert haben können, zugegriffen. Das Akzeptieren dieser Tatsache wird ihr Leben weit weniger frustierend werden lassen. Jeder, der Webseiten erstellt, sollte verstehen, dass es technische Vorraussetzungen zu beachten gibt, genauso wie für solche, die auf Papier veröffentlichen, oder Filme oder Fernsehsendungen machen, andere Vorraussetzungen existieren.

Warum der Gebrauch von Webstandards?

Bestimmte Webentwickler und Webdesigner hegen Widerstand gegen den Gebrauch von Webstandards. Oft hört man als Gegenargumente Es ist zu schwierig, Es funktioniert doch trotzdem und Die Programme, die ich benutze erzeugen ungültigen Code.

Es ist einfach emotional zu reagieren, und Widerstand gegenüber dem Lernen von Neuem und dem Ablassen von Vorgehensweisen, mit denen man vertraut ist, aufzubauen. Jedoch, betrachtet man die Situation logisch, wird man feststellen, dass das Lernen und der Gebrauch von Webstandards viele Vorteile birgt. Ein paar Beispiele:

Webstandards können den Webseitenschaffenden Zeit und Geld sparen, und den Besuchern einer Website eine bessere Erfahrung verschaffen. Ausserdem sind Webstandards die Zukunft. Wenn sie also nicht schon Webstandards einsetzen, dann ist jetzt der richtige Zeitpunkt damit zu beginnen, oder sie riskieren zurückzufallen.

Weitere Informationen:

Validierung

Validierung ist der kontinuierliche Vorgang sicherzustellen, dass ein Dokument den Regeln der verwendeten Sprache folgt. Das kann man mit dem Überprüfen eines Textes bezüglich seiner sprachlichen und grammatikalischen Fehler vergleichen.

Validierung ist wichtiger Teil der Webentwicklung. Viele schwer zu findende Fehler werden bei der Validierung entdeckt. Ein Fehler kann so trivial sein wie ein Verschreiber, oder so ernst wie der ungültige Einsatz von Elementen oder Attributen.

Unglücklicherweise validieren viele Leuten ihre Dokumente nicht. Manche wissen gar nicht, dass es Validierung gibt, andere vergessen zu validieren, und dann sind da noch solche, die Validierung absichtlich vermeiden. Dieser Zustand kann zum überwiegenden Teil den Browserherstellern angelastet werden. Die meisten Webbrowser versuchen ungültiges HTMl so gut wie möglich zu interpretieren, und versuchen zu raten, was der Autor gemeint haben könnte, anstatt eine Fehlermeldung anzuzeigen. Dieses Verhalten hat zu verwarlostem Markup geführt, wie es heutzutage recht gebräuchlich ist. Das Problem, das mit dieser Art von Markup besteht, ist, dass es zu vorhersehbaren Ereignissen führt und auf der Fehlerbehandlung des Webbrowsers beruht.

Es gibt keinen Grund, dass sie ihr erstelltes HTML und CSS nicht validieren. Im Gegenteil. Es gibt nur Vorteile.

Why we won’t help you ist Mark Pilgrims exzellente Erklärung der Vorteile, die Validierung bietet. Darüberhinaus führt der Artikel auch aus, warum es schwieriger sein kann Hilfe von Leuten in Diskussionsforen oder auf Mailinglisten zu bekommen, wenn man seine Dokumente vor dem Erfragen von Rat nicht validiert hat.

Etliche HTML-Editoren, wie zum Beispiel BBEdit und Homesite besitzen bereits integrierte Validierungswerkzeuge. Für den Fall, dass ihr Entwicklungswerkzeug keine integrierte Validierungsfunktion bietet, können sie auf die online verfügbaren Validierungsdienste des W3C zurückgreifen:

Von den Validatoren erzeugte Fehlermeldungen zu verstehen kann gelegentlich schwierig sein. Ein Fehler an einer frühen Stelle im Dokument kann mehrere zusätzliche Fehler nach sich ziehen. Behebt man einen ersten Fehler und validiert erneut, kann man so die Anzahl der Fehler häufig erheblich reduzieren. Einige Fehlermeldungen, die häufiger auftauchen werden in Common XHTML Validation Errors bei Black Widow Web Design erklärt.

Es ist immer eine gute Idee, wenn sie ihren Code absolut valide halten, es gibt aber jedoch einige Gelegenheiten, bei denen es schwierig ist Validierungsfehler zu vermeiden. Das häufigste Beispiel dafür ist das Einbinden von Flash, oder anderen Inhalten, die ein Plug-In erfordern. Erfahren sie mehr über die Probleme mit Flash in Flash Satay: Embedding Flash While Supporting Standards und Embedding flash without <embed>.

4. Struktur und Darstellung

Beschäftigt man sich mit Webstandards, wird häufig die Trennung von Struktur und Darstellung betont. Den Unterschied zwischen Struktur und Darstellung zu begreifen kann anfänglich Schwierigkeiten bereiten, speziell wenn man nicht gewohnt ist über die semantische Struktur eines Dokuments nachzudenken. Das zu verstehen ist jedoch sehr wichtig, wird dadurch doch die Steuerung der Darstellung eines Dokumentes mittels CSS sehr viel einfacher, wenn Struktur und Darstellung getrennt sind.

Struktur setzt sich aus den zwingend erforderlichen Abschnitten eines Dokumentes und der semantischen und strukturierten Auszeichnung der Inhalte eines Dokuments zusammen.

Darstellung ist das Aussehen, das man dem Inhalt gibt. In den meisten Fällen, dreht sich Darstellung darum, wie eine Dokument aussieht, sie kann aber auch beeinflussen, wie sich ein Dokument anhört – denn nicht jeder benutzt einen graphischen Webbrowser.

Trennen sie Struktur und Darstellung soweit wie möglich. Idealerweise sollte man eine HTML-Dokument haben, das Struktur und Inhalt beherbergt und die Darstellung des Dokuments gänzlich mit CSS steuern.

Die Trennung von Struktur und Darstellung ist heutzutage noch nicht sehr gebräuchlich. Auf den meisten Websites lässt der HTML-Code sowohl Struktur als auch Semantik vermissen.

Layouttabellen

Um die Struktur von der Darstellung zu trennen, muss man CSS statt Tabellen zur Layoutkontrolle eines Dokuments verwenden. Ist man daran gewöhnt Layouttabellen zu benutzen, kann sich das unbequem und komisch anfühlen, aber es ist nicht so schwierig wie es zunächst scheint. Umfangreiche Hilfe gibt es im Web, und die Vorteile sind so zahlreich, dass es sich auf jeden Fall lohnt, sich die Zeit zu nehmen diese andere notwendige Denkweise zu lernen.

Weitere Informationen:

Semantisches HTML

Ein anderer wichtiger Teil bei der Trennung von Struktur und Darstellung ist der Gebrauch von semantischem Markup um die Inhalte des Dokuments zu strukturieren. Existiert ein XHTML-Element, das die passende Bedeutung für den auszuzeichnenden Teil des Inhalts besitzt, gibt es keinen Grund irgendetwas anderes zu benutzen. Mit anderen Worten, benutzen sie CSS nicht um ein HTML-Element wie ein anderes aussehen zu lassen, zum Beispiel ein <span>-Element statt eines <h1>-Elements zu benutzen um eine Überschrift auszuzeichnen.

Der Einsatz von semantischem HTML gibt den verschiedenen Teilen eines Dokuments in jedem Webbrowser Bedeutung, sei es der aktuellste graphische Webbrowser auf einem modernen PC, ein alter Webbrowser, der nicht mit CSS umgehen kann oder ein text-basierter Browser in einer UNIX-Konsole.

Überschriften

Um Überschriften auszuzeichnen, verwendet man <h1>, <h2>, <h3>, <h4>, <h5> oder <h6>, abhängig von der jeweiligen Überschriftsebene. <h1> ist die höchste Ebene.

Beispiele:
<h1>Document heading</h1>
<h2>Sub heading</h2>

Document heading

Sub heading

Paragraphen

Benutzen sie das <p>-Element um Paragraphen auszuzeichnen. Verwenden sie nicht das <br />-Element um Absätze zu erzeugen. Abstände zwischen Paragraphen werden mit CSS gesteuert und müssen deshalb auch korrekt ausgezeichnet werden.

Beispiel:
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing
elit. Donec risus. Ed rhoncus sodales metus. Donec adipiscing
mollis neque. Aliquam in nulla.</p>

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

Listen

Eine Liste von Dingen sollte auch als Liste ausgezeichnet werden. In XHTML gibt es drei verschiedene Arten von Listen: Ungeordnete Listen, sortierte Listen und Definitionslisten.

Ungeordnete Listen, auch gepunktete Listen genannt, beginnen mit <ul> und enden mit </ul>. Jeder Listeneintrag wird von einem <li>-Element umschlossen.

Sortierte Listen beginnen mit <ol> und enden mit </ol>.

Definitionslisten verhalten sich etwas anders, sie werden gebraucht um Listen von Begriffen und Beschreibungen auszuzeichnen. Definitionslisten beginnen mit <dl> und enden mit </dl>. Jeder zu beschreibende Begriff wird von einem <dt>-Element und die Beschreibung von einem oder mehreren <dd>-Elementen eingefasst.

Beispiele:
<ul>
<li>Item 1</li>
<li>Item 2</li>
<li>Item 3</li>
</ul>
<ol>
<li>Item 1</li>
<li>Item 2</li>
<li>Item 3</li>
</ol>
  1. Item 1
  2. Item 2
  3. Item 3
<dl>
<dt>website</dt>
<dd>A collection of linked web pages that represent a company
or an individual.</dd>
<dt>web page</dt>
<dd>The basic unit of information on the Web, containing text,
graphics and other media.</dd>
</dl>
website
A collection of linked web pages that represent a company or an individual.
web page
The basic unit of information on the Web, containing text, graphics and other media.

CSS ermöglicht den Gebrauch von Listen auch dann, wenn der Listeninhalt gar nicht wie eine herkömmliche Liste dargestellt werden soll. Eine Navigationsliste, bestehend aus einer Liste von Links, ist hierfür ein gutes Beispiel. Der Vorteil einer Liste für eine Menü besteht darin, dass das Menü auch in Browsern, die kein CSS unterstützen, Sinn ergibt.

Zitate

Das <q>-Element sollte für kürzere, Fliesstextzitate verwendet werden. Webbrowser sollen Anführungszeichen automatisch vor und nach dem Inhalt des <q>-Elements hinzufügen. Bedauerlicherweise tut das der Internet Explorer nicht und in manchen Fällen kann das <q>-Element sogar Probleme mit der Zugänglichkeit verursachen. Daher empfehlen einige, dass man den Gebrauch von <q>vermeidet und stattdessen die Anführungszeichen per Hand einfügt. Umschliesst man Fliesstextzitate mit <span>-Elementen, die eine passende Klassen verwenden, erlaubt das zwar eine Gestaltung mit CSS, birgt aber leider keinen semantischen Wert. Lesen sie Mark Pilgrims The Q tag, um einen detailierten Einblick in die Probleme mit dem <q>-Element zu bekommen.

Das <blockquote>-Element sollte man für längere Zitate, die ein oder mehrere Absätze umfassen, verwenden. CSS kann dann eingesetzt werden um das Zitat zu gestalten. Beachten sie, dass Text nicht direkt innerhalb eines <blockquote>-Elements gestattet ist, sondern von einem weiteren Element umschlossen sein muss, üblicherweise von einem <p>-Element.

Das cite-Attribut kann sowohl in <q> als auch in <blockquote> eingesetzt werden und liefert damit eine URL als Quelle des Zitats. Verwenden sie <span> statt <q> für Fliesstextzitate, können sie das cite-Attribut nicht verwenden.

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

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

<p>The W3C says that <span class="quote">&#8220;The presentation of
phrase elements depends on the user agent.&#8221;</span>.</p>

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

<blockquote cite="http://www.w3.org/TR/1999/REC-html401-19991224/
struct/text.html">
<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>
</blockquote>

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

Hervorhebung

<em> verwendet man zur Hervorhebung und <strong> zur starken Hervorhebung. Die meisten Webbrowser zeigen hervorgehobenen Text kursiv und stark hervorgehobenen Text fett an. Das ist jedoch keine Voraussetzung, daher ist es am besten CSS für ihre Darstellung einzusetzen um sicher zu gehen wie hervorgehobener Text angezeigt wird. Vermeiden sie Hervorhebungen immer dann, wenn sie lediglich einen visuellen Effekt erreichen möchten.

Beispiel:
<p><em>Emphasized</em> text is normally displayed in italics,
while <strong>strongly emphasized</strong> text is usually
displayed in bold.</p>

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

Tabellen

XHTML-Tabellen sollten nicht zum Layout gebraucht werden. Sie sollten aber benutzt werden um tabellarische Daten auszuzeichnen. Um Datentabellen so zugänglich wie möglich zu machen, ist es wichtig, dass man um die verschiedenen Komponenten, aus denen sich Tabellen zusammensetzen weiß, und diese auch benutzt. Einige Beispiele sind Tabellenköpfe (<th>), Zusammenfassungen (das summary-Attribut) und Beschriftungen (das <caption>-Element).

Beispiel:
<table class="example" summary="This table shows the annual population
increase in Sweden during the years 1999 to 2003.">
<caption>Annual population increase in Sweden, 1999–2003</caption>
<thead>
	<tr>
		<td>&#160;</td>
		<th scope="col">1999</th>
		<th scope="col">2000</th>
		<th scope="col">2001</th>
		<th scope="col">2002</th>
		<th scope="col">2003</th>
	</tr>
</thead>
<tbody>
	<tr>
		<th scope="row">Population</th>
		<td>8 861 426</td>
		<td>8 882 792</td>
		<td>8 909 128</td>
		<td>8 940 788</td>
		<td>8 975 670</td>
	</tr>
	<tr>
		<th scope="row">Increase</th>
		<td>7 104</td>
		<td>21 366</td>
		<td>26 368</td>
		<td>31 884</td>
		<td>34 882</td>
	</tr>
</tbody>
</table>
Annual population increase in Sweden, 1999–2003
  1999 2000 2001 2002 2003
Population 8 861 426 8 882 792 8 909 128 8 940 788 8 975 670
Increase 7 104 21 366 26 368 31 884 34 882

Eine detailiertere Beschreibung von Tabellen und ihrem Gebrauch liefert Tables in HTML documents und HTML Techniques for Web Content Accessibility Guidelines 1.0.

Weitere Informationen:

5. (X)HTML

Mit HTML 4.01 ist es möglich moderne, strukturierte und die Standards entsprechende Websites zu erstellen. Um den Übergang zu sauberem, semantischem Markup zu vollziehen und um besser auf den möglichen Übergang zu XML und andere zukünftige Auszeichnungssprachen vorbereitet zu sein, empfehle ich für neue Websites den Gebrauch XHTML 1.0 Strict, das auch für die Beispiele in diesem Dokument verwendet wird.

XHTML 1.0 ist eine Neuformulierung von HTML 4 in XML 1.0 und wurde entwickelt um HTML zu ersetzen. XHTML 1.0 Strict, das ich zum Gebrauch empfehle, erlaubt darstellendes Markup nicht (HTML 4.01 Strict zwar auch nicht, aber ich beschäftige mich ja hier mit XHTML). Deshalb erzwingt XHTML 1.0 Strict die Trennung von Struktur und Darstellung.

XHTML 1.1, die aktuellste XHTML-Version, ist technisch etwas schwieriger zu handhaben, da die Spezifikation festlegt, dass XHTML 1.1-Dokumente mit dem MIME-Typ application/xhtml+xml haben und nicht als text/html bereitgestellt werden sollen. Der Gebrauch von text/html ist zwar nicht verboten, aber er wird auch nicht empfohlen. XHTML 1.0 auf der anderen Seite, das application/xhtml+xml verwenden sollte, darf auch den MIME-Typ text/html benutzen, solange das HTML-kompatibel geschieht. Die W3C-Notiz XHTML Media Types enthält einen Überblick aller, vom W3C empfohlener MIME-Typen.

Unglücklicherweise erkennen einige ältere Browser und der Internet Explorer den MIME-Typ application/xhtml+xml nicht und stellen unter Umständen den Quelltext dar oder weigern sich sogar das Dokument anzuzeigen.

Falls man application/xhtml+xml verwenden möchte, sollte man den Server überprüfen lassen, ob der anfragende Browser mit diensem MIME-Typ umgehen kann, und ihm in diesem Fall auch verwenden, ansonsten verwendet man eben text/html für allen anderen Browser.

Falls man PHP zur serverseitigen Programmierung einsetzt, kann das folgende Skript zur Aushandlung des Inhalts verwendet werden um Dokumente mit unterschiedlichen MIME-Typen verschiedenen Browsern anzubieten:

<?php
if (stristr($_SERVER[HTTP_ACCEPT], "application/xhtml+xml")
|| stristr($_SERVER["HTTP_USER_AGENT"],"W3C_Validator")) {
header("Content-Type: application/xhtml+xml; charset=iso-8859-1");
header("Vary: Accept");
echo("<?xml version=\"1.0\" encoding=\"iso-8859-1\"?>\n");
} else {
header("Content-Type: text/html; charset=iso-8859-1");
header("Vary: Accept");
}
?>

Das Skript überprüft, ob der Useragent einen HTTP_Accept-Header schickt, der den Wert “application/xhtml+xml”, oder ob der Useragent der W3C-Validator ist, der zwar keinen ordentlichen HTTP_ACCEPT-Header schickt, aber dennoch mit application/xhtml+xml umgehen kann. Trifft eines davon zu wird das Dokument als application/xhtml+xml bereitgestellt. Diesen Browsern wird auch XML-Deklaration geschickt. Anderen Browsern, darunter alle Versionen des Internet Explorer, wird das Dokument als text/html angeboten. Dem Dokument wird keine XML-Deklaration vorangestellt, da das den IE/Win in den Quirksmode versetzen würde, was wir nicht möchten.

Nach dem Content-Type-Header, wird ein Vary-Header gesendet, der allen zwischenläufigen Chaches, wie Proxyservern mitteilt, dass sich der Content-Type des Dokuments abhängig von den Fähigkeiten des anfragenden Klienten ändert.

Eine erweiterte Veresion eines PHP-Skripts zur Aushandlung des Inhalts finden sie in Serving up XHTML with the correct MIME type. Das Skript betrachtet die q-Bewertung des Useragents (wie gut er behauptet mit einem bestimmten MIME-Typen umgehen zu können), und wandelt XHTML in HTML 4 um bevor das Dokument als text/html an Useragents gesendet wird, die mit application/xhtml+xml nicht umgehen können.

Hier nun ein ähnliches Skript für alle, die ASP und VBScript einsetzen:

<%
If InStr(Request.ServerVariables("HTTP_ACCEPT"), "application/xhtml+xml") > 0 
Or InStr(Request.ServerVariables("HTTP_USER_AGENT"), "W3C_Validator") > 0 Then
Response.ContentType = "application/xhtml+xml"
Response.Write("<?xml version=""1.0"" encoding=""iso-8859-1""?>" & VBCrLf);
Else
Response.ContentType = "text/html"
End If
Response.Charset = "iso-8859-1"
%>

Beachten sie, dass manche Browser, zum Beispiel Mozilla, Dokumente, deren MIME-Typ application/xhtml+xml ist, nicht darstellen, wenn diese fehlerhaft sind. Das kann während der Entwicklung recht hilfreich sein, kann aber auf einer Live-Site zu Problemen führen, die von Leuten aktualisiert wird, die keine XHTML-Experten sind, es sei denn sie können sicherstellen, dass der gesamte Code gültig bleibt. Ist das nicht der Fall, könnten sie in Erwägung ziehen stattdessen HTML 4.01 Strict zu verwenden.

Es folgt eine Liste der wichtigsten Dinge, die zu beachten sind, setzt man XHTML 1.0 Strict statt HTML ein:

Weitere Informationen:

Doctype

Momentan haben nur sehr wenige HTML-Dokumente einen korrkten und vollständigen Doctype, oder DTD (Document Type Declaration). Das war bisher immer eher dekorativ als funktional, aber seit einigen Jahren kann die Anwesenheit eines Doctypes das Rendering eines Dokuments in einem Webbrowser stark beeinflussen.

Um gültig zu sein müssen sämtliche HTML- und XHTML-Dokumente eine Doctype-Deklaration besitzen. Der Doctype gibt an welche HTML- oder XHTML-Version das Dokument verwendet, wird vom Validator beim Validieren gebraucht und von Webbrowsern, die bestimmen müssen welchen Rendering-Modus sie verwenden. Ist in einem Dokument ein korrekter und vollständiger Doctype vorhanden, wechseln viele Webbrowser in den Standardmodus, was bedeutet, dass sie der CSS-Spezifikation genauer folgen. Das Dokument wird auch schneller gerendert, weil der Browser nichts zu interpretieren hat und ungültiges HTML kompensieren muss. Dadurch werden auch die Renderingunterschiede in Browsern verringert.

Der folgende Doctype deklariert ein Dokument als XHTML 1.0 Strict und veranlasst Webbrowser, die das sogenannte “doctype switching” beherrschen, ihren Standardmodus zu verwenden.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
Weitere Informationen:

Zeichenkodierung

Alle XHTML-Dokumente sollten ihre Zeichenkodierung angeben.

Die Zeichenkodierung gibt man am besten an, indem man den Webserver so konfiguriert, dass er einen HTTP- Content-Type-Header mit der Zeichenkodierung verschickt. Um weitere Informationen darüber, wie man das erreicht, zu erhalten, ziehen sie die Dokumentation der von ihnen verwendeten Webserversoftware zurate.

Sollten sie Apache einsetzen, können sie die Zeichenkodierung angeben, indem sie eine oder mehrere Regeln ihrer .htaccess-Datei hinzufügen. Verwenden zum Beispiel all ihre Dateien UTF-8, fügen sie folgendes hinzu:

AddDefaultCharset utf-8

Um eine Zeichenkodierung für Dateien mit einer bestimmten Erweiterung anzugeben, verwenden sie:

AddCharset utf-8 .html

Bietet ihnen ihr Server die Möglichkeit PHP-Skripte auszuführen, können sie folgendes angeben um die Zeichenkodierung zu bestimmen:

<?php
header("Content-Type: application/xhtml+xml; charset=utf-8");
?>

Liefern sie ihre Seiten als HTML aus, ändern sie application/xhtml+xml in text/html. Sollten sie aus irgendeinem Grund nicht in der Lage sein ihren Webserver so zu konfigurieren, dass er die richtige Zeichenkodierung verwenden kann, dann benutzen sie ein <meta>-Element im <head>- Abschnitt des Dokuments. Es ist auf jeden Fall eine gute Idee die Zeichenkodierung so anzugeben, selbst wenn ihr Server korrekt konfiguriert ist.

Zum Beispiel informiert das folgende <meta>-Element den Browser darüber, dass ein Dokument ISO-8859-1 als Zeichenkodierung verwendet:

<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1" />
Weitere Informationen:

6. CSS

Zumeist für die Angabe von Schrifteigenschaften gebraucht, kann man CSS heute einsetzen um das komplette Layout eines Dokumentes zu steuern. Um das effizient zu tun, benötigt man jedoch einen etwas anderen Ansatz als bei der Layoutkontrolle durch Tabellen.

Strukturiertes, semantisches XHTML ist nötig um mit CSS das Layout auf effiziente Art und Weise zu steuern.

Browserunterstützung

Wie bereits erwähnt hat sich die CSS-Unterstützung von Browsern in den letzten paar Jahren stark verbessert. Da unglücklicherweise nicht alle Browserherstteller an der Implementierung offener Standards interessiert zu sein scheinen, variiert der Grad der Unterstützung von Browser zu Browser. Darüberhinaus verursachen Softwarefehler, dass sich Browser in einer Art verhalten, wie sie es nicht tun sollten.

Momentan (2004) sind die Webbrowser mit der besten CSS-Unterstützung Mozilla (und andere Gecko-basierte Browser: Firefox, Camino, Netscape 6+), Opera und Safari (und weitere WebCore-basierte Browser: OmniWeb 4.5 und höher). Internet Explorer 6/Win bietet nicht denselben Grad an CSS-Unterstützung, erlaubt aber dennoch die meisten elementaren Dinge. Internet Explorer 5/Mac bietet eine sehr gute CSS 1-Unterstützung, kennt aber leider nicht viel von CSS 2. IE 5.* für Windows unterstützt ein wenig, hat aber einige Probleme, die man kennen sollte. Frühere Versionen von Internet Explorer bieten keine nennenswerte Unterstützung. Selbiges gilt für Netscape Versionen vor 6.

Da momentan die Mehrheit der Nutzer Internet Explorer für Windows verwendet, wird dieser Browser oft ihr kleinstes gemeinsames Vielfaches sein. Das heisst aber nicht, dass sie von den Fähigkeiten von Browsern mit besserer CSS- Unterstützung zur Verbesserung ihres Designs nicht Gebrauch machen sollten oder könnten.

Nicht alle Browser, die heute Verwendung finden, bieten den Grad an CSS-Unterstützung, den es zum Rendern einer grafisch attraktiven Website, die vollständig auf CSS setzt, braucht. Glücklicherweise benutzen auf den meisten Websites nur wenige Prozent der Besucher einen Browser, der zu alt ist um ein CSS-basiertes Layout ordentlich zu rendern.

Wichtig festzuhalten ist hier, dass diese Leute nicht ausgeschlossen werden. In den Neunzigern waren Browsercheckskripte ein beliebter Weg jeden, der den “falschen” Browser verwendete (üblicherweise jeder, außer Internet Explorer für Windows), auf eine Seite umzuleiten, die ihnen mitteilte, sie sollten zunächst ihren Browser aktualisieren bevor sie Zugriff auf die Site erlangten.

Heutzutage kann man mit nicht-unterstützten Browsern besser umgehen. Ein großer Vorteil von logischem, semantischem XHTML ist, dass das Dokument auch ohne CSS zugänglich und verwendbar ist. Die Darstellung — die Art und Weise, ein Dokument aussieht — wird nicht dieselbe sein, wie in einem unterstützten Browser, aber der Inhalt wird da sein. In den meisten Fällen, für die meisten Besucher einer Site sind die Inhalte sowieso wichtiger als ihr Aussehen. Das ist der Grund, warum es besser ist eine ungestylte Seite an nicht-unterstützte Browser zusenden, als diese von einer Site auszusperren.

Es gibt verschieden Wege das zuerreichen. Einer der gebräuchlichsten ist eine verknüpfte CSS-Datei mit @import zu laden. Netscape 4 und ältere Browser verstehen @import nicht und werden die CSS- Datei nicht laden. Es gibt etliche Wege CSS vor Webbrowsern zu verstecken. Die meisten Methoden CSS zu verstecken haben gemeinsam, dass sie auf Fehlern, wie Browser CSS-Code interprestieren, beruhen. Das bedeutet, es gibt immer das Risiko, dass eine Browserupdate den Fehler zum Verstecken des CSS behebt, nicht aber das CSS-Problem, das zum Verstecken dieses CSS geführt hat. Je weniger man sich also auf CSS-Hacks verlässt, desto besser.

Mann kann auch serverseitige Technologien einsetzen um einen Browsercheck durchzuführen und anschliessend verschiedene CSS-Dateien (oder auch keine) an verschiedene Browser zu senden. Tut man das, muss man sicherstellen, dass das Erkennungsskript auch aktuell gehalten wird, um zu verhindern, dass die falsche CSS-Datei gesendet wird, wenn ein Browser aktualisiert oder ein komplett neuer Browser veröffentlicht wird.

Weitere Informationen:

Verschiedene Wege CSS anzuwenden

Es gibt etliche Wege CSS auf Elemente eines HTML-Dokuments anzuwenden.

Extern

Es gibt mehrere Vorteile alle CSS-Regeln in ein oder mehreren separaten CSS-Dateien zu halten. Die HTML-Dokumente werden kleiner, CSS-Dateien werden im Browsercache gespeichert, müssen also nur einmal heruntergeladen werden und man braucht nur eine einzige Datei zu bearbeiten um das Layout der gesamten Website zu verändern. Eine externe CSS-Datei kann so aussehen:

h1 {
font-weight:bold;
}

Hinweis: In einer externen CSS-Datei gibt es kein <style>-Element.

Man kann eine CSS-Datei und ein HTML-Dokument mit einem <link>-Element verknüpfen:

<link rel="stylesheet" type="text/css" href="styles.css" />

Oder mit eienr @import-Regel in einem <style>-Element:

<style type="text/css">
@import url("styles.css");
</style>

Inline

Gebraucht man das style-Attribut, kann man CSS direkt auf ein HTML-Element anwenden:

<h1 style="font-weight:bold;">Rubrik</h1>

Das sollte jedoch vermieden werden, da es Struktur und Darstellung vermischt.

Intern

Ein <style>-Element beinhaltet internes CSS, welches selbst in das <head>-Element eines Dokuments gehört:

<style type="text/css">
h1 {
font-weight:bold;
}
</style>

das sollte ebenfalls vermieden werden, da man HTML und CSS am besten in getrennten Dateien hält.

Weitere Informationen:

CSS Syntax

Eine CSS-Regel besteht aus einem Selektor und einer oder mehrerer Deklarationen. Der Selektor bestimmt welches HTML-Element oder -Elemente von einer Regel betroffen sind. Jede Deklaration besteht aus einer Eigenschaft und einem Wert. Der Deklarationsblock wird von { } umschlossen und jede Deklaration endet mit ; (Semikolon).

Eine einfache CSS-Regel sieht so aus:

p {
color:#0f0;
font-weight:bold;
}

In diesem Fall ist p der Selektor, was bedeutet, dass die Regel auf alle <p>-Elemente innerhalb des Dokuments angewendet wird. Die Regel hat zwei Deklarationen, die zusammen den kompletten Text in einem <p>-Element grün und fett erscheinen lassen.

Um eine detailiertere Beschreibung von CSS-Regeln zu erhalten, schauen sie sich zum Beispiel CSS Beginner’s Guide, CSS from the Ground Up oder ein CSS-Buch an.

Weitere Informationen:

Überflüssige Elemente und Klassen

Beginnt man sich mit CSS zu beschäftigen, kommt es häufig vor, dass man den Fehler macht unnötige XHTML-Elemente, überflüssige Klassen und Extra-<div>-Elemente zu benutzen. Das bedeutet nicht notwendigerweise, dass der Code ungültig wird, aber es widerspricht einem der Gründe, warum Struktur und Darstellung voneinander getrennt werden sollten; um einfacheres, saubereres Markup zu bekommen.

Ein Beispiel für den Gebrauch unnötiger XHTML-Elemente:

<h3><em>Headline</em></h3>

Möchte man eine Überschrift kursiv darstellen, benutzt man CSS um das <h3><-Element neu zu gestalten:

h3 {
font-style:italic;
}

Eine überflüssige Verwendung von Klassen kann so aussehen:

<div id="main">
<div class="maincontent">
	<p class="maincontenttext">
		Lorem ipsum dolor
	</p>
</div>
</div>

Das tut es ebenso gut:

<div id="main">
<div>
	<p>
		Lorem ipsum dolor
	</p>
</div>
</div>

Um Elemente innerhalb von div#main zu kontrollieren, kann man im CSS-Code Kontextselektoren einsetzen. Das könnte so aussehen:

div#main p {
/* rules */
}

In den meisten Fällen kann CSS verwendett werden, so dass man logisches XHTML gestalten kann, wie man möchte ohne Extra-Markup hinzufügen zu müssen Es gibt jedoch Fälle, in denen es sich lohnt Extra-Code hinzuzufügen.

CSS-Tipps

Beginnt man sich ernsthaft mit CSS zu beschäftigen, treten früher oder später Probleme auf. Einige Probleme werden durch Missverständnisse verursacht, andere durch unklare Spezifikationen oder fehlerhafte Browser. Das CSS Crib Sheet ist eine Sammlung guter Ratschläge, zusammengestellt von Dave Shea. Es folgen nun die wichtigsten Tipps, ergänzt um einige weitere, die im CSS Crib Sheet nicht erwähnt werden.

CSS-Layouts

Es gibt viele Beispiele und Schrit-für-Schritt-Anleitungen, wie man CSS für das Layout verwendet. Ein guter Rat ist mit einem einfachen Lyout zu beginnen, zu lernen wie es funktioniert und dann mit fortgeschritteneren Layouts weiterzumachen.

Weitere Informatioenen:

7. Zugänglichkeit

Zugänglichkeit dreht sich nicht nur um die Unterstützung behinderter Besucher, auch wenn das einer der wichtigsten Gründe ist eine Website zugänglich zu machen. Eine zugängliche Website funktioniert für jeden besser, behindert oder nicht, und auf sie kann von mehr Leuten mit vielen Arten von Webbrowsern und anderen Geräten zugegriffen werden.

Eine allgemeine Fehlbetrachtung besteht darin, dass wenn man eine Website zugänglich macht, sie weniger attraktiv oder anders als eine Website aussieht, die nicht zugänglich ist. Das ist nicht der Fall. Zugänglichkeit muss die Darstellung nicht notwendigerweise beeinflussen.

Es folgt ein Beispiel wie Zugänglichkeit jedermann helfen kann: Eine Website hat ein Formular, mit dem man sich für eine Seminar anmelden kann. Innerhalb des Formulars kann man den Besuch des Seminars in einer von drei Städten auswählen. Jeder Stadtname sitzt bei einem radio-Button. Hatte derjenige, der das Formular angelegt hat, Zugänglichkeit nicht im Kopf, muss jeder Benutzer eines grafischen Browsers seinen Cursor über dem kleinen radio-Button positionieren um eine Stadt auszuwählen. Weiß der entwickler über Zugänglichkeit bescheid und hat er die Beschriftungen neben jedem radio-Button mit einem <label>-Element ausgezeichnet, ist man so auch in der Lage auf den Stadtnamen zu klicken um einen Ort auszuwählen. Welcher Weg ist wohl für jeden, der das Formular benutzt, einfacher?

Die Verwendung von semantischem, wohl.strukturiertem XHTML wird sie auf den Weg zu einer zugänglichen Website bringen. Um eine Idee davon zu bekommen, wie zugänglich ein Dokument tatsächlich ist, betrachten sie es in einem Text-basierten Browser wie Lynx um herauszufinden, ob der Inhalt immer noch Sinn ergibt. Das ist bei Weitem nicht die einzige Zugänglichkeitsprüfung, die man durchführen kann, aber es ist ein guter Anfang.

Frames

Viele Webdesigner benutzen Frames gerne um das Browserfenster in mehrere unabhängige Bereiche aufzuteilen, wobei jeder von diesen ein eigenes HTML-Dokument beinhaltet. Das kann für eine Intranetanwendung oder etwas Ähnliches recht nützlich sein. Auf einer öffentlichen Website gibt es bei der Verwendung von Frames jedoch viele Dinge zu beachten:

Darüberhinaus macht man sich selbst das Leben schwer. Frames machen eine Website technisch komplexer.

Tabellen

Recht häufig interpretieren die Leute “Benutzt Tabellen nicht für’s Layout” als “Verwendet überhaupt keine Tabellen”. So sollte man das aber nicht verstehen. Zeichnet man tabellarische Daten aus, gehören diese in eine Tabelle, daher sollte man auch immer eine Tabelle verwenden. Beim Zusammenstellen von Datentabellen ist jedoch wichtig zu wissen, dass es viele Möglichkeiten gibt sie logischer und zugänglicher zu machen.

Weitere Informationen:

Formulare

Formulare sind oft unnötig schwer zu benutzen, teils weil sie unlogisch aufgebaut sind, teils weil der zugrundeliegende HTML-Code nicht die Elemente verwendet, die es gibht Formulare zugänglicher und einfacher benutzbar zu machen. Die Elemente <label>, <fieldset> und <legend> existieren und sollten auch verwendet werden.

Eine häufige Frage ist, was man zum Layouten eines Formulars verwendet. Manche sagen, man könne ein Formular als tabellarische Daten begreifen und sollte es daher mit einer Tabelle auszeichnen, während andere meinen, dass CSS verwendet werden sollte. Welche Methode man auch immer verwendet, beim Gebrauch einer Tabelle sollte man auf jeden Fall sicherstellen, dass das Formular Sinn ergibt ergibt und zugänglich ist, wenn die Tabelle, die das Formular enthält, linaearisiert wird.

Weitere Informationen:

JavaScript und Cookies

Vermeiden sie die Abhängigkeit von JavaScript. Mehr Leute, als man denkt, haben JavaScript in ihrem Browser ausgeschaltet, sei es aus Sicherheitsgründen oder um Popupfenster zu vermeiden. Sie könnten auch einen Browser verwenden, der JavaScript nicht unterstützt. Laut TheCounter.com haben 6% der Webbenutzer kein JavaScript. W3Schools.com berichtet von 8%.

In den meisten Fällen, in denen JavaScript eingesetzt wird, bringt es dem Besucher keinerlei Vorteile. Natürlich gibt es Fälle, bei denen JavaScript verwendet werden kann um eine bessere Erfahrung zu bereiten. Ein Beispiel ist die Prüfung von Formulareingaben.

Beachten sie, dass das nicht bedeutet, dass man den Gebrauch von JavaScript vermeiden sollte. Es bedeutet lediglich, dass man vermeiden sollte das Funktionieren der Website von JavaScript abhängig zu machen.

Dasselbe gilt für Cookies. Verwenden sie Cookies nicht in einer Weise, dass die Website nicht mehr funktioniert, wenn der Besucher sie nicht akzeptiert.

8. URLs

Dieser Abschnitt beschäftigt sich nicht wirklich mit Webstandards oder Zugänglichkeit, kommt aber an dieser Stelle, weil die Art, wie sich ein URL zusammensetzt, großen Einfluss haben kann, wie gut eine Website von Suchmaschinen indexiert wird und wie gebrauchsfähig sie für ihre Besucher sind.

Einige Suchmaschinenrobots folgen keinen Links zu URLs, die mit einem Querystring enden. Diese Art von URLs kommt sehr häufig auf Websites vor, die ihre Inhalte dynamisch aus einer Datenbank beziehen und sehen zum Beispiel so aus:

http://yourdomain.com/products.asp?item=34627393474632&id=4344

Der einfachste Weg einen URL zu konstruieren, der für Suchmaschinenrobots und Menschen besser ist, ist ihn aussehen zu lassen als ob er auf ein Verzeichnis zeigt. Das obige Beispiel würde also geändert werden um so auszusehen:

http://yourdomain.com/products/item/34627393474632/id/4344/

Der Webserver interpretiert dann diesen neuen URL und konvertiert ihn dann intern zurück zum Original-URL, inklusive Querystring. Am Ende dieses Abschnitts gibt es einige Links zu Seiten mit mehr Informationen wie man das erreicht.

Noch besser, aber auch etwas komplizierter, ist es sichtbare URLs komplett umzuschreiben, so dass sie für den Menschen lesbar werden:

http://yourdomain.com/products/flowers/tulips/

Die Vorteile der Verwendung dieser Art von URLs sind, dass Suchmaschinenrobots die Site besser indexieren werden, es für Menschen leichter wird den URL zu lesen, und dass man nicht die verwendete Servertechnologie offenbart. Da die URLs keine serverspezifischen Dateierweiterungen, wie .asp, .cf, .cgi oder .jsp beinhalten, wird es ebenfalls leichter die auf dem Server eingesetzte Technologie zu wechseln, falls das nötig werden sollte.

Entscheidet man sich Querystrings in seinen URLs zu verwenden, ist es wichtig, dass jedes Ampersand, &, als seine HTML-Entität &amp; kodiert wird. Tut man das nicht, werden einige Webbrowser, wie sie auch sollten, das Ampersand als Beginn einer HTML-Entität betrachten, und falls der unmittelbar folgende Text mit einer HTML-Entität übereinstimmt, wird der Browser den URL konvertieren und in den meisten Fällen den Querystring zerstören.

Eine andere erwähnenswerte Sache ist, dass es für die meisten Websites nicht notwendig ist eine www-Subdomain zu verwenden, und dass daher http://yourdomain.com/ statt http://www.yourdomain.com/ verwendet werden sollte. Weitere Informationen darüber sind auf no-www.org verfügbar. Ob man nun die www-Subdomain verwendet oder nicht, es ist auf jeden Fall eine gute Idee seinen Webserver so zu konfigurieren, dass jeder Traffic zu http://www.yourdomain.com/ und http://yourdomain.com/ zum selben URI umgeleitet wird.

Weitere Informationen:

9. Referenzen

Eine Auswahl empfohlener Bücher, Websites und Mailinglisten.

Bücher

CSS

Allgemeine Webentwicklung

HTML

Zugänglichkeit

Webstandards

XHTML

10. Glossar

CSS (Cascading Style Sheets)
Regeln, dei beschreiben wie ein Dokument dargestellt weden sollte.
Darstellung
Das Aussehen (oder der Klang) einer Website.
HTML (HyperText Markup Language)
Wird verwendet um die Struktur eines Dokuments auszuzeichnen.
Markup
Mit dem Auszeichnen einnes Dokuments gibt man ihm und seinem Inhalt Struktur und Bedeutung. Im Web wird HTML und XHTML zum Auszeichnen verwendet.
Struktur
Die notwendigen Teile eines Dokuments plus die logische Auszeichnung des Inhalts eines Dokuments.
Validierung
Validierung ist der andauernde Kontrollprozess ein Dokument den Regeln, der in ihm verwendeten Sprache folgen zu lassen. Das kann man mit dem Überprüfen von Text auf sprachliche und grammatikalische Fehler vergleichen.
W3C (World Wide Web Consortium)
Eine Organisation, die Spezifikationen, Richtlinien und Werkzeuge für das Web entwickelt.
Webstandards
Webstandards sind Technologien, die, hervorgebracht vom W3C und anderen Standardsgremien, dazu verwendet werden webbasierte Inhalte zu erzeugen und zu interpretieren. Diese Technologien wurden entworfen um im Web veröffentlichte Dokumente zukunftssicher und sie so vielen wie möglich zu machen.
XHTML (Extensible HyperText Markup Language)
Reformuliertes HTML, das den Regeln von XML folgt.
XML (Extensible Markup Language)
Eine Auszeichnungssprache, die aussieht wie HTML, aber dem Autor erlaubt Daten zu beschreiben in dem er passende Elemente definiert.
Zugänglichkeit
Eine zugängliche Website ist für jeden zugänglich und benutzerfreundlich, wenn es keine Rolle spielt welche Hard- und Software verwendet wird und wenn es egal ist was man zum Navigieren auf der Site verwendet.

Kommentare, Fragen oder Vorschläge? Bitte lass’ es mich wissen.

© Copyright 2004 Roger Johansson