Nach W3C Standard erstellte Seiten sind handwerklich sauber, moderne Browser stellen sie perfekt dar. Dass sich außer wenigen, engagierten Webdesignern und HTML-Bastlern kaum ein Unternehmen dafür interessiert, mag auch an allerlei Legenden haben, die man immer wieder hört. Standardkonforme Seiten sehen langweilig aus
Reiner Unfug. Praktisch jede vorhandene Seite kann standardkonform umgeschrieben werden.

Tabellen sind verboten
Keineswegs. Tabellen sind ebenso Standard wie es CSS Container sind. CSS Container machen Ihnen die Arbeit allerdings leichter. Tabellarische Daten müssen auf jeden Fall in Tabellen Platz finden. Oder haben Sie schon einmal versucht ein Excel-Sheet mit CSS Containern nachzubauen?

Man muss XHTML benutzen
Ob HTML 4.01 oder XHTML 1.0 oder 1.1, es spielt unter diesem Gesichtspunkt keine Rolle.

Ein Fehler genügt und alles ist verloren
Stellen Sie sich die W3C Regeln wie einen Duden vor. Es gibt akzeptierte Regeln und jeder versucht ihnen so nahe wie möglich zu kommen. So wie man in einem längeren Text auch bei bestem Kenntnisstand den einen oder anderen Fehler produziert, trifft das auch auf Webseiten zu. Ein Fehler ist kein Beinbruch. Wichtig ist, die Standards überhaupt erst einmal zu respektieren. Wer sie beherrscht, darf sich gelegentlich auch darüber hinwegsetzen.

Standardkonforme Seiten sind nur in Handarbeit möglich
WYSIWYG-Editoren wie beispielsweise Macromedias Dreamweaver haben kein Problem damit, auch handgearbeitete Vorlagen werden nicht angetastet. Das trifft aber nicht auf jede Software zu. Wer mit Frontpage arbeiten muss, hat keine Chance. Die Hersteller von Content Management Systemen haben das Thema ebenfalls noch nicht für sich entdeckt. Nahezu alle produzieren einen unappetitlichen Codebrei.

Standardkonforme Seiten machen mehr Arbeit
Im Gegenteil. Standards sind die gemeinsame Basis auf der alle Webseiten stehen. Wer sich daran hält, hat weit weniger mit unterschiedlichen Browsern und Browserversionen zu kämpfen. Man muss weniger testen und darf sich obendreien seiner Sache viel sicherer sein.

So mancher Webdesigner lässt sich von Browser eigenen Spezialfunktionen dazu verleiten, selbige auf seinen Webpages weidlich einzusetzen. Die irrige Annahme: Die Besucher werden schon den gleichen Browser besitzen. Das tun sie aber garantiert nicht. Und schon treten Fehlermeldungen auf, oder werden Seiten unvollständig oder zerschossen dargestellt. So reizvoll Spezialfunktionen auch sind - sie sollten für die Benutzbarkeit einer Website besser eine Kann- denn eine Muss-Lösung wählen.

Das W3C legt die Spezifikationen für gültigen HTML-Code (einschließlich Style Sheets) fest. Dahinter steckt die Idee, dass eine regelkonforme Webpage auf allen Browsern gleich aussehen soll. Webdesigner könnten dann auf Spezialtricks für eine einheitliche Browser-Darstellung ihrer Seiten verzichten, was die Webpages vom Umfang des Quelltextes tendenziell schlanker machen würde. Auch der in jedem Webdesign anfallende Cross-Browser-Test sowie das Debugging würden weniger zeitaufwändig ausfallen - von Besucherbeschwerden einmal ganz abgesehen.

Teilweise ist das leider noch Theorie. Ausgerechnet die Browser-Hersteller knüppeln dem Webdesigner regelmäßig zwischen die Beine. Obwohl Microsoft und AOL/Netscape Mitglieder des W3C sind und die Standards mit entwickelt und abgesegnet haben, gehen ausgerechnet ihre Browser bisweilen sehr eigenwillige Wege bei der Interpretation von demselben HTML-Tag.

