XHTML - eine Einführung - oder:
Warum diese Webseite in HTML 4.01 geschrieben wurde

»XHTML ist im Kommen. XTHML ist die Zukunft.«

So ähnlich liest man es fast überall.
Aber was bedeutet dieses mysteriöse X vor dem HTML eigentlich?
XHTML=»Extensible Hypertext Markup Language= Erweiterbare Hypertext-Auszeichnungssprache«.
Klingt gut.

»XHTML ist eine Neuformulierung von HTML auf der Basis von XML.«
So. Aha. Aber was ist nun schon wieder XML?
XML=»Extensible Markup Language«.
Es ist eine Metasprache, die bestimmte Regeln für Auszeichnungssprachen aufstellt. Bisher gab es zwar schon SGML, das jedoch komplizierter im Regelwerk ist und nicht mehr zeitgemäß erschien. HTML zum Beispiel ist eine Anwendung, die auf SGML beruht.
In XHTML sind die Regeln strenger und eindeutig. Jedes Element, das aufgemacht wurde, muß auch wieder geschlossen werden. Ebenso müssen Elemente logisch verschachtelt werden. Das nennt man Wohlgeformtheit. Also:

<element1><element2>Hier dann der Inhalt</element2></element1>.

XHTML sieht ähnlich aus wie HTML, hält sich aber streng an XML-Regeln und wird mit einem XML-Parser geparst. XML-Parser wiederum sind streng und können im Gegensatz zu üblichen HTML-Render-Engines nur wohlgeformte Dokumente anzeigen. Bei einem Fehler der Wohlgeformtheit brechen sie den Parse-Vorgang ab und geben eine Fehlermeldung aus.

»Was für Vorteile hat denn nun XHTML?«

XHTML ist kompatibel mit anderen XML-Anwendungen, so z.B. MathML, eine mathematische Auszeichnungssprache, Ruby oder SVG. Es können dann einfach Anwendungen in diesen Sprachen in eine Webseite eingebaut werden und vom Browser angezeigt werden.
Endlich kann ich auch komplizierte mathematische Formeln online stellen! ;)

Bis hier hin klingt ja alles prima und es spricht auch alles dafür, XHTML zu verwenden. Sauber, logisch und kompatibel mit anderen Anwendungen.

»Und wo ist dann der Haken?«

Zur Demonstration habe ich mal eine .xhtml-Seite abgespeichert und hier hochgeladen.
Öffnet sie mal mit verschiedenen Browsern. Na?
FF — kein Problem. Opera — kein Problem. IE — nanu? Die Seite wird nicht geöffnet — er bietet sie zum Download an?
Ja — genau. Der IE kann kein XHTML! Auch nicht die »neueste« Version 6.0.
»Aber es gibt doch tausende von XHTML-Seiten im Netz, und die werden auch vom IE geöffnet!« höre ich Euch sagen.
Tja, es sind strenggenommen keine XHTML-Seiten. Es sind HTML-Seiten mit falscher Syntax, weiter nichts. Sie werden mit dem falschen MIME-Typen ausgeliefert.

»Was ist denn nun schon wieder ein MIME-Typ?«

