Hier wird ausgenutzt, dass der IE eine ganz eigene, völlig vermurkste Vorstellung von Namensräumen besitzt. Der XHTML-Namensraum wird angegeben, weil HTML-Elemente diesem angehören. Allerdings könnte der Namensraum auch kuddeldimuddel heißen. Es wäre das selbe Ergebnis. Der Namensraum hat keine Bedeutung in diesem Trick.
Falsch. Er muss 'http://www.w3.org/1999/xhtml' heißen.
Daniel hat hier über den IE und diesen Namespace-Hack gesprochen, mit dem man ihm angeblich HTML5 beibringen kann. Und er hat darin Recht. Der IE verarbeitet die Elemente nicht, weil sie im XHTML-Namespace liegen, sondern weil sie in irgendeinem anderen Namespace liegen. Sprich, damit der Hack funktioniert, könnte man auch folgendes schreiben:
<html xmlns:foo="foo"><body>
<foo:section>...</foo:section>
</body></html>
Klar, wenn dieser Code als XHTML5 verarbeitet werden WÜRDE, wäre section kein Element aus dem HTML-Namensraum. Aber bei dem Hack geht es eben NICHT darum, korrektes oder gar sinnvolles XHTML5 zu schreiben. Und es geht auch nicht darum, korrektes HTML5 zu schreiben. Denn ein HTML5-Parser wird obiges section-Element ebenfalls nicht als HTML erkennen, die (hier falsche) Namensraum-Angabe spielt dabei bekanntlich keine Rolle.
Bei dem Code handelt es sich weder um HTML(5) noch um XHTML.
Falsch. Es ist sowohl als auch. Es ist XHTML5.
Es wäre XHTML5, wenn es in Browsern auch als solches verarbeitet werden würde.
Vorwärtskompatibel ist das leider auch nicht, die so erstellten Elemente sind keine HTML(5)-Elemente sondern generische, bedeutungslose Elemente.
Falsch.
Was er damit meinte, habe ich auch in https://forum.selfhtml.org/?t=202812&m=1370510 beschrieben.
(...) sind völlig äquivalente XML-Dokumente.
Das ist schön, aber wir reden hier von HTML5 als text/html. Da nützt es nichts, wenn das Dokument, wenn es als XHTML5 verarbeitet werden WÜRDE, Markup aus dem HTML-Namensraum enthält.
<article/>
und<foo:article/>
sind bei Verarbeitung als 'application/xhtml+xml' völlig äquivalente XHTML5-Elemente, wenn dem Präfix 'foo' der Namensraum 'http://www.w3.org/1999/xhtml' zugeordnet wurde.
Das hat auch niemand bezweifelt. Dieser IE-Hack ist nur in der XML-Theorie stimmig. Wobei, noch nicht einmal das: Man würde niemals ohne Not solchen Code schreiben. Eine XML-Praxis gibt es derweil nicht: Aus naheliegenden Gründen wird niemand diesen Code als application/xhtml+xml an XHTML-fähige Browser ausliefern. Das gab es vor 10 Jahren bei XHTML 1.x nicht und niemand wird es ohne Vorteile für XHTML5 plötzlich einführen. Es wäre auch absurd. Den ganzen Zirkus veranstaltet man gerade wegen einem Browser, der weder HTML5 noch XHTML5 kann. Wieso sollte dieser Hack sämtliche anderen Browser betreffen, die unbekannte Elemente wie durch HTML5 vorgeschrieben parsen.
Ich verstehe nicht, warum dieser Hack eine solche Faszination ausübt. Ich vermute, weil da unglaublich mit Nebelkerzen geworfen wird. Es wird suggeriert, man würde XML-Namensräumen und XHTML5 nutzen. Dabei will man eigentlich nur einen unerklärlichen Bug im IE ausnutzen. Der ist an sich nicht zu rationalisieren. Trotzdem versucht man, das als XHTML5 zu verbrämen. Das zieht aber nur weitere Nachteile und Widersprüche nach sich.
Dass XHTML erste Wahl ist, sagte ich schon.
Okay. Darf ich dich auf das Thema des Threads hinweisen? ;)
Mathias