HTML-Standards sind der einzig sinnvolle Weg, die Verbreitung von "besserem" HTML zu fördern und inkompatible Browser vom Markt verschwinden zu lassen (der grausige Netscape 4 mag hierfür ein gutes Beispiel sein). Und es gibt ja auch ein wenig Unterstützung vom W3C: Das Konsortium bietet einen eigenen Überprüfungsdienst für die Gültigkeit von HTML-Code an. Man kann seine Webpages hoch laden und online prüfen lassen oder sich für den lokalen Einsatz ein kleines Validierungstool herunterladen.

Dokumententyp korrekt definieren
Kein Quellcode ohne die Angabe von DOCTYPE in HTML. Moderne Browser verlangen sogar danach und richten den Modus der Seitenanzeige danach aus.

Zeichensatz korrekt angeben
Es ist nicht nur guter Stil, sondern auch eine Notwendigkeit, dem Browser mitzuteilen, welchen Zeichensatz er für die Darstellung der Inhalte einer Webpage verwenden soll. Dafür ist eine spezielle Meta-Angabe im Dateikopf zuständig:

Häufige Fehler mit HTML
Einsteiger lernen HTML zu Fuß besser, und Profis schätzen die volle Kontrolle über den Quellcode. Beide haben einen gemeinsamen Feind: den Fehlerteufel.

Tippfehler
Falsch geschriebene Tags, wie <tabel> statt <table> werden vom Browser ignoriert - oder als "echter" Text angezeigt. Oft ergeben sich weitere Darstellungsfehler. Während falsch geschriebene Tags eher kosmetische Folgen haben, werden Tabellen meist völlig verhagelt.

End-Tags vergessen
Von wenigen Ausnahmen abgesehen, müssen in einem korrekten Quellcode stets auch End-Tags gesetzt werden. Fehlt er, kann das diverse Kettenreaktionen auslösen, weil nachfolgende Tags auf den vorhergehenden Tag Bezug nehmen. Zerschossene Tabellen haben häufig ein vergessenes </tr> oder </table> als Ursache.

Tags falsch verschachtelt
Es ist nicht nur erlaubt, sondern auch notwendig, Tags zu verschachteln, und zwar von innen nach außen. Wer's falsch macht, löst Folgefehler aus, weil nicht klar ist, welcher Tag vom Browser interpretiert werden soll.

Grafiken werden nicht angezeigt?
Passiert dem Zu-Fuß-Programmierer dauernd. Meist ist ein falsch geschriebener Dateiname oder Pfad der Grund. Korrekte Groß- und Kleinschreibung ist wichtig. Am besten alles entweder groß oder kleinschreiben.

Anführungszeichen bei Attribut-Parametern vergessen
Es ist regelkonform, die Parameter eines Attributs in zwei Anführungszeichen zu setzen; fehlen beide Anführungszeichen, ist das meist nicht schlimm. Fehlt hingegen nur eines, schon eher. Ausgerechnet den sonst fehlertoleranten Internet Explorer bringt ein width="120> so weit aus dem Konzept, dass er den Tag völlig ignoriert und keine Tabelle aufbaut.

HTML-Code wird nicht ausgeführt
Steckt irgendwo im Quellcode der Kommentar <!--, der den nachfolgenden Block deaktiviert?

Unterschiedliche Schreibweisen: HTML vs. CSS
Ähnliche Funktionen müssen keine identische Schreibweise haben: Während HTML das Attribut bgcolor zum Färben des Hintergrund verwendet, heißt es bei Style Sheets background-color. Bei HTML werden Parameter mit dem Gleichheitszeichen übergeben, bei Style Sheets mit dem Doppelpunkt.

Keine Übersicht über den eigenen Quellcode mehr? Leerzeilen im Quellcode können Blöcke optisch trennen; Einrücken hilft, die Struktur von Tabellen mit dem Auge schneller zu erfassen. Hilft auch bei der Fehlersuche.

Die Einschläge rücken näher. Nach und nach beginnen auch größere Websites damit sich vom herkömmlichen Tabellendesign zu verabschieden und setzen auf CSS-Container. Lohnt sich das? Die Magazin-Legende Wired hat es getan, der Stern ebenso wie Hotbot oder die Bundeswehr, sogar die Deutsche Post als Gelbes Schwergewicht setzt auf die konsequente Trennung von Form und Inhalt . Ethische und Moralische Gründe ließen sich anführen, doch der wichtigste Punkt ist auch hier der schnöde Mammon.

