Web-Kurs: HTML-Validator
Es gibt zwei Dinge, die professionelle Web-Designer fürchten: Netscape 4.x und HTML-Validatoren.
Programme zum Erkennen von Fehlern in HTML-Dokumenten gibt es schon fast seit den ersten Web-Editoren. Mit der zunehmenden Komplexität der Web-Seiten nahmen auch die möglichen Fehlerquellen zu. Einen Ausweg boten die Web-Browser: Netscape und Microsoft bauten etliche Sicherheitsnetze auf, damit auch übelster HTML-Code sauber dargestellt wurde. Oft liegt es auch an dem HTML-Code, wenn ein alternativer Browser die Seite nicht richtig darstellt.
Nun sind aber schon seit einiger Zeit neue Anzeigegeräte für Internet-Seiten verfügbar. Nicht alle Geräte können einen kompletten Internet Explorer und Mozilla unterbringen. Zwangsläufig wird dabei auch an der Fehlerkorrektur gespart, denn trotz RAM-Inflation werden in solchen Geräten selten mehr als 64 MB eingebaut " die sich dann auch noch verschiedene Funktionen teilen (Digitalkamera, MP3-Player). Auch die Browser-Vielfalt steigt in letzter Zeit spürbar an: Apple bläst zur "Safari", der Marktanteil der Mozilla-Browser steigt langsam an und dann gibt es auch noch auf mehreren Plattformen eine norwegische "Opera".
Damit werden auch HTML-Validatoren interessanter. Statt die HTML-Dateien manuell zu überprüfen und mit den W3C-Spezifikationen zu vergleichen, geben Validatoren gleich Hinweise auf Fehlerquellen.
Bekannte Validatoren
Atari-Besitzern dürfte wohl der CAB-Smiley bekannt sein, hinter dem eine einfache Überprüfung der Seite steckt. Als vollwertiges Überprüfungsprogramm ist er nicht zu gebrauchen, denn schließlich soll die Überprüfung nicht die Darstellung der Internet-Seiten ausbremsen. Für eine gründliche Überprüfung ist CAB daher ungeeignet.
Ähnliches gilt für die Test-Funktion von HTML-Help, die mehr oder weniger der von CAB entspricht und hauptsächlich für Light of Adamas-Benutzer eingebaut wurde.
Als nächstes gibt es HTML-Tidy, ein verbreitetes Kontroll- und Korrektur-Tool, das unter der Obhut des World Wide Web Consortium entwickelt wurde. Tidy ist sehr umfangreich und kann auch Seiten korrigieren. Immerhin ist es so leistungsfähig, das es auch in einigen kommerziellen Produkten eingebaut ist ("Macromedia HomeSite").
Kurioserweise gibt es vom W3C noch einen Validator, der nur überprüft aber nicht korrigiert. Der HTML-Validator arbeitet online und eignet sich so besonders für dynamische Seiten.
Ebenfalls online ist Bobby. Bobby ist ein spezialisiertes Überprüfungsprogramm, das sich dem Thema Accessibility (wir berichteten) widmet. Eine Bobby-Ausgabe ist eine Sammlung von Fehlermeldungen und gut gemeinten Ratschlägen. Es gibt sowohl einen kommerziellen Bobby-Client als auch eine Online-Version, die kostenlos ist. Ob die kommerzielle Version ihr Geld wert ist, bleibt fraglich: die Ausgabe von Bobby überschneidet sich mit dem HTML-Validator.
In medias res
Letzterer vergibt bei erfolgreichem Bestehen das Prädikat "HTML 4.01 compliant". Eine Atari-Seite, die diesen Kriterien entspricht und aus mehr besteht als einer Seite Text mit fünf Links, ist die Up-to-Date-Liste.
In der ursprünglichen Version hat der Validator um die 30 Fehler ausgespuckt. Bei der Anzahl der Fehler könnte man sich schon fragen, wie so eine Seite überhaupt korrekt angezeigt werden kann. Die Lösung liegt im Sprachstandard selber, denn mit HTML 4.01 hat das W3C zwar viele Tags und Attribute angekündigt, aber gleichzeitig andere als "unerwünscht" bezeichnet. Mit anderen Worten: wer ein böses Tag oder Attribut benutzt, wird vom Validator angemahnt.
Sie finden den HTML-Validator unter www.w3.org. Auf der linken Seite gibt es einen Link zum HTML-Validator. Der möchte nun wissen, ob er eine Internet-Adresse oder eine lokale Datei überprüfen soll. Bei letzteren ist es noch wichtig, die Einschränkungen für dynamische Seiten zu beachten, denn wenn sich PHP- oder ASP-Befehle darin befinden, könnte dies den Validator täuschen und eine falsche Fehlerliste provozieren.
Für den Einstieg wurde www.st-computer.net überprüft. Bei Drucklegung sollten aber nicht mehr alle Fehler auftreten, die das W3C-Tool bemängelt hat.
Kurz nach dem Starten der Überprüfung erschien jedoch nicht die Anzahl der Fehler, sondern ein...
Fatal Error
Der Validator drückt sich zuweilen etwas dramatisch aus. Bei diesem fatalen Fehler wird bemängelt, das der Dokumententyp nicht definiert ist. Dieser legt fest, um was für ein Dokument es sich handelt. Bestimmte Programme können so herausfinden, ob das Dokument in HTML 2.0, 3.2 oder 4.01 geschrieben ist. Letzterer Standard ist noch einmal unterteilt in Strict (extrem strenge Auslegung der HTML-Sprache), Transitional (Standard) und Frameset (enthält Frames). Für den designierten HTML 4-Nachfolger XHTML sind ebenfalls einige Dokumententypen vorhanden.
Ein geeigneter Browser würde für jeden Dokumententyp den geeigneten Parser starten. In der Praxis sieht es eher so aus, dass die Browser nur zwischen HTML und XHTML unterscheiden. Wer seine Seiten in XHTML verfassen möchte, sollte aber wissen, das dort die Regeln für die Schreibweise von Tags und Attributen wesentlich strenger ist als die von HTML. Dafür gibt es die (bisher noch weitgehend ungenutzten) Möglichkeiten von XML und die eventuell höhere Darstellungsgeschwindigkeit eines in XHTML geschriebenen Dokuments " schließlich muss ein XML-Parser nicht mehr so viel Zeit in das Ausbessern von Fehlern investieren.
Is' was Doc?
Um endlich eine Liste von "Fehlern" zu bekommen, gibt es zwei Möglichkeiten. Als erstes kann im Validator der Dokumententyp eingestellt werden. Damit können die verschiedenen Dokumententypen ausprobiert werden, eine eventuelle Einstellung im Dokument selber wird ignoriert.
Da auf der st-computer-Seite noch kein Typ definiert ist, wird das nachgeholt. Die Webseite verwendet Style-Sheets, keine Frames und keine besonderen multimedialen Eigenschaften. Damit stehen zwei HTML4-Untertypen zur Auswahl: Strict und Transitional.
Der große Unterschied ist, das Transitional auch noch die "unerwünschten" HTML-Tags als erlaubt ansieht: <B>, <U>, <APPLET>, <FONT> und <CENTER>. Zu der Liste gehören noch einige weitere, die jedoch kaum noch eingesetzt werden. Bei Strict müssen diese Tags durch Style Sheets bzw. andere Tags ersetzt werden. Statt <APPLET> wird das <OBJECT>-Tag benutzt. Hinzukommt das viele Attribute, die sich auf das Layout beziehen, ebenfalls durch Style Sheets ausgewechselt werden müssen. Ältere Browser stören sich zwar nicht sonderlich an Style Sheets, aber die Seite wird unter Umständen sehr langweilig aussehen, da jede Texthervorhebung entfällt. Zumindest so genannte Inline-Style Sheets scheinen bald in HighWire Einzug zu halten, denn Stile, die sich leicht umlenken lassen:
<td style="height:50%;width:100%">
sind noch relativ einfach zu implementieren. Die einzige volle CSS-Unterstützung ist momentan für Light of Adamas 2.0 vorgesehen. Da CSS über die Möglichkeiten von HTML-Tags wie <FONT> weit hinausgeht, ist es verständlich, das LoA sich verzögert.
Es spricht nichts dagegen, eine Seite zunächst auf HTML 4.01 Transitional zu optimieren. Später kann immer noch auf Strict umgeschwenkt werden.
Entity
Der nächste größere Fehler befand sich in den Grafiken für den ICQ-Status:
http://web.icq.com/whitepages/online?icq=7777777&img=5
Der Validator stört sich an &img, das er als Entity interpretiert (ähnlich wie ", & etc.). Ein &img existiert jedoch nicht und deshalb erscheint eine Fehlermeldung. Das Kaufmannsund ist beim Übergeben von Parametern jedoch sehr beliebt. Wenn die Seite die den Parameter ausliest auf dem eigenen Server liegt, ist die Lösung relativ einfach " das "&" wird durch ein anderes Zeichen ersetzt. Die UTD-Liste benutzt das Semikolon:
http://www.st-computer.net/uptodate/show.php?prog=emutos;typ=os
Beim ersten Link geht das natürlich nicht so einfach, denn wer hat schon Zugriff auf die Dateien des ICQ-Servers? Das W3C schlägt vor, alle "&" durch "&" zu ersetzen:
http://web.icq.com/whitepages/online?icq=7777777&img=5
Damit werden auf einen Schlag gleich sechs Fehlermeldungen beseitigt " manche Fehler moniert der Validator gleich mehrfach.
Paragraphen
Zu guter letzt behauptet der Validator, das mehrere Absätze geschlossen, aber nicht geöffnet wurden. Ein Blick in den Quelltext zeigt, das dass nicht stimmt.
<p>DynamiX bietet zahlreiche professionelle Mastering-Funktionen, die es laut
der Entwickler bisher auf dem Falcon nicht gab und die mit weitaus teureren
Produkten auf anderen Plattformen durchaus konkurrieren können. Es bietet
die im Masteringprozess wohl wichtigsten Funktionen:
<ul> <li>Lautheitsmaximierung und </li> <li>Stereo-Enhancing.</li> </ul> Ausführliche Informationen finden Sie auf der Webseite der Entwickler. </p>
Der Validator besteht auf einer sauberen Trennung der Absätze und auch einen Web-Browser ist es einfacher, wenn alles voneinander getrennt ist. In diesem Fall wird "</p>" hinter "Funktionen:" geschoben und der Satz unter der Liste wird mit "<p>...</p>" eingeschlossen. Das nun die Liste nicht mehr innerhalb eines Absatzes steht, ist nicht tragisch, denn es gehört zu den Elementen, die einen Absatz erzeugen.
Ähnliches auszusetzen hat es auch an Tabellen innerhalb von Absätzen. Diese erzeugen zwar nicht zwangsläufig einen Absatz, sollten jedoch nicht in <p>-Tags eingeschlossen werden.
Damit wäre zumindest die News-Seite gültiges HTML 4.01. Als nächstes habe ich mir eine meiner eigenen Seiten vorgenommen, "mypenguin.de/prg/".
In Anführungszeichen
Dabei ist dann auch eine kleine Schludrigkeit herausgekommen. HTML-Validator spuckte die Meldung "an attribute value must be a literal unless it contains only name characters" aus. Damit ist gemeint, das ein Attributwert, der in Anführungszeichen gesetzt werden müsste, ohne diese geschrieben wurde. Auf der Seite kam folgendes vor:
<tr bgcolor=#eeeeff>
richtig ist:
<tr bgcolor="#eeeeff">
Fehlende Attribute
Ein häufiger Fehler sind fehlende Attribute. Seit HTML 4 werden bestimmte Attribute zwingend verlangt. Viele HTML-Editoren fügen diese auch automatisch ein.
Ein bekanntes Beispiel ist das "ALT"-Attribut, mit dem ein alternativer Text für Bilder festgelegt wird. Dieses Attribut ist für alle Bilder zwingend, unabhängig davon, ob das Bild relevant ist oder nicht. Das gilt auch für so genannte "Fill"- und "Spacer"-GIFs, deren einziger Zweck es ist, Platz zu schaffen. Kommt jedoch ein Text-Browser auf die Seite, wird er versuchen, das Alt-Attribut auszulesen. Fehlt es, erscheint bspw. der Text "[IMAGE]". Wenn das Attribut zwar vorhanden, aber leer ist, soll gar nichts angezeigt werden. Das ist bei Platzhalter-Grafiken auch durchaus sinnvoll, da sie keine bedeutsamen Informationen enthalten.
Du bist voll mein Typ!
Unter die fehlenden Attribute fallen auch mangelnde Typ-Bezeichnungen. Style Sheets werden gerne so notiert:
<style>
.kopf {
text-decoration: none;
}
</style>
Im eröffnenden <style> fehlt das "type"-Attribut, damit klar ist, welche Style Sheet-Sprache verwendet wird:
<style type="text/css">
Empfehlenswerter ist es natürlich, Style Sheet-Definitionen grundsätzlich in einer externen Datei zu speichern. Gleiches gilt für Skripte.
Skripte benötigen ebenfalls eine Angabe des MIME-Typs. Das "language"-Attribut ist hingegen vom W3C gar nicht gerne gesehen:
<script language="JavaScript1.2">
Die Angabe der verwendeten Sprache war ursprünglich dafür gedacht, Browser auszuschließen, die z.B. nur einen älteren JavaScript-Sprachstandard unterstützen. Darauf konnte man sich aber noch nie verlassen " so unterstützt der Internet Explorer etliche Befehle des Sprachstandards 1.2, andere wiederum nicht. Natürlich könnten einfach zwei Skripte angelegt werden " eins für den IE, das andere für Netscape. Das funktioniert jedoch schon innerhalb der Netscape-Produktfamilie nicht mehr, von alternativen Browsern wie Opera, Safari, iCAB und Light of Adamas mal ganz zu schweigen. Intelligenter ist es, das Vorhandensein von einzelnen Funktionen abzufragen:
if (document.getElementById) { ... }
Damit wird die Versionsangabe der verwendeten Skript-Sprache überflüssig. Die Sprache wird im Mimetype festgelegt:
<script type="text/javascript">
Zukünftig werden sich noch viel mehr verschiedene Sprachen innerhalb eines (X)HTML-Dokuments tummeln. Der designierte Nachfolger von HTML 4.0, XHTML, erlaubt schon heute das Einbinden von Formeln in MathML oder Vektorgrafiken im SVG-Format.
Browser-Erweiterungen
Bei der Entwicklung von HTML gab es mehrere Browser-Erweiterungen, die zunächst von Netscape bzw. Microsoft eingebaut und erst später in den HTML-Standard aufgenommen wurden. Frames kamen auf, als HTML 2.0 der Sprachstandard war. Aufgrund der zögerlichen Entwicklung drohte die Weiterentwicklung des Sprachstandards dem W3C zu entgleiten. HTML 3.0 war schließlich eine ganze Ansammlung von neuen Ideen, wie etwa Fußnoten oder ein anderes <IMG>-Tag (<FIG>). Der Sprachstandard war jedoch ein einziger Fehlschlag und es gab nur einen Exoten-Browser, der einen Großteil von HTML3 unterstützte. HTML 3.2 orientierte sich schon mehr an der Wirklichkeit, während bei HTML4 viele Erweiterungen der Browser-Hersteller aufgenommen wurden " darunter IFrames und "normale" Frames.
Es wurde jedoch nicht alles aufgenommen, darunter einige Attribute, die Web-Programmierer sehr lieb gewonnen haben. Dazu zählen die ungeliebten Seitenränder, denen mit mehreren Attributen im <BODY>-Tag zuleibe gerückt wird: leftmargin, topmargin, bottommargin, rightmargin, marginheight, marginwidth. Die ersten vier stammen vom Internet-Explorer, die anderen von Netscape. Für Seitenränder ist aber nicht HTML, sondern CSS zuständig. Um die Rahmen mit CSS abzuschalten, müsste das <BODY>-Tag folgendermaßen aussehen:
<body style="margin-left:0px;margin-top:0px;">
Noch besser ist es natürlich, diese Angaben extern in einer CSS-Datei zu machen und auf mehreren Seiten einzubinden.
Denkfehler
Ein HTML-Validator findet auch klassische Denkfehler, so steht bei Yahoo! im Quelltext:
<td align=middle>
Hier lässt sich über die eigentliche Absicht nur rätseln. Wenn der Inhalt vertikal zentriert sein soll, ist der Attributwert zwar richtig, aber der Attributname muss "valign" lauten.
Nehmen wir einmal an, dass der Attributname richtig ist. In diesem Fall stimmt der Wert aber nicht, den um den Inhalt einer Tabellenzelle horizontal zu zentrieren, muss der Wert "center" lauten.
Formulare
Die <FORM>-Tags gehören zu den Elementen, die einen Absatz erzeugen. Damit machen sie sich sehr unbeliebt bei Designern und Programmierern, denn eine kleine Box wird durch den automatischen Absatz zu weit ausgedehnt. Daher gibt es solche Konstrukte:
<tr> <form action="test"> <td><input ...></td> </form> </tr>
Natürlich hätte der Validator die <FORM>-Tags lieber innerhalb von <TD>...</TD>. Eine richtige Lösung gibt es für das Problem nicht, außer, die <FORM>-Tags an eine Stelle zu packen, wo sie weder den Validator noch die Optik stören " z.B. Seitenanfang bzw. Seitenende.
Ein Attribut, das auf der Abschussliste des W3C liegt ist "NAME" im <FORM>-Tag. Das wird vermutlich für jene, die Formulare nur per PHP/CGI/Perl/ASP verarbeiten kaum von Belang sein. Wer allerdings JavaScript benutzt, wird sich fragen, wie er Zeilen wie
document.forms["Beispielform"].submit();
ersetzen soll. Ganz einfach: Jedes Formular erhält eine eindeutige Nummer. Angenommen das Formular ist das zweite in der Datei, muss die neue Fassung lauten:
document.forms[1].submit();
Jetzt wird es Strict!
Die Webseite der st-computer ist also gültiges HTML4.01 Transitional. Beim Umstellen auf "Strict" meldet der Validator für die News-Seite 18 Fehler. Strict trennt streng zwischen Aussehen und Inhalt. Es entspricht damit der reinen Lehre von HTML.
Es beginnt beim <BODY>-Tag. Dort werden die Farben für Text, Links, besuchte/aktivierte Links und die Hintergrundfarbe definiert. Da dies Attribute sind, die das Aussehen betreffen, besteht HTML4.01 Strict darauf, diese als CSS zu schreiben:
<style type="text/css">
body {
background-color:white;
color: black;
}
a:link, a:visited {
color: black;
}
a:active {
color: #999999;
}
</style>
statt:
<body bgcolor="#FFFFFF" text="#000000" link="#000000" vlink="#000000" alink="#999999">
Gleiches gilt auch für Tabellenzellen, denn bei "Strict" ist das "bgcolor"-Attribut nicht mehr erlaubt. Der Vorher-Nachher-Vergleich:
<td bgcolor="#cccccc"> <td style="background-color: #cccccc">
Da die "Strict"-konforme Schreibweise erheblich länger ist, entsteht eine gute Gelegenheit, das Seitenlayout zu durchforsten. Die Webseite der st-computer verwendet für Tabellenzellen auf der rechten Seite immer die gleiche Hintergrundfarbe. Schon deshalb bietet es sich an, die Style Sheet-Definition auszulagern:
<style type="text/css">
.themen {
background-color:#cccccc;
}
</style>
<td class="themen">
Jetzt kommt aber der Schock: nicht nur Farbdefinitionen sind in "Strict" verboten, auch das geliebte "ALIGN"-Attribut gehört zum Alteisen! Hinzu kommen noch "WIDTH" (nur bei Tabellenzellen) und "BORDER" (bei Bildern). Natürlich ist das <FONT>-Tag ebenfalls nicht erlaubt, aber es war von Anfang an eher als Notnagel gedacht, da HTML keine besonderen Formatierungsmöglichkeiten kannte.
Der Ersatz für ALIGN lautet in CSS "text-align", für die Höhe (height) und Breite (width) ändert sich nichts, außer, dass die Angabe in CSS erheblich flexibler ist, da nicht nur Prozent und Pixel als Maßeinheiten erlaubt sind.
"Strict" kennt aber auch das Attribut "target" nicht. Wer also mit Frames arbeitet, muss als Dokumententyp weiterhin "Transitional" oder "Frameset" nehmen.
Alles in CSS auslagern?
Natürlich bietet das Auslagern des Layouts in CSS ungeahnte Möglichkeiten, gerade bei größeren Web-Projekten. Auch die Fehlerkorrektur ist einfacher, die Datei wirkt wesentlich aufgeräumter.
Die hier beschriebenen Style Sheet-Angaben werden von den Browsern der 4er Generation problemlos ausgewertet und auch die erste CSS-fähige Version von Light of Adamas wird diese unterstützen. Die größte Gefahr die bei der Verwendung von CSS entsteht ist, dass die Seite bei alten Browsern etwas fade aussieht, da dann weder Fettschrift noch Hintergrundfarben angezeigt werden. Benutzbar bleibt die Seite in jedem Fall " es sei denn, es wird besonders ausgiebig von dynamischer Positionierung gebrauch gemacht. Bei sehr komplexen Layouts über CSS neigt auch der Netscape 4.0 zu Spinnereien. Allerdings ist es wohl nicht mehr einzusehen, für einen Browser zu entwickeln, der sich kaum an gängige Standards hält und der sich mit seinem Marktanteil inzwischen auch bei den Exoten befindet.
Stolperfallen
Kein Fehler beim Erstellen der HTML-Seite, aber Stolperfallen für Validatoren, sind HTML-Tags, die durch JavaScript eingefügt werden. Kaum ein HTML-Validator versteht JavaScript und interpretiert dann einfach die HTML-Tags im <script>-Bereich.
Bei diesem Problem gibt es nur eine Lösung: die eigenen Funktionen in eine externe JavaScript-Datei ausgliedern und sich in der HTML-Datei lediglich auf Funktionsaufrufe beschränken.
Achtung Umleitung!
Wer arglos "st-computer.net" im Validator eingibt, wird immer eine "Fatal"-Meldung bekommen. Warum eigentlich, wenn doch der Doctype längst eingefügt wurde? Ganz einfach: der HTML-Validator kommt nicht mit Umleitungen zurecht. Wer www.st-computer.net im Browser eingibt, wird automatisch auf www.st-computer.net/news/ umgeleitet. Dem Validator gefällt das gar nicht.
Info: HTML4.01
HTML 4.01 unterscheidet sich nicht stark von HTML 4. Hauptsächlich wurden Unklarheiten in der Dokumentation und Fehler in der DTD berichtigt. HTML 4.01 ist voraussichtlich die letzte Version des klassischen HTML und wird vom abwärtskompatiblem XHTML abgelöst.
Mia Jaap