Übersetzungen dieses Artikels sind verfügbar.
Deutsche Übersetzung von Christian Machmeier.
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.
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.
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.
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.
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.
Ein W3C-Dokument, das zeigt wie man die Qualität des Codes einer Website verbessern kann.
Der Missionsauftrag des Web Standards Project.
Eine kurze Erklärung des Web Standards Project, was Webstandards sind und warum ihr Einsatz eine gute Sache ist.
Ein Netscape DevEdge-Artikel, der zeigt wie eine Firma mit dem Einsatz von Webstandards Geld verdient.
Ein Artikel des Web Standards Project, das sich speziell an Mitglieder der Marketing-, Press- und IT-Abteilungen wendet.
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>.
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.
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.
Folien einer Präsentation, die auf der Seybold 2003 gehalten wurde.
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.
Um Überschriften auszuzeichnen, verwendet man <h1>, <h2>,
<h3>, <h4>, <h5> oder
<h6>, abhängig von der jeweiligen Überschriftsebene. <h1> ist
die höchste Ebene.
<h1>Document heading</h1> <h2>Sub heading</h2>
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.
<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.
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.
<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>
<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>
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.
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.
<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">“The presentation of phrase elements depends on the user agent.”</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>“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.”</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.”
<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.
<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.
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).
<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> </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>
| 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.
Eine hervorragende Quelle um die Herangehensweise, wie man etwas semantisch-korrekt auszeichnet zu erlernen.
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:
Benutzen sie immer Kleinschreibung und setzen sie alle Attribute in Anführungszeichen: Sämtloche Elemente und Attributnamen sind klein zu schreiben. Alle Attributwerte kommen in Anführungszeichen.
Falsch: <A HREF="index.html" CLASS=internal>
Richtig: <a href="index.html" class="internal">
Schliessen sie alle Elemente: In HTML müssen einige Elemente nicht
geschlossen werden. Solche Elemente werden automatisch geschlossen, sobald das nächste
Element beginnt. Das erlaubt XHTML nicht. Alle Elemente müssen geschlossen werden, auch
solche, die keinen Inhalt haben, wie zum Beispiel <img>.
Falsch: <li>Item 1Richtig:
<li>Item 1</li>
Falsch: <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
Richtig: <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</p>
Falsch: <br>
Richtig: <br />
Falsch: <img src="image.jpg" alt="">
Richtig: <img src="image.jpg" alt="" />
Attribute können nicht verkürzt werden: In HTML können bestimmte Attribute abgekürzt werden werden. Das erlaubt XHTML nicht.
Falsch: <input type="checkbox" id="checkbox1" name="checkbox1" checked>
Richtig: <input type="checkbox" id="checkbox1" name="checkbox1" checked="checked" />
Verwenden sie keine veralteten Elemente: Einige Elemente und Attribute, die in
HTML 4.01 Transitional und XHTML 1.0 Transitional erlaubt sind, sind in XHTML 1.0 Strict (und in HTML
4.01 Strict) veraltet. Einige Beispiele sind <font>, <center>,
alink, align, width, height (bei einige Elementen),
und background.
Das Web Standards Project fragt das W3C, ob und warum man HTML oder XHTML benutzen sollte.
Ein Artikel von A List Apart über den Übergang von HTML zu XHTML.
Eine gute Erläuterung, wie man XHTML und CSS einsetzt.
Das W3C erklärt den Unterschied zwischen XHTML 1.0 und HTML 4
Eine Zusammenfassung der Unterschiede zwischen XHTML 1.0 Strict und Transitional
Das Web Standards Project fragt das W3C welchen MIME-Typ man für HTML und XHTML verwenden sollte, und warum.
Eine Zusammenfassung welche Medientypen zur Bereitstellung von XHTML-Dokumenten verwendet werden sollten.
HTML Dog’s Führer durch die Elemente und Attribute, die man in XHTML nicht verwenden sollte.
Ein Dokument über MIME-Typen und wie man Inhaltsaushandlung mit verschiedenen serverseitigen Skriptsprachen bewerkstelligt.
Ein W3C-Dokument über MIME-Typen und XHTML.
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">
Ein A List Apart-Artikel über wie und warum man einen Doctype einsetzt.
Eine Zusammenfassung wie verschiedene Doctype-Deklarationen Browser mit doctype-switching beeinflussen.
Die offizielle Liste korrekter Doctype-Deklarationen des W3C.
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" />
Das Web Standards Project fragt das W3C wie Webautoren die Zeichenkodierung angeben sollen.
Ein Artikel über verschiedene Zeichenkodierungen.
Eine Erklärung wie man Landes- und Sonderzeichen in HTML-Dokumenten einsetzt.
Ein Tutorial, wie man die Zeichenkodierung auswählt und einsetzt.
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.
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.
Eric Meyer beschriebt vier Wege CSS vor bestimmten Browsern zu verstecken.
Eine große Sammlung an Techniken CSS vor Browsern zu verstecken.
Ein Dokument über verschiedene Wege die Erfahrung von Leuten mit modernen Browsern zu verbessern.
Es gibt etliche Wege CSS auf Elemente eines HTML-Dokuments anzuwenden.
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>
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.
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.
Eine Erklärung von CSS-Import und Medientypen.
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.
Mit Hilfe seiner Leser hat Dave Shea eine Liste praktischer CSS-Regeln zusammengestellt.
John Gallant und Holly Bergevin erklären wie man kompaktes CSS verfasst.
Eine sehr gute Erklärung von verschiedenen CSS-Selektoren und wie sie funktionieren.
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.
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.
Validiere zuerst: Beim Debuggen beginnt man mit der Validierung von HTML und CSS. Viele Probleme können durch ungültigen Code verursacht werden.
Teste zunächst in den fortschrittlichsten Browsern, dann bring es in den anderen zum Laufen: Benutzt man während des Testens einen alten Browser mit einer schlechten und/oder fehlerhaften CSS- Implementierung, passt sich das CSS an die Implementierung dieses Browsers an. Testet man dann in einem fortschrittlicheren Browser, stehen die Chancen gut, dass nichts so aussieht, wie man dachte. Es ist daher besser es zunächst in den Standards-kompatiblesten Browsern zum Laufen zu bringen und den Code anschliessend an weniger fähige Browser anzupassen.
Verstehe das CSS-Boxmodell: Um die tatsächliche Breite und Höhe eines Elements zu bestimmen,
muss man sein padding und seine border zu seiner width oder
height hinzuzählen. Im Internet Explorer 5.*/Win sind jedoch padding und
border in der angegebenen width oder height schon miteingeschlossen.
Angenommen man hätte folgendes CSS:
div.box {
width:300px;
padding:20px;
border:10px solid;
}
Die albsolute Breite des divs ist 360px.
10px + 20px + 300px + 20px + 10px = 360px
Im Internet Explorer 5.*/Win beträgt die absolute Breite aber 300px, daher ist die Breite des Inhalts 240px.
300px - 10px - 20px - 20px - 10px = 240px
Um dieses Problem zu umgehen kann man entweder einen CSS-Hack benutzen um unterschiedliche Werte an Browser,
die das richtig machen und an die, die es falsch verstehen, zu senden, oder man vermeidet width
und padding oder border für ein Element anzugeben.
Eine ausführliche Erklärung des CSS-Boxmodells bietet das Dokument Box model.
Gib Einheiten zu numerischen Nicht-Null-Werten an: CSS verlangt die Angabe von Einheiten
für Eingenschaften wie width, height oder font-size. Eine Ausnahme
bildet der Wert 0 (Null). In diesem Fall ist keine Einheit notwendig, da Null Null ist, unabhängig in welcher
Einheit.
Verstehe floats: Das float-Konzept ist manchmal schwer zu verstehen, aber es ist sehr wichtig, da es häufig in CSS-basierten Layout Verwendung findet. Sehr gute Artikel über floats sind Containing Floats, Floatutorial und Float: The Theory.
“LoVe/HAte”: Definiere Pseudoklassen für Links in der reihenfolge Link, Visited, Hover, Active.
“TRouBLed”: Beim Benutzen der Kurzform um margin,
padding und border für ein Element anzugeben, achtet man darauf, dass das im
Uhrzeigersinn geschieht: Top, Right, Bottom, Left.
Benenne Klassen und IDs anhand ihrer Funktion und nicht anhand ihrer Darstellung: Nennt man
eine Klassen .smallblue und entscheidet später, dass der Text groß und rot erscheinen soll, ist
der Klassenname sehr verwirrend. Besser ist es Namen zu verwenden, die Funktion oder Struktur beschreiben, wie
.copyright oder .important.
CSS unterscheidet Groß- und Kleinschreibung: Werte der HTML-Attribute class und
id beachten bei der Verwendung von CSS Groß- und Kleinschreibung (siehe
CSS2 syntax and basic data types).
Überprüfe die IDs: Nur ein Element innerhalb eines Dokuments kann einen bestimmten Wert für
das id-Attribut haben, wohingegen sich beliebig viele Elemente denselben classennamen
teilen können.
Verwende nur erlaubte Zeichen für class und id: Class-
und id-Namen können nur aus Zeichen [A-Za-z0-9] und dem Bindestrich (-) bestehen, und sie dürfen
nicht mit einem Bindestrich oder einer Zahl beginnen (siehe
CSS2 syntax and basic data types).
Kommentiere korrekt: CSS-Kommentare beginnen mit /* und enden auf */:
/* This is a comment */
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.
Ein Beispiel, wie man ein einfaches Layout mit einem Kopf, zwei Spalten und einem Fuss erstellt.
Eine Linksammlung zu verschiedenen CSS-Layouts.
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.
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:
robots.txt mitteilen
Unterseiten nicht zu indexieren. Auf anderen Sites wird Javascript eingesetzt um jeden, der über eine Suchmaschine
kommt auf die Startseite umzuleiten. Beide Methoden mögen funktionieren, falls es das Ziel ist weniger Besucher
zu bekommen.
Darüberhinaus macht man sich selbst das Leben schwer. Frames machen eine Website technisch komplexer.
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.
Links zu Artikel, die beschreiben, wie man zugängliche Tabellen erstellt.
Ein Artikel über die Verwendung von Tabellen zur Darstellung tabellarischer Daten.
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.
Ein WebAIM-Artikel über zugänglicher Formulare.
Ein Artikel über die Grundlagen bessere, zugänglichere Formulare zuerstellen.
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.
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 & 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.
Ein Artikel, der die Probleme mit bestimmten Arten von URLs erklärt und wie man seine URLs verbessert.
Ein Artikel darüber, warum das Beenden eines URLs mit einem “/” gut ist.
Eine Sammlung von Links zu Artikeln und Tutorials über URLs.
Eine längere Erklärung der Probleme mit unkodierten Ampersands in Querystrings und ein Testfall.
Eine Auswahl empfohlener Bücher, Websites und Mailinglisten.
Ein Projekt-basiertes Buch, dass erklärt wie man CSS einsetzt.
Die Fortsetzung des ersten Eric Meyer on CSS.
Ein Referenzbuch, das die CSS-Empfehlungen erklärt.
Standardsbasiertes Webdesign und -entwicklung in der realen Welt.
Ein gutes Buch über Zugänglichkeit und wie man zugängliche Websites erstellt.
Die offizielle W3C-Spezifikation.
Die offizielle W3C-Spezifikation.
Eine Mailingliste, auf der der praktische Einsatz und Anwendungen von CSS diskutiert werden.
Eine Website mit einer großen Sammlung an Tutorials, Referenzen und Artikeln über HTML und CSS.
Viele Beispiele, die zeigen wie man CSS einsetzen kann um ein und dasselbe HTML-Dokument auf komplett unterschiedliche Weise zu gestalten.
Mehrere sehr gut geschriebene Artikel über CSS.
Artikel, Demonstrationen, Browserbugs und mehr.
Ein wöchentliches Onlinemagazin mit Artikeln, die das Design, die Entwicklung und die Bedeutung von Webinhalten erforschen, speziell mit dem Fokus auf Techniken und Vorteile des Designens mit Webstandards.
Eine Mailingliste für alle Webschaffenden. Meistens werden auf der Liste Themen des Webdesign und der Webentwicklung diskutiert.
Die offizielle W3C-Spezifikation.
Eine Website mit einer großen Sammlung an Tutorials, Referenzen und Artikeln über HTML und CSS.
Joe Clarks Buch über Zugänglichkeit im Onlineformat.
Mark Pilgrims Buch über Zugänglichkeit.
Die offiziellen Richtlinien des W3C für zugängliche Websites.
Eine Informationssammlung des W3C über Werkzeuge, mit denen sich die Zugänglichkeit von Websites bestimmen und verbessern lassen.
“Das Web Standards Project ist eine Graswurzelkoalition, die für Standards kämpft, die für alle den einfachen, günstigen Zugang zu Webtechnologien sicherstellen.”
MACCAWS’ Mission ist Webautoren die notwendigen Resourcen zur Verfügung zu stellen, damit diese ihren Kunden Webstandards als kommerziell-sinnvolle Wahl präsentieren können. Zwei sehr bemerkenswerte Dokumente von MACCAWS sind What Every Web Site Owner Should Know About Standards: A Web Standards Primer und The Way Forward with Web Standards.
Dave Sheas Führer für jeden, der mit dem Einsatz von Webstandards beginnen möchte.
Die offizielle W3C-Spezifikation.
Eine Website mit einer großen Sammlung an Tutorials, Referenzen und Artikeln über HTML und CSS.
Kommentare, Fragen oder Vorschläge? Bitte lass’ es mich wissen.
© Copyright 2004 Roger Johansson