XHTML ist die XML-Variante von HTML. Das bedeutet, dass alle Elemente von HTML 4.0 in XHTML so definiert sind, dass sie den Vorgaben und Anforderungen von XML entsprechen. XHTML 1.0 ist damit eine Anwendung von XML.
Der Vorteil: Durch XHTML wird es für Browser-Hersteller schwieriger, mit proprietären Erweiterungen aus den Vorgaben des W3C auszuscheren. Die XHTML-DTD schreibt genau vor, in welcher Form die einzelnen Tags zulässig sind - Raum für Interpretationen bleibt kaum. Für den Programmierer bedeutet das mehr Sicherheit beim Verfassen von Dokumenten. Wenn eine XHTML-Datei funktioniert, arbeitet sie auf sämtlichen Clients.
Ein weiterer Vorteil der Nähe zu XML: Der Code muss wohl geformt sein. Das bedeutet, bei der Syntax des Codes legt XHTML weit strengere Maßstäbe an als HTML. Für die Clients hat dies weniger Aufwand zur Folge: Der Internet Explorer und in einigen Fällen auch der Netscape Navigator lassen viele HTML-Schlampereien durch. Der hierfür erforderliche fehlertolerante Code ist Ballast, der bei einem reinen XHTML-Browser nicht erforderlich ist.
Änderungen in XHTML
Die aus HTML bekannten Tags bleiben praktisch unverändert erhalten. Ein <table> funktioniert genauso in XHTML wie in HTML, auch die "Entities", Zeichendefinitionen wie ö oder ö ändern sich nicht. Der einzige Unterschied ist, dass jedes XHTML-Dokument auf einer DTD (Document Type Definition) basiert.
In XHTML gibt es drei DTDs: Strict, Transitional und Frameset. Strict ist die Variante der Wahl, wenn moderne HTML-4-Dokumente inklusive Stylesheet-Anweisungen nachgebaut werden sollen. Transitional sorgt für die Rückwärtskompatibilität von Dokumenten und bedient auch Clients, die nichts mit Stilvorlagen anfangen können. Frameset schließlich steht für Dokumente, die eine Rahmendefinition, also ein Frameset, bestimmen. Die Beschreibungen sehen so aus:
<!DOCTYPE
html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<!DOCTYPE
html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!DOCTYPE
html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
Eine einfache Beispieldatei in XHTML unterscheidet sich von ihrem HTML-Pendant nur in den Kopfzeilen:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/ DTD/strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Hallo Erde</TITLE>
</head>
<body>
<p>Willkommen bei<a href="https://www.tecchannel.de/link.cfm?type=page&pk=45"> tecChannel.de</a>.</p>
</body>
</html>
XHTML fordert Programmierdisziplin
Beim Programmieren von XHTML-Seiten ist jedoch mehr Disziplin gefordert. XHTML-Programmierer können es sich nicht mehr leisten, zum Beispiel ein <p>-Tag zum bloßen Trenner für Absätze zu degradieren. Außerdem gilt es, alle Attribute und Werte in Anführungszeichen zu schreiben. Mit der Verschachtelung bestimmter Elemente ineinander ist es ebenfalls vorbei. XHTML definiert einige strikte Verbote.
Diese untersagen allerdings nur Aktionen, die ohnehin unsinnig sind. Nur haben manche Browser die Fehler meist nicht bemerkt oder moniert. Die Verbote sind:
Das Anchor-Tag a darf keine weiteren Anchor-Tags enthalten.
Das Tag pre darf keine Elemente der Typen img, object, big, small, sub oder sup enthalten.
Label- und Formelemente können nicht mehr ineinander verschachtelt werden.
Innerhalb einer Button-Definition dürfen keine Tags wie input, select, textarea, label, button, form, fieldset, oder iframe vorkommen.
Diese Restriktionen bieten eine deutliche Arbeitserleichterung für Programmierer. Dank der engeren Vorgaben lassen sich viele Fehler vermeiden, die man früher erst auf den zweiten Blick bemerkte. Vor allem ist es mit dem XML-basierenden Ansatz endlich möglich, vernünftige Debugger für XHTML-Seiten zu schreiben. Sie untersuchen anhand der Vorgaben in der DTD die Syntax eines XHTML-Dokuments, um Fehler schon während der Entwicklung zu erkennen.
HTML-Seiten auf XHTML vorbereiten
Bis sich XHTML durchsetzt, wird es noch eine Weile dauern. Dennoch können Sie sich schon jetzt auf den neuen Standard vorbereiten. Mit ein paar Grundregeln lässt sich HTML-4-Code so gestalten, dass Sie ihn später mit minimalem Aufwand auf XHTML umstellen können.
Wenn Sie Auftragsarbeiten an HTML-Programmierer herausgeben oder selbst programmieren, achten Sie darauf, dass Sie nur noch wohl geformten, also den XML-Konventionen entsprechenden Code bekommen. Beachten Sie dabei die folgenden Punkte:
Jedes Tag muss ein Abschlusstag haben. Besonders gilt dies bei Absätzen. Diese beginnen immer mit einem p-Tag und enden mit /p. Wenn Sie einen leeren Absatz einbauen wollen, verwenden Sie die HTML-Schreibweise p und /p an Stelle der XML-Version p /. Die XML-Fassung ohne Inhalt kann auf Browsern zu Fehlinterpretation führen.
Leere Elemente, die bislang ohne Abschlusstag verwendet wurden, benötigen jetzt eine Schlussmarke. Diese bekommt in XML immer einen Querstrich nach dem eigentlichen Tag: br / oder hr /. Diese Tags funktionieren bereits mit den aktuellen Versionen des Internet Explorer und des Netscape Navigator. Achten Sie aber darauf, vor dem / ein Leerzeichen einzufügen.
Setzen Sie alle Werte oder Attribute in Anführungszeichen. Das gilt auch für Zahlenwerte. Beispiele:
<table rows="5" cellpadding="3"> oder <td align="right">
Vermeiden Sie Zeilenumbrüche sowie mehrere Leerzeichen in Tags und zwischen den Attributen.
Weitere Umstellungsregeln
Achten Sie darauf, Tags richtig zu verschachteln. Konstruktionen wie
<p>Das ist ein Absatz <b>mit Fettschrift</p></b>
sind nicht erlaubt und führen in Zukunft zu Fehlermeldungen. Korrekt lautet die Syntax:
<p>Das ist ein Absatz <b>mit Fettschrift</b></p>
Attribute dürfen nicht mehr abgekürzt werden. Selbst dann, wenn Parameter und Attribut gleich sind. Nach der neuen Definition lautet die korrekte Schreibweise:
<dl compact="compact">
Gleiches gilt auch für das Attribut "checked" bei Radio-Buttons in Formularen. Damit es keine Probleme mit dem Bezug auf Elemente Ihres HTML-Dokuments gibt, sollten Sie sowohl ID wie auch name gleichzeitig nutzen:
<img id="bild" name="bild" ....>
Um bereits geschriebenen HTML-Code für XHTML vorzubereiten, ist das Tool Tidy eine große Hilfe. Der Syntaxchecker merzt unsaubere Programmierung in XHTML-Dokumenten aus.
Modularisierung von XHTML
Nach den Vorstellungen des W3C wird die Portabilität ein zentrales Charakteristikum von XHTML sein. XHMTL soll in Zukunft eine breite Vielfalt von Geräten bedienen - von Taschencomputern über Mobiltelefone und Fernsehapparate bis zu stationären Computern.
Um diese Endgeräte unterschiedlichster Leistungsklassen ansprechen zu können und die verschiedenen Bedürfnisse von Nutzern, Entwicklern und Designern zu befriedigen, hat sich das W3C entschlossen, XHTML in "handliche Module" aufzusplitten. Diese werden zum Entwickeln von Subsets und Erweiterungen verwendet. Damit werden Entwicklern standardisierte Bausteine für das Erstellen von Inhalten an die Hand gegeben.
So würden beispielsweise einfache WAP-Handys dann nur wenige Module unterstützen, High-End-Mobilgeräte wie PDAs oder spätere UMTS-Geräte entsprechend mehr und stationäre PCs wiederum umfangreichere Module als Mobile Devices.
Vor allem Herstellern von Browsern für alternative Endgeräte wie Handys oder Handheld-Computer bringt die Modularisierung Vorteile: Die Devices verfügen meist nur über begrenzten Speicher oder geringe Rechenleistung. Die Software in den Geräten wird durch die strikten XML-Regeln effizienter, weshalb weniger Programmieraufwand erforderlich ist. Gleichzeitig können die Browser die Seiten besser an die speziellen Eigenschaften der Geräte anpassen, da die Spezifikation viel genauer ist.
Modul-Philosophie
Die grundlegende Philosophie hinter der XHTML-Modularisierung ist schnell erklärt. Ein basales Grundgerüst von XHTML-Kernmodulen ermöglicht die Entwicklung von XHTML-konformen Markup-Sprachen. Jede dieser neuen Sprachen muss dieses Grundgerüst enthalten. Zusätzlich können sie andere XHTML-Module verwenden, vom W3C definierte Module oder auch vom Autor spezifizierte Module, die korrekt definiert wurden.
All diese Module lassen sich innerhalb des XHTML Framework zusammenfügen und legen so eine neue, aufgabenspezifische Markup-Sprache fest, mit der sich portabler, XHTML-konformer Content entwickeln lässt, der auf jedem XHTML-konformen Client einsetzbar ist. Dadurch, dass man die Elemente beliebig kombinieren und selbst eigene Module schreiben kann, sind auch herstellerspezifische Erweiterungen beispielsweise von Netscape oder Microsoft absolut legal und vertragen sich besser mit dem Konkurrenz-Browser als bisher.
Abstrakte und DTD-Module
Das W3C hat eine ganze Reihe von Dokumenten publiziert, in denen unterschiedlich leistungsfähige XHTML-Markup-Sprachen definiert werden. Das hierfür relevante Grundlagendokument mit dem Titel Modularization of XHTML schafft die normative Basis zur Modularisierung. Das Dokument legt auf einem sehr abstrakten Level fest, wie XHTML-Module definiert werden und zerlegt XHTML 1.0 in Pakete von Elementen und Attributen. Sie beinhalten die Kernmodule, die in allen XHTML-Dokumenttypen enthalten sein müssen und die auf sämtlichen XHTML-konformen Systemen laufen.
Die Modularisierung besteht aus zwei verschiedenen Modultypen. Man unterscheidet:
Abstrakte Module zur abstrakten Beschreibung von Gruppen von Elementen, Attributen und Inhalten.
DTD-Module zur Implementierung der abstrakten Module.
Die Spezifikation der abstrakten Module legt alle Datentypen fest und teilweise die Werte, die diese Datentypen annehmen können. Dazu gehört beispielsweise das Strukturmodul, das die wichtigsten Elemente wie Body oder Head von XHTML-Dokumenten definiert. Eine detaillierte Beschreibung dieser Datentypen kann man auf der entsprechenden W3C-Seite einsehen.
Abstrakte Module im Überblick
Die Implementierung der abstrakten Module erfolgt in Form von XML-DTDs. Ein DTD-Modul besteht aus einem Satz Elementtypen, einem Satz Attributlisten-Deklarationen und einem Satz Content-Model-Deklarationen. Dies gibt dem Anwender die Mittel an 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 lediglich an spezielle Hardware-Plattformen auszuliefern.
Modulname | Elemente | Modul für |
|---|---|---|
| ||
Structure | body head html title | Elemente für das Grundgerüst eines XHTML-Dokuments. |
Text | abbr acronym address blockquote br cite code dfn div em h1 h2 h3 h4 h5 h6 kbd p pre q samp span strong var | Block- und Inline-Elemente, die Text enthalten können und logische Auszeichnungen darstellen. |
Hypertext | a | Anker und Verweise. |
List | dl dt dd ol ul li | nummerierte (Aufzählungs-) Listen. |
Object | object param | Multimedia-Referenzen. |
Presentation | b big hr i small sub sup tt | visuelle Darstellungen, physische Auszeichnungen |
Edit | del ins | Änderungsmarkierungen im Text. |
Bidirectional Text | bdo | mehrsprachige Dokumente mit unterschiedlicher Schreibrichtung. |
Forms | button fieldset form input label legend select optgroup option textarea | Formulare und Formularelemente. |
Table | caption col colgroup table tbody td tfoot th thead tr | Tabellen und Tabellenelemente. |
Image | img | Grafikreferenzen. |
Client-side Image Map | area map | Grafiken mit verweis-sensitiven Flächen. |
Server-side Image Map | ismap (bei img) | Grafiken mit verweis-sensitiven Flächen, in Kommunikation mit dem Webserver darzustellen. |
Intrinsic Events | on (Event-Handler-Attribute) | Event-Handler, die eine Schnittstelle für Script-Sprachen bilden. |
Meta-Information | meta | Meta-Daten für Suchmaschinen und Browser. |
Scripting | noscript script | Script-Bereiche und Bereiche für Browser, die keine Scripts ausführen. |
Stylesheet | style (Element) | Bereiche, in denen Stylesheet-Formate definiert werden. |
Style-Attribute | style (Attribut) | Style-Attribut |
Link | link | logische Beziehungen zu anderen Dateien. |
Base | base | Adress- und Zielfensterbasis. |
Ruby Annotation | ruby rbc rtc rb rt rp | Textform für fernöstliche Sprachen, um Silben- oder Wortzeichen mit zusätzlichen semantischen Hinweisen zu versehen. |
XHTML Basic
Die erste, auf Basis der XHTML-Modularisierung definierte, aufgabenspezifische Markup-Sprache ist XHTML Basic. Die Motivation für XHTML Basic bestand darin, einen XHTML-Dokumenttyp bereitzustellen, der von allen Gemeinschaften geteilt werden kann und der gleichzeitig reich genug ist für einfaches Content Authoring. Die Sprache ist vor allem für speicherarme Kleingeräte geschaffen worden, zum Beispiel für Handys, PDAs oder Pager. Entsprechend ist die Basic-Variante der "kleinste gemeinsame Nenner" - quasi die "Mobilausgabe" - von XHTML.
Die W3C-Spezifikation definiert den XHTML-Basic-Dokumenttyp auf der Grundlage der Modularisierung und beinhaltet die Module, die mindestens erforderlich sind, um ein Dokumenttyp der XHTML-Muttersprache zu sein. Zusätzlich enthält er Grafiken, Formulare, grundlegende Tabellen und Objektunterstützung.
XHTML Basic kommt an Einfachheit und Kompatibilität den frühen Versionen von HTML gleich und bildet eine gemeinsame Grundlage. Diese kann erweitert werden. So lässt sich zum Beispiel ein Event-Modul, das umfassender ist als das traditionelle HTML-4-Event-System, einfügen. Eine weitere häufig genutzte Möglichkeit ist ein Scripting-Modul.
Nicht unterstützte Elemente
In XHTML Basic werden diejenigen Eigenschaften nicht unterstützt, die für Geräte mit kleinen Displays unangemessen sind. Im Detail sind dies die folgenden:
Viele einfache Web-Clients können nur Einschrittschrift (Monospace) anzeigen. Bidirektionaler Text, fettgedruckte Schrift und andere erweiterte Schriftelemente werden deshalb in der Basic-Version nicht unterstützt. Externe Stylesheets sind erforderlich. Das link-Element kann zum Aufruf von externen Stylesheets verwendet werden.
Normalerweise haben kleine Endgeräte begrenzten Speicher und begrenzte Rechenleistung. Da der Inhalt auch lesbar sein sollte, wenn Scripts nicht ausgeführt werden, ist die Ausführung von Script-Programmen auf solchen Geräten in der Basic-Variante nicht möglich. Die XHTML-Elemente script und noscript fallen deshalb weg.
Da Tabellen auf kleinen Geräten schwer darstellbar sind, werden nur grundlegende XHTML-Tabellen unterstützt. Das gilt auch für Formulare, da nur Geräte mit einem lokalen Dateisystem Vorteile aus Datei- oder Grafikeingabetypen in Formularen ziehen können.
Frames sind stark von der Bildschirmgröße abhängig und werden daher ebenfalls nicht von XHTML Basic unterstützt.
Basic-Elemente und -Module
Alle in XHTML Basic zusammengefassten Module und ihre Elemente sind in der folgenden Tabelle aufgelistet.
Modulname | Elemente |
|---|---|
| |
Structure | body, head, html, title |
Text | abbr, acronym, address, blockquote, br, cite, code, dfn, div, em, h1, h2, h3, h4, h5, h6, kbd, p, pre, q, samp, span, strong, var |
Hypertext | a |
List | dl, dt, dd, ol, ul, li |
Forms | form, input, label, select, option, textarea |
Table | caption, table, td, th, tr |
Image | img |
Object | object, param |
Meta-Information | meta |
Link | link |
Base | base |
XHTML Basic wird zum Teil bereits eingesetzt. So kann der in den Mobiltelefonmodellen Nokia 6210 und 7190 verwendete Mikro-Browser nicht nur mit WML geschriebene Seiten anzeigen, sondern er kommt auch mit XHTML zurecht. Unter www.nokia.com/xhtmldemo findet sich ein Demo, das die Möglichkeiten von XHTML demonstriert. Auch Microsofts Mobile Explorer unterstützt neben WML bereits XHTML.
Neben Nokia haben auch Motorola, Ericsson, Siemens und zahlreiche andere Mobilfunkunternehmen zugesichert, dass sie XHTML als künftiges Format für Mobilfunkdienste unterstützen werden. Die Firmen kündigten an, dass sie Produkte, Inhalte und Dienste auf XHTML-Basis entwickeln werden.
XHTML 1.1
Ein weiterer, auf der Modularisierung von XHTML beruhender Dokumenttyp, ist XHTML 1.1. Unter dem Titel XHTML 1.1 - Module based XHTML hat das W3C offiziell einen neuen Dokumenttyp definiert, der auf den Modulen der Modularisierungs-Definition beruht. In diesem Dokumenttyp werden die Module aus der XHTML-Modularisierung in einer Markup-Sprache zusammengefügt, die als Basis für künftige XHTML-Entwicklungen dienen soll.
Bei XHTML 1.1 handelt es sich im Wesentlichen um eine Neuformulierung von XHTML 1.0 unter strikter Nutzung der Module. Dies bedeutet, dass viele Features des XHTML-Dokumenttyps wie Frames in diesem Dokumenttyp fehlen. Diese Features sind erst über Module verfügbar, wie sie in der Modularisierung von XHTML festgelegt sind. Autoren können selbstverständlich auch eigene Dokumenttypen definieren, die auf XHTML 1.1 basieren und diese Features nutzen.
XHTML 1.1. soll sich insbesondere durch die Streichung von deprecated-Elementen (deprecated = missbilligt), die in HTML 4 beziehungsweise XHTML 1.0 noch geduldet waren, als sauber definierte Grundlage für Weiterentwicklungen positionieren. Wegen der Streichung aller deprecated-Elemente sowie auf Grund der Forderung nach Stylesheets und der damit strikten Trennung zwischen Inhalt und Layout kann XTHML 1.1 als ein echter Neuanfang bezeichnet werden.
Content-Entwickler, die ihre Inhalte auf XHTML 1.1 aufbauen, können darauf vertrauen, dass sie auf allen Plattformen einsetzbar sind, die XHTML unterstützen. XHTML-1.1-Dokumente werden zum einen auf historischen und existierenden Browsern problemlos dargestellt. Da sie per Definition gültige XML-Dokumente sind, können sie zum anderen aber auch von XML-Suchmaschinen und anderen Technologien verarbeitet werden.
Fazit
XHTML ist ein neuer Ansatz des W3C, um endlich die teilweise unkontrollierte Entwicklung des World Wide Web in den Griff zu bekommen. Nachdem man mit den 3er Versionen von HTML den Browser-Herstellern hinterherhinkte und mit HTML 4.0 den Status quo festklopfte, weist XHTML in die Zukunft. Und im Gegensatz zu früheren Vorschlägen zu HTML hat XHTML das Zeug, sich wirklich durchzusetzen. Denn an XML wird kein Software-Hersteller vorbeikommen. Und wo XML ist, funktioniert auch XHTML.
Allerdings kann XHTML nur ein Übergangsprodukt auf dem Weg zur kompletten Umstellung der Webdaten in XML sein. Denn die in XHTML umgeschriebenen HTML-Tags sagen nach wie vor nur etwas über das Aussehen eines Objekts aus, jedoch nichts über dessen Inhalt oder über die Struktur einer Datei.
Einen echten Fortschritt stellt das Konzept des modularisierten XHTML dar. Der modulare Aufbau erlaubt den Clients, nur die Bestandteile von XHTML zu verwenden, die sie benötigen. Außerdem befreit der neue XHTML-1.1-Ansatz von den drei unterschiedlichen Document Type Definitions und kommt mit nur noch einer DTD aus. Dies garantiert laut dem W3C, dass sich XHTML 1.1 auf wirklich allen XML-fähigen Clients einsetzen lässt. Inwieweit sich das Konzept der Modularisierung durchsetzen wird, bleibt abzuwarten. Zumindest im Mobilbereich dürfte XHTML künftig eine entscheidende Schlüsselrolle einnehmen und aktuelle Konkurrenten wie das altbackene WML ablösen. (ala)