Validen HTML Code sollte man bei einem Profi eigentlich erwarten können, aber wie kommt es, dass auf der Startseite trotzdem 185 Fehler angezeigt wurden? Wie erhalte ich validen HTML-Code auch mit einem CMS und Wysiwyg-Editor?

Verursacht haben die hohe Zahl an Fehlermeldungen beim Markup Validation Check vor allem zwei Dinge, die bei Kontrolle nach der Seitenerstellung hätten leicht vermieden werden können.
1. Der Document-Type war HTML 4.1 eingestellt aber der HTML-Quellcode des Templates war für XHTML geschrieben worden. In der Folge meckerte der Validator jedes „Ende-Tag“ an ( „/“ ) das am Ende eines HTML-Tags wie <meta … /> oder <img … />stand. Da kommt auf einer Seite einiges zusammen.
2. Der zweite Fehler war, dass in einem Modul das den Seiteninhalt darstellt (Content), ein Wrapper um den Inhalt mit <p> … </p> gebildet wurde.  Da der Wysiwyg-Editor mit dem der Inhalt erstellt und bearbeitet wird, ebenfalls noch einen Absatz <p> um jeden Text macht, standen plötzlich zweimal <p><p> nacheinander im Quelltext. Das führte dann zu so kuriosen Erscheinungen, dass die folgenden HTML-Tags in Großbuchstaben angezeigt wurden und das mag XHTML nun gar nicht. Die Löschung des <p>-Wrappers im Modul beerdigte gleich die größte Zahl an Errors im Validator.

Übrig blieb dann nur noch ein einziger Fehler, erzeugt durch eine Tabelle die der Wysiwyg-Editor partout mit HTML-Bezeichnungen wie „width“ und „height“ angeben wollte. Das „height“ wurde vom Validator angemeckert und nach einigem probieren gelang es, dem Editor eine Tabelle ohne diese Auszeichnungen zu entlocken.

Damit war das Dokument valide, eine Arbeit von vielleicht gerade mal 10 Minuten.
Merke: Man sollte auch seine Seite ab und zu einer Kontrolle unterziehen um eingeschlichene Fehler zu finden.

Valides Problem Wysiwyg-Editor und HTML in PHP

Anders als bei einer statischen HTML-Seite pfuschen einem Webdesigner beim erstellen validen Codes noch andere Dinge dazwischen:
Das eine ist der nahezu in jedem CMS übliche Wysiwyg-Editor, der eigenen HTML-Code erzeugt, aber jedoch nicht immer dem neuesten Stand entsprechend oder so wie es der Webentwickler will.
Was heißt WYSIWYG ? Das ist die verkürzte Schreibweise von „What You See Is What You Get“ und heißt übersetzt „Was du siehst ist (das) was du bekommst“. Schön wäre es, aber davon abgesehen versuchen diese Editoren einen Text oder Seiteninhalt möglichst so darzustellen, wie er später aussieht wenn er gespeichert wurde und als Seite angezeigt wird. Auch dieser Text wurde mit so einem Editor geschrieben, in dem Falle ist es der tinyMCE Editor für WordPress.

Was macht der Editor?

Er erzeugt automatisch HTML-Code, damit der Autor so schreiben kann wie er will ohne HTML-Kenntnisse zu haben. Tippe ich auf die Eingabe (Return)-Taste, dann beginnt er einen neuen Absatz, also beendet den ersten Text mit </p> und beginnt einen neuen Absatz (unsichtbar) mit <p> und setzt den Text dort hinein. Solches Verhalten kann in den meisten Editoren irgendwo voreingestellt werden, für den tinyMCE gibt es eine ausführliche Beschreibung.
Da wird es leicht wissenschaftlich und nicht jeder ist in der Lage, sich seien Editor einzustellen.

