HTML ist seit 1992 die Auszeichnungssprache des Internets und diente anfangs nur dazu, die Formeln von Forschern plattformunabhängig darzustellen. Mittlerweile ist aus der einfachen Markup-Sprache ein umfangreiches Mittel zur Beschreibung von interaktiven und dynamischen Webinhalten geworden, welches andauernd erweitert werden muss, um den sehr verschiedenen und vielfältigen Wünschen und Bedürfnissen der Benutzer zu entsprechen.
Die ständige Erweiterung und die lockeren Syntax-Regeln liessen dann aber auch ein anderes Problem auftauchen: Da die benötigten Rechen- und Speicherkapazitäten für die Umsetzung eines HTML-Dokuments immer grösser wurden, ist das Einsatzgebiet des ehemaligen Allrounders HTML merklich geschrumpft. Dies war auch ein Grund für die Entwicklung von WAP. Da WAP den strikten Konventionen von XML unterliegt, ist es somit leichter interpretierbar und dadurch auch eine Voraussetzung für kleinere Browser, welche auch auf tragbaren Geräten wie einem Handy eingesetzt werden können.
Die Idee hinter der Entwicklung und Standardisierung von XHTML 1.0 besteht somit vor allem darin, eine Markup-Sprache zu erschaffen, welche plattformunabhängig ist und die Benutzer ohne grosse Einschränkungen an ihre Bedürfnisse anpassen können. So entgehen die derzeitigen Entwickler einerseits dem Druck, andauernd HTML an die aktuellen Gegebenheiten anpassen zu müssen, und andererseits ist es nun möglich, den selben Standard auch für mobile Geräte zu nutzen. Dies wurde erreicht, indem man die Vorteile von HTML 4.01 und XML vereinte.
Die Neuerungen von HTML zu XHTML sind grundsätzlich nicht sehr gross. Die Verschmelzung der XML-Syntax mit HTML bringt vor allem einige Änderungen in der Schreibweise der Tags mit sich.
Eine der wesentlichsten Unterschiede besteht darin, dass Endtags gesetzt werden müssen und Tags klein zu schreiben sind.
Dieses Code-Beispiel ist nach HTML 4.01 korrekt und wird vom Browser auch entsprechend interpretiert. Allerdings ist nicht bekannt, wo der Wirkungsbereich des Tags endet, da der Endtag fehlt. Dies macht das Interpretieren des HTML-Codes unnötig schwieriger, da der Browser "raten" muss, was er jetzt wie darzustellen habe. Die XML-Syntax in XHTML hilft bei diesem Problem weiter und fordert zwingend Endtags, denn dies vereinfacht das Rendern der Seiten.
Weiter ist die Kleinschreibung von Tags und Attributen nun Pflicht, weil dies in der XHTML-DTD festgelegt wurde und in dieser nun einmal alle Tags klein geschrieben wurden. Demgemäss müsste das oben genannte Beispiel wie folgt aussehen:
Nach dem XML-Standard würde auch
korrekt sein, allerdings sollte ein Leerschlag vor dem abschliessenden Slash eingefügt werden, um die Rückwärtskompatibilität zu sichern.
Eine weitere Auswirkung von XML ist die Regel, dass die Tags korrekt verschachtelt werden müssen: Der jüngste Tag muss als erster wieder geschlossen werden.
Das W3C fordert nach neuem Standard, dass die Werte für Attribute mit Anführungszeichen eingegrenzt werden, wobei es unerheblich ist, ob es sich dabei um einfache (') oder doppelte Anführungszeichen (") handelt, so lange überhaupt welche verwendet werden. Dabei ist es aber wichtig, jedes Mal die gleichen zu benutzen. Konstruktionen à la table width= "400' sind nicht erlaubt.
Weiter dürfen nicht wie bisher Attributwerte alleine stehen. So war es bis anhin bei einzelnen Attributen möglich, einfach den Attributwert hinzuschreiben. Dies ist nun nicht mehr möglich. Dafür ist die Änderung ziemlich einfach gehalten: Der Attributwert muss einfach dupliziert und zu einem regulären Attribut umgeschrieben werden, wie es im folgenden Beispiel gezeigt wird.
Schlussendlich müssen noch zwei weiteren Veränderungen vorgenommen werden, um aus einem HTML-Dokument ein vollwertiges XHTML-Dokument zu machen. Als erstes muss eine passende Doctype vor das Root-Element () gesetzt werden. Dies ist nötig, damit der User-Agent (Browser etc.) das vorliegende HTML-Dokument mit der XHTML-DTD vergleichen kann. Wenn der Verweis auf die DTD fehlt oder das XHTML-Dokument nicht korrekt ist, sollte die Seite nicht angezeigt werden, sofern der User-Agent voll XML-kompatibel ist. Drei Varianten sind hier möglich:
Noch bevor die XHTML-1.0-Spezifikation zur Empfehlung erhoben wurde, begann das W3C mit der Entwicklung von XHTML 1.1. Die zentrale Neuerung ist dabei die Teilung der XHTML-DTD in kleinere Untergruppen, also Module, was vom W3C als Modularisierung von XHTML bezeichnet wird.
Diese Module werden zur Entwicklung von Subsets und Erweiterungen verwendet, was besonders im Hinblick auf die Veröffentlichung von XHTML-basierendem Content für verschiedene Zielplattformen wichtig ist.
Eine der Hauptaufgaben der Modularisierung liegt vor allem darin, dass sich die Elemente beliebig kombinieren lassen und man selber eigene Module schreiben kann. Dadurch sind auch herstellerspezifische Erweiterungen beispielsweise von Netscape oder Microsoft absolut "legal" und vertragen sich auch besser mit dem Konkurrenzbrowser als bisher.
Die Modularisierung besteht aus zwei verschiedenen Modultypen: Abstract-Module und DTD-Module. Das DTD-Modul besteht aus einem Satz Elementtypen, einem Satz Attributlisten-Deklarationen und einem Satz Content-Model-Deklarationen.
Das Abstract-Modul definiert bestimmte Daten, die sich semantisch von allen anderen unterscheiden. Dazu gehört beispielsweise das Strukturmodul, welches die wichtigsten Elemente wie Body oder Head von XHTML-Dokumenten definiert.
Dies gibt dem Anwender die Mittel in die Hand, eine speziell für seine Website abgestimmte DTD zu schreiben, welche nur die Elemente enthält, die man wirklich benötigt. Mit Hilfe dieser DTD ist es dann möglich, den Content nur an spezielle Hardwareplattformen auszuliefern.
Wie dies vor sich gehen soll, ist man sich allerdings noch nicht ganz im klaren. Eine Möglichkeit besteht darin, einen Proxyserver vor den Webserver zu stellen und diesen dann auslesen zu lassen, welche Hardwareplattform zugreift. Mit Hilfe eines Parsers und der XHTML-Dokumentmodelle werden dann die Dokumente anhand der DTD aufbereitet und an das Endgerät geschickt.
Ein zweiter Ansatz besteht darin, dass der Client die komplette Seite vom Server bezieht und anschliessend nur jene Code-Zeilen umwandelt, welche für ihn bestimmt sind, was XHTML die nötige Plattformunabhängigkeit und Flexibilität auch ohne übermässigen Geldeinsatz verschaffen würde, was ein grosser Vorteil gegenüber HTML und XML wäre. Ob der dazugehörige Parser direkt in das Lesegerät integriert oder mit jedem Dokument mitgeliefert werden soll, ist noch unklar.
Wer seine HTML-Dateien in "wohlgeformte" XHTML-Dokumente überführen möchte, kann das zum einen von Hand machen und muss die Änderungen vornehmen, wie sie oben beschrieben sind. So lange es sich dabei um wenige Seiten handelt, ist der Aufwand vertretbar. Wer aber mehr als 10 Dokumente zu bearbeiten hat, sollte sich nach einem Konvertierungstool umsehen.
Zu diesem Zweck wurde vom XHTML-Entwicklerteam ein spezielles Programm erstellt, womit sich die HTML-Dokumente mit wenigen Mausklicks in mehr oder weniger korrekte XHTML-Dokumente umsetzen lassen, sofern die Vorlage einigermassen sauber codiert ist (Näheres im Kasten "HTML Tidy").
Die Umstellung besteht aber nicht nur darin, dass der Quellcode nun "wohlgeformt" sein muss, sondern auch zwingend Style Sheets verwendet werden müssen. Dies, weil der font-Tag als erster von vielen schon in HTML 4.0 vom W3C als veraltet deklariert und durch CSS abgelöst wurde. Vor allem Attribute, welche gerne zur Definition von Layouts verwendet werden, beispielsweise table height= "400", fallen nach und nach weg. Wer also auf ein absolut XHTML-kompatibles Dokument angewiesen ist, muss sich damit anfreunden, Designs nur noch in CSS zu definieren.
Die Transitional-DTD räumt aber noch eine gewisse Schonfrist ein, bis sämtliche unerwünschten Attribute verschwunden sein müssen.
Einen komplexen Internetauftritt in XHTML zu konvertieren, ist allerdings wenig ratsam und sollte generell noch einmal überdacht werden, da es mit einigen wenigen Modifikationen im Quellcode nicht getan ist. Wer demnächst ein Redesign plant, sollte aber die Gelegenheit nutzen und den Quellcode XHTML-1.0-konform erstellen lassen.
Wie schon eingangs angesprochen, wird XHTML noch nicht auf breiter Front unterstützt, vor allem die WYSIWYG-Editoren wie Go!Live oder Dreamweaver halten sich nach wie vor zurück. Übrig bleiben nur Code-Editoren, wobei es sich um eigentliche XML-Authoring-Tools handelt.
• XML Spy 3.5: XML Spy ist ein klassisches XML-Authoring-Tool, mit welchem man unter anderem XML-, XHTML-, XSL-, SVG-Dokumente und DTDs erstellen kann. Neben den Standard-Tools sind beispielsweise Validatoren integriert, welche die Wohlgeformtheit und die Übereinstimmung mit der DTD überprüfen, was natürlich die Arbeit sehr erleichtert. Auch ist es möglich, das Schema des Dokuments anzeigen zu lassen. Allerdings ist XML Spy weniger zur Erstellung von XHTML-Dokumenten geeignet als beispielsweise Mozquito Factory, da es sich hauptsächlich um ein Entwicklerwerkzeug für XML und verwandte Sprachen handelt. Wer aber eine DTD erstellen muss, sollte dieses Tool ausprobieren.
• Mozquito Factory 1.5: Als eines der ersten Authoring-Tools, welches speziell auf XHTML ausgerichtet ist, gilt Mozquito Factory. Neben Syntax-Highlighting und Unterstützung für das XHTML-Modul XForms besitzt das Programm eine interessante Arbeitsweise: Das erstellte Dokument wird in JavaScript umgeschrieben und nachher exportiert. Der Code enthält einen speziellen Parser, welcher das Script entsprechend verarbeitet und den fertigen Code anschliessend an den Browser übergibt. Das Programm muss auf dieses umständliche Prozedere zurückgreifen, da die Parser der Browser bestimmte selber erstellte Tags einfach übergehen würden. Durch die Verwendung des Parsers von Mozquito Factory wird dieses Problem umgangen.
Da JavaScript allerdings nicht eine sehr elegante Lösung ist, wurde auch ein entsprechender Server entwickelt, welcher zuerst die Datei konvertiert und dann dem User-Agent zusendet. Dies ist deutliche die sicherere Methode, als den Umweg über JavaScript zu gehen, wie ein kleiner Test im Open-Source-Browser Mozilla 0.92 beweisst: Die Seite bleibt weiss und der Browser verabschiedet sich mit einem Error.
Nach einem Überblick über die Technik, stellt sich die Frage, weshalb XHTML eingesetzt werden soll. Eigentlich bringt XHTML vorläufig nur wenig Vorteile und eher Nachteile, da ein erheblicher Mehraufwand nötig ist, um eine Seite zu entwickeln.
Beispielsweise unterstützt noch keiner der namhaften WYSIWYG-Editoren XHTML 1.0, und auch die Konvertierung zu fehlerfreiem XHTML 1.0 ist nur mit grossem Aufwand möglich.
Wer sich allerdings zur Verwendung von XHTML 1.0 durchringen kann, wird vom andauernden Testen der Webseiten zumindest teilweise befreit, da rein technisch gesehen keine Interpretationsfehler mehr auftauchen können. Wer seine Webdaten zudem plattformunabhängig auf möglichst vielen Endgeräten zur Verfügung stellen möchte, setzt mit XHTML auf die richtige Technologie, insbesondere, wenn neue Sites erstellt werden.
Die Verwendung der Modularisierung von XHTML hat auf jeden Fall zum jetzigen Zeitpunkt wenig Sinn, vor allem, weil sie vom W3C noch nicht als Empfehlung deklariert wurde. Zwar sind auf der Anbieterseite die technischen Möglichkeiten vorhanden, aber geeignete User-Agents, welche ohne überproportionalen Aufwand modularisierte Dokumente anzeigen können, sind auf der Benutzerseite nach wie vor nicht vorhanden.
Allerdings wäre es eine Überlegung wert, ob man statt auf XML auf XHTML setzen möchte, da man in XHTML auch XML-Module einbauen kann. Die enge Verknüpfung zu XML zeigt aber auch, dass XHTML 1.1 nicht gerade für den Hausgebrauch konzipiert, sondern sich vielmehr für die Verwendung in Unternehmen eignet.
