application/xhtml+xml und HTML-Seiten als text/html ausgeliefert werden. Ein gutes PHP-Skript, dass diese Aufgabe erledigt, gibt es auf keystonewebsites.com.
Man kopiert sich das Code-Schnipsel in eine Datei und bindet diese dann ganz an den Anfang der Seite (vor <head>) ein. Abhängig vom User Agent liefert das Skript dann den richtigen Header aus. Für User Agents, die kein application/xhtml+xml können, wird der XHTML-Code HTML-kompatibel gemacht; aus <br />s werden dann z.B. <br>-Tags.
Für den "Content-Type"-Teil in den Meta-Tags kann man auf die Variablen $mime und $charset zurückgreifen:
<meta http-equiv="Content-Type" content="<?php echo $mime; ?>; charset=<?php echo $charset; ?>" />
Defined tags for this entry: Webdesign
1
Garvin: Zwar fixt das Script Probleme ungeschlossener Tags, ABER:
1. Es behebt keine anderen XML Probleme. Ungültige Entities (das beliebte www.bla.de/?id=1&nix=2) werden weiterhin ein Rendern der Seite unmöglich machen, da die XML-Engine der Browser meckert.
2. Es startet output-Buffering und durchsucht den gesamten Output nach fehlerhaftem XML ab. Das ist zum einen sehr performanceintensiv, und unterbindet zum anderen HTTP Chunked Encoding, da die gesamten HTML Daten erst nach vollständiger Abarbeitung der Seite gesendet werden.
Mein persönliche Fazit ist, solange xhtml+xml-Seiten immer noch so leicht zu einer vollständig undarstellbaren Webseite in Browsern führen, dies nicht zu nutzen. Zumindest bei dynamischen Webseiten, wo leicht mal ein Fehler einschlüpft. HTML ist immer sehr fehlertolerant gewesen, und der xhtml+xml Schritt macht diesen zentralen Aspekt derzeit noch zunichte.
2
alp: Ein einem CMS wäre ich auch vorsichtiger beim Einsatz eines solchen Skriptes; aber für statisches leichtes Zeugs hat es sich gut bewährt.
HTML ist immer sehr fehlertolerant gewesen, und der xhtml+xml Schritt macht diesen zentralen Aspekt derzeit noch zunichte.
Wem sagst du das ... ist das Teil erst mal drin, versteht der Validator nur noch HTML4. Dafür verweigert dir der xhtml+xml-kompatible User Agent jeden Dienst, wenn etwas nicht sauber gecoded ist.
3
Sascha Carlin: Bei aller Liebe, korrekter Code hilft so lange nicht, wie das Ergebnis nicht zufriedenstellend ist. Und so lange solche Verrenkungen nötig sein, um 100% sein zu wollen, bin ich lieber nur 80%.
Weißt schon, mit 20% 80% erreichen und so
4
molily: Was ich bei der Sache nicht verstehe: Scripte, die ein XHTML-Dokument wahlweise als text/html oder application/xhtml+xml ausliefern, gibt es schon länger. Das neue ist hier: Das Markup wird zu HTML 4 umgeformt. Warum überhaupt? XHTML 1.0 kann auch problemlos als text/html ausgeliefert werden. Das funktioniert in der Praxis aber faktisch genauso gut wie HTML 4.
Das Problem ist, man kann ein XHTML-Dokument nicht einfach in ein HTML-4-Dokument umwandeln, indem man das Dokument durchläuft und einfach /> durch > ersetzt. Ein HTML-Dokument mit xmlns="http://www.w3.org/1999/xhtml" und xml:lang="de" ist auch Unsinn. Daher verstehe ich gar nicht, wieso diese umständlige Lösung mit dem Output Buffer gewählt wird.
Was auch fehlt, ist der Hinweis, dass man gleichzeitig Styles und Scripte schreiben muss, die in beiden Modi funktionieren.
5
Marcus: Dazu kommt die Frage nach der Sinnhaftigkeit. Ja, application/xhtml+xml ist dann sinnvoll, wenn das XHTML-Dokument MathML ausliefern soll. Aber in einer Website, die auch noch wesentlich schneller gerendert wird, wenn sie einfach in text/html ausgeliefert wird (vgl. incremental display & loading von XML-Dokumenten)? Und nur weil im Accept-Header application/xhtml+xml steht?
Ich verstehe auch nicht, weshalb das Script auf HTML 4 zurückfällt, zumal eine Weiche auf XHTML in text/html auch nicht die fix_code-Funktion ausführen müsste.
6
Marcus: Ach so, und den Validator würdde ich über den User-Agent abholen. Der W3C-Validator versteht nämlich application/xhtml+xml