Ein automatischer Absatz in HTML ist vermutlich das geringste Problem für validen Code, schwieriger wird es, wenn der Editor veraltetes HTML benützt und statt mit Stylesheets die HTML-Tags direkt mit Parameter versieht (z.B. <font size=7 color=red>). Da hilft dann am besten ein Update oder die strikte Vermeidung jeglicher Textformatierungen im Editor (z.B. keine Schrift vergrößern, Schriftart ändern oder farblich darstellen!).
Mit frischem Update und strenge Arbeitsregeln mit dem Editor sollte es möglich sein, validen Code auch valide zu halten. Natürlich muss jeder der am CMS im Inhalt etwas bearbeitet, diese Regeln kennen und befolgen.

Mein CMS macht falsches HTML

Das kam früher sehr oft vor, es ist noch gar nicht lange her, dass die Module oder der Kern des CMS selbst, den HTML-Code erzeugten und das nicht unbedingt in neuerer Version. Irgendwelche HTML-Tags die den Designer arg stören, kamen aus den Tiefen des CMS hervor und nicht selten begann langes Suchen oder resignieren.
Auch machte es nicht unbedingt viel Sinn, den Quellcode eines CMS auf den neuesten Stand in Sachen HTML/CSS zu bringen, denn das nächste Update hatte dann alles wieder überschrieben, sofern man sich die Veränderungen nicht sicherte und später wieder einpflegte.
Das konnte sich schnell zu einer Sisyphos-Arbeit entwickeln bei vielen Installationen und verschiedenen Systemen.
Da war es leichter, mit den Fehlern im Validator zu leben.

Zum Glück hat sich das geändert und moderne CMS benützen meistens eine Template-Engine und halten Programmcode (wie PHP) und Design (wie HTML/CSS) weitgehende getrennt.

Bei Typo3 (TYPO3) hat man eher keine Probleme, validen Code zu erzeugen, da hier nahezu vorbildlich die Trennung angewendet wird. Dank Typoscript kann man den HTML-Wrapper um einen vom CMS ausgegebenen Inhalt beliebig einstellen. Meistens verbirgt sich also das HTML einer Ausgabe dort.
Aber nicht immer, denn Typo3 benützt auch Templates die den HTML-Rahmen für Ausgaben bilden, bei Extensions ist das oft zu finden. Macht also ein HTML-Tag einmal Probleme, dann findet sich das sicher in diesen Templates.

Bei Contenido wird für Module die z.B. Inhalte ausgeben, jeweils ein Modul-Template verwendet das für das HTML zuständig ist. HTML-Layout und Modul-Template ergeben das überwiegende HTML einer Seite (dazu natürlich der Editor). Findet sich also ein unliebsames HTML-Tag nicht im Layout der eigenen Entwicklung, dann findet es sich oft im Template.
In meinem Fall aber war es direkt im PHP-Modul versteckt, wo es den Tabelleninhalt der Datenbank mit einem <p>…</p> einhüllte. Vermutlich habe ich das sogar irgendwann einmal selbst gemacht, aber die Reihenfolge abgeklappert von Layout, Modul-Template zu PHP-Modul und schon war der „Fehler“ gefunden.

Fehlerverursacher

sind nicht oft die Systeme selbst, denn diese werden ständig überarbeitet und Fehler ausgemerzt. Ein Update auf den neuesten Stand wirkt da oft Wunder. Anders sieht das bei extermen Modulen, Plugins, Componenten oder Extensions aus. Diese werden nicht von der Entwicklergruppe des CMS gemacht und nicht immer auf den neueren Stand angepasst. So kann es schon vorkommen, dass so eine Erweiterung noch altmodischen HTML-Code erzeugt, der nun gar nicht in eine XHTML-Doctype passt.
Da hilft dann nur, den Entwickler anzuschreiben und um eine Überarbeitung zu bitten oder die Erweiterung selbst im Quelltext zu durchsuchen und das HTML anzupassen. Natürlich ist dann wieder das Update-Problem…

Als Trost wenn es nicht klappt, alles valide zu bekommen, bleibt das Wissen, dass Profis die Probleme kennen und Arbeitsaufwand zum Nutzen und Wirkung abwägen. Und eine valide Seite macht noch lange keine gute Seite, sie ist dann lediglich richtig codiert.