Nur kurz einer Ergänzung zur Schließung der XHTML2-Arbeitsgruppe: XHTML2 ist zwar damit erledigt, aber XHTML an sich existiert weiterhin und wird auch weiterhin entwickelt. Denn XHTML5 ist ja auch noch da.
XHTML5 ist nichts weiter als HTML5 auf dem XML-Trip. Wenn man ein HTML5-Dokument XML-konform schreibt und es als mit einem XML-Mimetype ausliefert, wird es nicht HTML- sondern vom XML-Parser des Browsers verarbeitet. Außerdem ist es auch möglich, HTML5 in XHTML-Syntax zu schreiben – egal ob <br> oder <br />, erlaubt ist beides. Darüber, ob es am Ende HTML oder XHTML ist, entscheidet am Ende allein der Mimetype (application/xhtml+xml für XHTML, text/html für HTML). Ich weiß zwar immer noch nicht wirklich, warum man XHTML5 benutzen wollen könnte, aber Fakt ist, dass man kann. Wer also immer noch an der XML-Web glaubt, muss sich nicht grämen: XHTML lebt noch, lediglich die Ausfertigung namens XHTML2 musste die Segel streichen.
Passend dazu gerade reingeflattert: An Unnofficial Q&A about the Discontinuation of the XHTML2 WG (via @yatil)
Kommentare (14)
Maik ¶
6. Juli 2009, 12:00 Uhr
Mein bevorzugtes CGI-Programmiermodell ist, auch auf dem Server mit DOM zu arbeiten. Das heißt, ich erzeuge mir mit einer XML-Bibliothek ein Dokument von passendem Typ und arbeite dann mit DOM-Befehlen, um die Elemente zu erzeugen und einzusetzen. Dann habe ich auf dem Server in Perl und auf dem Client in Javascript im Wesentlichen die gleiche Schnittstelle.
Da fällt am Ende automatisch valides XML raus, weil ich an keinem Punkt selber Tags schreibe, sondern einfach im letzten Schritt den DOM-Baum serialisieren lasse. Es wird sogar automatisch valides XHTML 1.1, da ich dafür lediglich als vorletzten Befehl den DOM-Baum gegen die XHTML-DTD validieren lassen muss. Ich werfe dann einen Fehler, anstatt Müll an den Client auszuliefern. Als Content-Type schicke ich allerdings noch text/html, da (wer sonst!) der Internet Explorer das Dokument, obwohl es völlig korrekt ist, einfach nicht anzeigt, wenn application/xhtml+xml geschickt wird.
Ich bin Fan von XHTML und werde auch von HTML5 die XML-Variante verwenden.
Tobias Herkula ¶
6. Juli 2009, 12:23 Uhr
Zitat Maik:
Wenn schon XHTML mit text/html als MIME dann bitte nur XHTML 1.0 Strict, da XHTML 1.1 ganz klar vorraussetzt das es als application/xml oder application/xhtml+xml ausgeliefert wird.
Nichts destotrotz kann man beides ohne Probleme per HTTP-ACCEPT-HEADER anpassbar an den Browser liefern. Dann sieht der IE XHTML 1.0 Strict als text/html und alle guten browser bekommen echtes XML...
Peter ¶
6. Juli 2009, 12:28 Uhr
Zitat Maik:
Wenn du das tust, ist das aber kein XHTML. XHTML5 ist per Definition nur dann XHTML, wenn es einen XML-Mimetype hat.
Zitat Tobias Herkula:
Das geht in der Tat (wobei auch XHTML 1.0 ohne XML-Mimetype eigentlich nicht wirklich XHTML ist). Aber warum sollte man das wollen?
Neb ¶
6. Juli 2009, 13:23 Uhr
"Ich weiß zwar immer noch nicht wirklich, warum man XHTML5 benutzen wollen könnte, aber Fakt ist, dass man kann."
Nun, wenn man das Dokument um etwas erweitern möchte, was nicht in HTML 5 vorgesehen ist, dann führt doch kein Weg an XHTML vorbei, oder?
Wie sieht es denn mit RDFa aus? Wird man das in _X_HTML 5 verwenden können?
Peter ¶
6. Juli 2009, 13:28 Uhr
Zitat Neb:
Dieser Weg führt dann wiederum in weitem, weitem Bogen um den Internet Explorer herum. Und ich weiß ja nicht, wie praktikabel das ist....
In der derzeitigen Fassung von (X)HTML5 nicht.
Maik ¶
6. Juli 2009, 13:31 Uhr
Natürlich ist die Auslieferung als text/html schmuddelig und falsch. Wenns aber beim IE schlicht nicht anders geht, was soll man machen?
Deinen Tipp, Tobias, habe ich aber aufgegriffen und in meiner persönlichen Quellcodesammlung die XML-Auslieferfunktion entsprechend ergänzt, so dass er application/xhtml+xml schickt, wenn der Accept-Header erklärt, dass der Client das versteht. Wenn das nicht der Fall ist, wird weiter als text/html ausgeliefert, auch wenns falsch ist. Mein bisheriger Gedanke war, dass man das bestenfalls am User-Agent-Header auseinandersortieren könnte, was ich noch schmuddeliger fände, als einen falschen Content-Type zu setzen.
Peter ¶
6. Juli 2009, 13:35 Uhr
Zitat Maik:
Absolut nicht! Die Auslieferung von im XHTML-Stil geschriebenen Dokumenten als
text/htmlist völlig korrekt – völlig korrektes HTML, allerdings. Allein die Auslieferung ist maßgeblich für die Behandlung. Das heißt, du machst damit an sich alles richtig, es ist nur kein XHTML :)Maik ¶
6. Juli 2009, 13:53 Uhr
Zitat Peter:
Nicht ganz, denn nicht jedes korrekte XHTML 1.1-Dokument ist valides HTML. Die Auslieferung als
text/htmlempfiehlt das W3C ausdrücklich nur, wenn der Clientapplication/xhtml+xmlnicht versteht und das Dokument den „Compatibility Guidelines“ entspricht. Auf letzteres achte ich derzeit überhaupt nicht, ich serialisiere in beiden Fällen genau gleich. Von daher ist es eigentlich schon falsch – aber das absolute Maximum an Aufwand, das ich für schon stinkende Codeleichen wie den IE zu treiben bereit bin.Axel ¶
6. Juli 2009, 14:30 Uhr
Verstehen die neueren IEs
application/xhtml+xmldenn?Peter ¶
6. Juli 2009, 16:34 Uhr
Nö.
Siegfried ¶
8. Juli 2009, 13:06 Uhr
XHTML (version whatevre) ist XML. Und erlaubt damit Namespaces. Schon die Diskussion darüber mitbekommen, warum HTML5 kein RDFa unterstützen wird? Die Argumente dagegen sind korrekt: Keine Namespaces in HTML.
Umgekehrt, wenn man da konsequent wird, dann werden die Möglichkeiten in XHTML unendlich. Direktes einbetten von SVG, ohne object? In XHTML kein Problem. Ablegen von Metadaten in RDF direkt im Dokument? In XHTML kein Problem. Und so weiter. Hier liegt der eigentliche Vorteil von XHTML gegenüber HTML.
Du hast allerdings Recht, das führt in weitem weitem Bogen um den IE herum.
Du kennst doch sicher den Begriff "graceful degradation". Das besagt in Etwa, wenn ein bestimmter Browser wie z.B. zufälligerweise der IE ein bestimmtes Feature nicht kann, dann bekommen Nutzer des IE die Seite eben in einer weniger prächtigen, aber immer noch nutzbaren Form. Jedenfalls so weit nutzbar wie eben möglich. Mein Rezept dazu: Ich gehe von XHTML aus, lasse aber davon per XSLT eine HTML-Version anfertigen, und biete Beides an (automatic content negotiation). Zur Zeit bekommen praktisch alle Browser HTML, wegen der Einstellungen bei http Accept. Aber das ließe sich ändern. Und XHTML als Quellformat bietet jederzeit die Möglichkeit der automatischen Bearbeitung durch XSLT. Bei HTML ist hier Schicht im Schacht.
Wolf-Dieter ¶
9. Juli 2009, 19:00 Uhr
Mir fällt ein Stein vom Herzen, dass XHTML an sich weiter existiert. Denn ich bin denkfaul.
Hab mein (statisches, client-seitiges) CMS One Hand Content auf XHTML gebürstet, und gut ist.
Peter ¶
9. Juli 2009, 19:02 Uhr
Das würde auch ohne XHTML noch funktionieren. HTML5 schluckt auch XHTML-Syntax.
Siegfried ¶
10. Juli 2009, 07:25 Uhr
Das ist nicht das Selbe. Auch der IE schluckt XHTML. Aber eben nicht als XML, sondern als eine weitere fehlerhafte HTML-Version. Damit ist all das, was durch XML wesentlich mehr und anders ist, für die Füße. Sobald Du mit Namespaces anfängst und diese auch konsequent nuzt, ist hier HTML am Ende. Auch HTML5.