Wer CSS-Container verwendet spart nämlich Geld , viel Geld sogar, vorausgesetzt die Serverlast ist hoch, viele Seiten sind vorhanden und diese werden rege abgefragt. Wer damit mangels Masse kein Problem hat, das dürfte für die meisten Betreiber gelten, kann zumindest seinen Besuchern Gutes tun. Denn schlankere Seiten rutschen einfach schneller durch die engen Leitungen. Beim Stern macht das immerhin satte 39% aus. Die Zahl der verwendeten Dateien ist vor allem durch den Verzicht auf BlindGIFs stark geschrumpft.

Die oft angeführte Standardkonformität ist leider nicht mehr als Heuchelei. Denn wirklich standardkonform sind alle diese Seiten nicht. Das hat auch nicht wirklich etwas mit der eingesetzten Technik zu tun, sowohl CSS als auch Tabellen sind Standards. Fehlerfreie Seiten zu produzieren, bleibt eine Herausforderung für die Zukunft.

Dr. Web produziert an die 80 Gigabyte Traffic im Monat. Auch hier konnte die Umstellung einiges sparen. 15-20% liessen sich nach der Umstellung im September 2003 einsparen.

Kleine Websites betrifft das kaum und auch optisch bringt die veränderte Technik keine Vorteile. Tendenziell sehen die umgestalteten Seiten schlichter aus, üben sich in Verzicht. Aber das liegt durchaus im Trend. Grafiklastige Seiten spüren keine Vorteile. Die Angst vor Browserproblemen hingegen ist berechtigt, denn auch moderne Browser sind sich nicht im allem einig, was die Interpretation von Cascading Stylesheets anbelangt.

Vorteile von Containern

• Geringere Dateigrößen sparen Kosten und Ladezeit
• Die logische Struktur einer Seite bleibt erhalten
• Leicht anpassbar durch externe Stylesheets
• Größere Flexibilität in Bezug auf das Ausgabegerät
• Mehr Erfolg bei Suchmaschinen
• Erhöhte Zugänglichkeit

Nachteile von Containern

• Mit WYSIWYG Editoren nicht oder nur teilweise zu erstellen
• Zahlreiche Browser- und Darstellungsprobleme
• Alte Browser zeigen unformatierte Seiten

Der Überblick zeigt: Die Vorteile überwiegen. Änderungen sind leichter durchzuführen, Geräte für das mobile Surfen können leichter bedient werden. Auch wenn es um das Thema Zugänglichkeit geht, haben CSS Container die Nase vorn. Schließlich bedarf es nur eines weiteren Stylesheets, um ein Layout vollständig umzukrempeln.

Fehlerfrei, valide und geprüft, so hätten es viele gern. Doch so ganz einfach ist die Sache nicht. Vor allem dann nicht, wenn man bei Null anfangen muss und sich niemals zuvor damit beschäftigt hat. Der erste Test mit einem Validator lässt die meisten bereits wieder aufgeben. Hunderte von Fehlermeldungen lassen auf ein unmögliches Vorhaben schließen.

Zu erst einmal möchten wir Ihnen die Sache ein wenig schmackhaft machen. Warum sollte man sich diese Arbeit aufhalsen?

Browser zum Beispiel sind ein Argument. Man weiß nie, welche neue Version übermorgen erscheint und wie die eigenen Seiten dann aussehen. Valider Quellcode verleiht einem Sicherheit. Eine Garantie, dass alles in Ordnung ist, die gibt es zwar nicht, doch die Chancen sind deutlich größer. Wenn etwas nicht klappt, dann ist es zumindest nicht Ihre Schuld, sondern liegt am fehlerhaften Browser . Und je sauberer der Quellcode ist, desto einfacher hat es ein Browser, die Seiten korrekt darzustellen.

Sollte einmal ein Experte tief in den Bauch Ihrer Seiten blicken, weiß er Bescheid. Ein valider Code sagt ihm, dass ebenfalls ein Experte am Werk ist.

Fehlerfreie Seiten sind außerdem oft schneller geladen, sind zugänglicher und leichter einzulesen , zum Beispiel für Suchmaschinen - ein wichtiges Argument, wenn eine Website auch Erfolg haben soll.

