Tim Tepaße: HTML 5? XHTML 5?

Beitrag lesen

Hallo,

Sollte ich wenn ich ein Projekt aufziehe weiterhin XHTML 1.0 Trans nehmen oder kann ich schon auf HTML 5 zählen? Wie sieht es da mit der Browserkompatiblität aus und Was ist mit XHTML 5? gibt es das?

(X)HTML 5 ist bislang nur in kleinen Stücken in Browsern implementiert. Es geht da schließlich nicht nur um einzelne neue Elemente, sondern um Javascript-APIs und größere neuere Modelle. Strukturelle Elemente sind in dem Sinne kein Aufwand und „funktionieren“. Größtenteils.

Der Internet Explorer hat Probleme, ihm unbekannte Elemente zu rendern. Allerdings gibt es eine Merkwürdigkeit: erstellt man solche unbekannten Elemente mittels in Javascript mittels document.createElement("article"); dann kann der IE diese Elemente nutzen und rendern. In allem Browsern gilt, dass die neuen Elemente noch keine Default-Darstellungsregeln im Browser-Stylesheet besitzen. display:block; und vernünftige Regeln für den margin sind also notwendig.

Elemente, die nicht nur strukturieren, sondern, die auch ein spezielles Rendering und Handling besitzen wie <video>, <canvas> oder <datagrid> sind nicht so leicht browser-übergreifend zu nutzen. Teilweise gibt es Skript-Lösungen, die mit versucen Funktionalität in minderen Browsern wie dem IE nachzubilden, teilweise (schon fast absurde) Verschachtelungen von Fallback-Varianten wie hier für <video>.

Ich würde Dir raten, wenn Du unbedingt willst, die strukturierenden Elemente mit obiger Starthilfe zu nutzen, dazu noch den Doctype und <meta charset="...">. Was darüber hinaus geht, ist browserübergreifend noch nicht wirklich nutzbar, höchstens, wenn man sehr genau weiß, was man tut. Die in der HTML 5 Galerie verlinkten Webseiten beschränken sich meist auch nur auf diese kleine Teilmenge.

•••

XHTML 5 ist HTML 5 nur in XML formuliert, mehr nicht. Es gibt aber einen großen Unterschied zu XHTML 1.x; es soll immer als XML versendet und verarbeitet werden. Das soll heissen, es wird mit dem MIME-Typ „application/xhtml+xml“ versandt, der Browser wirft darauf hin seinen XML-Parser an und verarbeitet es als XML, nicht mit dem SGML-ähnlichen HTML-Parser. Letzterer wird verwandt, wenn eine Resource mit dem MIME-Typ „text/html“ versendet wird. Das Problem ist wieder einmal der Internet Explorer; dieser verarbeitet „application/xhtml+xml“-Dokumente nicht als Webseite sondern als potentiellen Download. In der Realität ist „application/xhtml+xml“ also leider nicht nutzbar. Dazu gibt es das Problem, dass als XML verarbeitete XHTML-Dokumente bei nur einem (Flüchtigkeits)-Fehler im Browser die Verarbeitung abbrechen. Das will man oft nicht. Effektiv ist XHTML im Web heutzutage kein wirkliches XHTML sondern nur HTML mit XHTML-Syntax.

XHTML-Syntax ist jedoch in HTML-5-Syntax zu Teilen erlaubt, Dinge wie <br /> und ähnliches. Dies ist dafür da, dass die derzeit fälschlich mit „text/html“ versendeten XHTML-Dokumente auch als richtiges HTML 5 gelten - man will nicht einen Großteil des Webs vor den Kopf stoßen. Die Frage für den Webseiten-Ersteller ist nun, ob man trotzdem XHTML-Syntax verwenden, das Dokument aber als „text/html“ versenden will. Dazu gibt es zwei Gedankengänge. Der eine wird hier im Forum von molily ausgedrückt: Man kann das X(HTML)-Dokument in der Erstellung oder in der Erarbeitung auf seine Qualität kontrollieren, z.B. durch Validierung mit XML Schema, das nach sehr viel mehr testen kann, als der normale HTML-4-Validator. Dazu kommt damit die Einhaltung von strengeren Syntax-Standards. Für ihn ist also nicht die Übertragung und die Webseite im Browser relevant, sondern das auch sehr wichtige „davor“. (Hier schildet molily die Beweggründe ausführlicher; hier gibt es ein Beispiel.) Die andere Position, die zum Teil ich auch einnehme ist, dass das nicht  unbedingt so wichtig ist. Zum einen, weil ein guter Web-Entwickler Qualitätsstandards automatisch einhält, schon allein, weil ihr im Laufe der Jahre Postel's Law verinnerlicht hat. Zum anderen, weil der HMTL-5-Validator immer besser wird. Aber beides ist eine Einschätzung, die aus der persönlichen Erfahrung kommt: molily hat nach eigener Aussage ständig mit diversen HTML-Code aus den unterschiedlichsten Quellen zu tun; ich weniger. Dass da ein Bedürfnis nach automatischer Qualitätssicherung besteht, ist sehr leicht nachzuvollziehen.

Die serverseitige Verarbeitung und Qualitätskontrolle ist der wesentliche Punkt, wo man einen Vorteil durch das XML in XHTML erhält. Wenn man das nicht hat, braucht man auch nicht unbedingt XHTML zu nutzen. Aber andererseits hat man dadurch auch keine Nachteile.

•••

(Und nebenbei würde ich auch dringends von @target abraten. Ich bin eigentlich recht entspannt, bei Webseiten, die anders sind, als ich sie in einer perfekten Welt machen wollen würde. Das target-Attribut ist jedoch nur nervig; dies, weil es nicht nur in die Webseite im Viewport eingreift, sondern in meine private Organisation von Tabs und Fenstern. Und da gehören Aktionen einer Webseite m.E. nicht hin.)

Tim