Jede Ressource hat einen bestimmten MIME-Typ. Der MIME-Typ sagt dem Empfänger, welcher Art ein Dokument ist, welchen Parser er verwenden soll und welche syntaktischen Regeln dabei gelten. HTML-Seiten haben text/html, JPEG-Bilder haben image/jpeg, Flash hat application/x-shockwave-flash usw. Und XHTML hat eben application/xhtml+xml.
Woher weiß der Browser den MIME-Typ? Normalerweise wird der MIME-Typ vom Server per HTTP angesagt, notfalls wird er durch die Dateiendung bestimmt (vor allem,wenn kein Server zwischengeschaltet ist auf dem heimischen Computer. So werden .php-Seiten nach dem Parsen meist als text/html weitergereicht an den Browser. Dazu braucht man auch nichts einstellen, das ist schon so vom Provider auf dem Server voreingestellt.
Webseiten, die mit XHTML-Doctype geschrieben wurden, werden meistens einfach als .html abgespeichert und so auch an den Browser übergeben. Der denkt dann natürlich, es sei ganz normales HTML und behandelt es entsprechend. Da so viel Unterschied ja nicht besteht und die Browser eh so programmiert sind, HTML-Fehler möglichst zu übergehen, wird die Seite auch meist wunschgerecht angezeigt. Auf diese Weise kann man auch eine Seite mit XHTML-Doctype an den IE ausliefern. Aber richtiges XHTML ist das natürlich nicht. Und die Vorteile, eben das eXtensible, fehlen auch. Es ist einfach nur falsches HTML. Denn strenggenommen würde zum Beispiel nach SGML-Regeln bei einem <br /> der Slash bereits das Element schließen. Allerdings macht das kaum ein Browser, und somit wird der Betrachter im Allgemeinen von den vielen überflüssigen > verschont. Wie gesagt sind die Browser-Render-Engines schließlich auf Fehlerkorrektur programmiert.

»Kann man denn heute schon richtiges XHTML benutzen?«

Kann man schon. Dazu muß man allerdings serverseitig abfragen, ob der jeweilige Browser XHTML-fähig ist oder nicht, und dementsprechend den MIME-Typen ausgeben lassen. Gute Browser bekommen dann echtes XHTML, der IE und andere Krücken bekommen HTML vorgesetzt.
Erlaubt ist dieses Vorgehen bei XHTML 1.0 nach den Kompatibilitätsrichtlinien, die in Anhang C beschrieben sind.
XHTML 1.1 dagegen sollte explizit nicht als text/html ausgegeben werden. Daher sollte man es heute auch noch nicht einsetzen.
Hier ein PHP-Script, mit dem man eine solche Abfrage starten kann.(Vielen Dank an Thomas Scholz):


<?php
function ua_accepts_xhtml() {
    /* Prüft, ob an den UA XHTML ausgeliefert werden darf.
     * Gibt TRUE zurück, wenn ja, FALSE, wenn nicht. */

    /* In dubio pro HTML. */
    $xhtml = FALSE;
    $check_pattern = '|application/xhtml\+xml(?!\s*;\s*q=0)|';

    /* Behauptet der UA, XHTML zu können? */
    if (($_SERVER['SERVER_PROTOCOL'] == 'HTTP/1.1') and
        isset($_SERVER['HTTP_ACCEPT']) and
        preg_match($check_pattern, $_SERVER['HTTP_ACCEPT'])) {
            $xhtml = TRUE;
    }
    /* Ältere Geckos haben ein paar Crashbugs mit XHTML. */
    if(isset($_SERVER['HTTP_USER_AGENT'])) {
        if(preg_match("|rv\:0.9|", $_SERVER['HTTP_USER_AGENT'])) {
            $xhtml = FALSE;
        }
    }
    return $xhtml;
}

/* Anwendung. */
$content_type   = ua_accepts_xhtml() ? 'application/xhtml+xml' : 'text/html';
header('Content-Type: ' . $content_type . ';charset=utf-8');
header('Vary: Accept, User-Agent');
header('Cache-Control: private');
?>

Dieses Script berücksichtigt auch, dass Netscape 6 noch kein XHTML kann, obwohl er es behauptet. Dieser Browser wird zwar nicht mehr viel benutzt, aber ganz ausschließen sollte man seine User dann doch nicht.
Hier habe ich einmal eine solche Testseite hochgeladen: Testseite mit unterschiedlicher MIME-Typ-Ausgabe je nach Browser.
Besonders interessant ist es, die unterschiedliche Fehlerbehandlung zu beobachten. Dazu habe ich hier ein Beispiel, bei dem ein <br> statt eines <br /> eingefügt wurde. Der IE übersieht den Fehler (eigentlich ist es ja für HTML auch keiner!), gute Browser hingegen zeigen dann die Seite nicht mehr an und weisen auf den Fehler hin.

Eine weitere Möglichkeit wird auf dieser Seite beschrieben - sie ist noch eleganter: Browser, die es können, bekommen dann XHTML, alte Browser bekommen dagegen echtes HTML 4.01, die nötigen Änderungen im Quelltext werden dann dynamisch durch das Skript generiert.

»Ist das nicht ziemlich aufwändig?«

Ja. - Und deshalb ist diese Seite in HTML 4.01 Strict geschrieben. Unter Normalbedingungen rendern alle Browser die Seite im standardkonformen Modus, ich schreibe ordentliches und valides HTML und benutze CSS zum Gestalten.
Das verstehen alle Browser und auch alternative Anzeigegeräte problemlos.
Da ich nicht so viele mathematische Formeln anzuzeigen habe, keine SVGs benutze, und auch sonst keine XML-Anwendungen in die Seite einbauen möchte, vermisse ich XHTML auch nicht.

Zudem kann es trotz allem Probleme mit der Rückwärtskompatibilität geben. So gibt es im IE einen Bug, der gelegentlich dazu führt, dass nur ein XML-Parsebaum dargestellt wird (Stichwort: Content-Negotiation), und auch in Formularen kann es Probleme geben, weil alte Browser die Langform (z.B. checked="checked")nicht kennen.
Wer Javascript einsetzt, wird feststellen, dass viele Scripte nicht mehr funktionieren — so kann zum Beispiel kein HTML mehr mit document.write ausgegeben werden. Genaueres steht bei Ian Hickson: Why document.write() doesn't work in XML.

Doch im Jahre 2012, wenn der letzte IE6 ausgestorben ist, dann werde ich auch wieder XHTML benutzen, ganz bestimmt.

Denn XHTML ist die Zukunft, nicht die Gegenwart.

Weiterführende Links:

Autorin dieses Artikels: Teresia Kuhr