Also ran an den Speck. Als Maßstab gilt uns der Validator des W3C, jener Organisation, die für die Webstandards zuständig ist.

Bevor Sie Ihre Seiten dort prüfen lassen, sind jedoch einige Vorbereitungen nötig.

1. Eine Seite genügt. Verwenden Sie die Startseite, sofern es sich nicht um eine reine Vorschalt- oder Weiterleitungsseite handelt. Legen Sie eine Kopie an.
2. Sie benötigen ein Werkzeug. Mit MS Frontpage erstellte Seiten können zwar auch nachbearbeitet werden, doch das Programm verwirft Ihre Korrekturen, sobald Änderungen mit Frontpage daran vorgenommen werden. Sie benötigen einen Editor, der Korrekturen nicht verwirft. Dazu reicht im Prinzip ein einfacher Texteditor. Wenn Sie nicht sicher sind, probieren Sie es aus.
3. Räumen Sie auf. Je geringer der Umfang einer Seite, desto schneller klappt es mit der Validierung. Nehmen Sie heraus, was Sie nicht unbedingt benötigen. Später kann man wieder erweitern.
4. Entfernen Sie alle Javascripte.
5. Bestimmte, häufig vorkommende Kleinigkeiten werden vom Validator auf jeden Fall angemeckert. Um diese kann man sich bereits vorher kümmern. Dazu gehört, dass jede Grafik einen Alternativtext benötigt. Das gilt auch für BlindGIFs. Dies ist leicht zu beheben, schreiben Sie in den IMG-Tag einfach ALT="" hinein.
6. Legen Sie mit Hilfe eines Doctypes fest, welche Version von (X)HTML Sie verwenden. Geschieht dies nicht, weigert sich der Validator überhaupt mit der Arbeit zu beginnen.

Soweit vorbereit lassen wir den Ernstfall auf uns zukommen. Ein Validator kennt verschiedene Arten von Fehlern.

• Tags, Elemente und Codes, die ihm unbekannt sind, die nicht zum Standard gehören oder nicht zur angegebenen (X)HTML Version passen.
• Syntaxfehler, das heißt fehlerhaft geschriebene Tags, die manch ein Browser trotzdem zu interpretieren weiß.
• Falsche Verschachtelungen. Manchmal ein großes Problem bei komplizierten Tabellenkonstruktionen.
• Fehlende Abschlusstags.

Einige Beispiele dazu:

end tag for STRONG omitted...
<strong>Text<p>...

Der Abschlußtag wurde ausgelassen.

there is no attribute BGCOLOR
<table border=0 bgcolor=#4a5a74...

Das sieht eigentlich ganz passabel aus. Ist es aber nicht, denn hier wurde dem Validator per Doctype die HTML Version 3.2 vorgeschrieben. Diese kannte aber noch keine Hintergrundfarben für Tabellen.

invalid comment declaration
<!--- Ad-Tag 468x60 --->

Ein falsch geschriebener Tag. Browser stören sich nicht daran, der Validator nimmt es genau. Es muss heißen <-- statt <---

there is no attribute BORDER
<td valign=top border=0 width=50 height=50>

Rahmen für Tabellenzellen kennt HTML nicht, dies wäre nur mit CSS möglich.

there is no attribute FACE
<font size=1 face=Verdana, Arial, Helvetica>

Schlechte HTML-Editoren produzieren so etwas. Korrekt wäre font-face. Font-Befehle gibt es übrigens in der HTML 4 nicht mehr.

Eine falsch verschachtelte Tabelle stellt sich so dar:

end tag for element TD which is not open
...><tr><td>&nbsp;</td></table></tr></td></tr></table>

end tag for element TR which is not open
...<td>&nbsp;</td></table></tr></td></tr></table>

Solche Fehler aufzuspüren ist nicht einfach, der Validator hilft aber dabei.

Findet man den Fehler im wuchernden Code-Dschungel nicht, ist es eine gute Idee, den möglichen Bereich einzugrenzen . Dies tut man, indem man nur mit diesem den Validator füttert, oder Teile der Seite vorübergehend entfernt.

Auch wenn der Einstieg schwierig ist. Jeder aufgespürte und korrigierte Fehler macht die Website besser, jedes gelöste Problem ist ein Schritt nach vorn.