Ich bin zur Zeit viel unterwegs und komme nicht dazu, viel originelles zu schreiben. Also spielen wir einfach das altbekannte Spiel weiter: Leser fragen zu HTML5, CSS3, JavaScript und Co und der Erklärbär antwortet. Denn Fragen kommen jeden Tag bei mir an und weil die meisten dieser Fragen (und Antworten) viel zu schade sind, um sie in meinem E-Mail-Archiv verrotten zu lassen, hole ich sie im Rahmen der Artikelserie „Fragen zu HTML5 und Co“ regelmäßig ans Tageslicht – getreu dem Motto „dumme Fragen gibt es nicht“.

HTML5 in XHTML/HTML 4

Ich habe eine schöne HTML5-Seite gebaut mit schönen HTML5-Formularfeldern und so. Nun soll das Formular aber in eine HTML4/XHTML-Seite eingebunden werden und zwar direkt, nicht per <iframe>. Was kann im schlimmsten Fall passieren?

Passieren kann eigentlich gar nichts, die HTML5-Elemente dürften auch in Seiten mit anderen Doctypes funktionieren. Browsern sind Doctypes nämlich total egal. So lange der Browser in der prinzipiell Lage ist, ein Element zu verarbeiten, wird es tun, egal was in der ersten Zeile der HTML-Seite steht. Als kleine Demo: Ein Canvas-Element in einem Dokument mit dem Doctype HTML 3.2.

Wohlgemerkt: dass so etwas funktioniert, heißt nicht, dass man auch Gebrauch von dieser Möglichkeit machen sollte! Sofern es keine wirklich triftigen Gründe gibt, das HTML5-Formular in die Non-HTML5-Seite direkt einzubetten, sollte man es lassen – Webstandards gibt es nicht ohne Grund.

CSS-Transforms und Z-Index

Ich hantiere gerade mit den neuen CSS3-Transformationen. Meine HTML-Elemente sind über Z-Index in verschiedene Ebenen eingeteilt und vor der Anwendung einer Rotate-Transformation funktioniert diese Einteilung auch noch. Dannach aber verhalten sich die Elemente, als ob sie keine Z-Index-Eigenschaft hätten (Beispiel; wenn durch Hover auf der roten Box die Transformation aktiv wird, wird die grüne Box von der blauen Box trotz Z-Index verdeckt). Woran könnte das liegen?

Das ist eine ganz normale Wechselwirkung zwischen Transformationen und dem Layering-Mechanismus von CSS. Die Spezifikationen lassen uns wissen:

This module defines a set of CSS properties that affect the visual rendering of elements to which those properties are applied [...] Some values of these properties result in the creation of a containing block, and/or the creation of a stacking context.

Zu deutsch: mit CSS3 transformierte Elemente bilden einen eigenen, geschlossenen Kontext (Stacking Context). Wenn man die in einem solchen Element enthaltenen Kindelemente mit einem Z-Index versieht, gilt dieser nur in Relation zu anderen Kindelementen des transformierten Elements. Dieser Effekt tritt auf, weil nicht wirklich das Element plus seine Kindelemente transformiert werden, sondern es wird durch den Browser ein Gesamtbild des Elements und seines Inhalts errechnet, das dann transformiert wird. Und damit wird der Z-Index eines Kindelements in Bezug auf Elemente außerhalb des Elternelements natürlich bedeutungslos.

Audio- und Videocodecs abfragen

Wir sind gerade dabei, das Video-Element in unsere Seite einzubauen und es funktioniert soweit ganz gut. Ich möchte jetzt aber eine Fehlermeldung ausgeben, wenn keins der angebotenen Video-Formate vom Browser akzeptiert wird. Welches JavaScript muss ich da drauf werfen? :-)

Ob ein Browser ein Audio- oder Video-Format unterstützt lässt sich herausfinden, indem man die JavaScript-Funktion canPlayType() auf einem Audio - oder Video-Element ausführt. An die Funktion kann mal als String den MIME-Type bzw. den Codec übergeben, auf dessen Unterstützung man prüfen möchte, also z.B. so:

document.createElement("video").canPlayType("video/mp4");

Die Rückgabewerte dieser Funktion sind entweder ein leerer String (Format wird nicht unterstützt) oder der String "maybe" oder der String "probably". Das mutet etwas kurios an, ist aber eigentlich sowohl sinnvoll als auch praktisch.

Zum einen weiß der Browser unter Umständen wirklich nicht sicher, ob er etwas mit dem übergebenen Format anfangen kann. Wenn man z.B. Chrome 20 nach seine Unterstützung für "video/mp4" fragt, antwortet er "maybe", weil er aus dem MIME-Type allein nicht schließen kann, mit welcher Codec-Version er es zu tun bekommen wird. Zwar kann er prinzipiell etwas mit MP4-Dateien anfangen, aber ganz sicher sein kann sich der Browser ohne weitere Informationen eben nicht. Fügt man eine Codec-Angabe hinzu und fragt z.B. nach "video/mp4; codecs='avc1.42E01E'" (H.256 Baseline) kommt ein zuversichtlicheres "probably" zurück, denn jetzt weiß der Browser schon sehr viel genauer, was da auf ihn zukommt und er kann einschätzen, ob sein Codec-Fundus der Aufgabe gewachsen ist.

Außerdem haben Stings als Rückgabewerte den Vorteil, dass man Sie in JavaScript entweder sehr genau oder nur ungefähr unterscheiden kann, je nachdem was man möchte. Möchte man man sowohl "maybe" als auch "probably" als Antworten akzeptieren, ist die entsprechende If-Abfrage ganz einfach:

var canPlay = myVideo.canPlayType('video/mp4');
if(canPlay){
    macheEtwas();
}

Die Funktion macheEtwas() wird hier sowohl bei "maybe" als auch bei "probably" ausgeführt, da beide Strings als true durchgehen, der leere String (die negative Antwort von canPlayType()) gilt hingegen als false. Möchte man es hingegen genau nehmen und nur "probably" durchlassen, so ist das gar kein Problem:

var canPlay = myVideo.canPlayType('video/mp4');
if(canPlay === "probably"){
    macheEtwas();
}

Was auf den ersten Blick so kurios daher kommt, ist also eigentlich ganz patent.

Welches Element für Kommentare?

Wenn ich nach semantischem Markup für Kommentare suche, wird immer mit <article> pro Kommentar gearbeitet. Mir erschließt sich der Sinn dafür allerdings nicht. Ich finde eine <ol>-Liste wesentlich korrekter dafür. Wie siehst du das?

Ich persönlich halte beides für Varianten, die man einsetzen kann, je nach Situation. Die Spezifikationen scheinen recht eindeutig zu sein, denn sie erwähnen in ihrer Definition des <article>-Elements explizit Nutzerkommentare als möglichen Anwendungsbereich:

The article element represents a self-contained composition in a document, page, application, or site and that is, in principle, independently distributable or reusable, e.g. in syndication. This could be a forum post, a magazine or newspaper article, a blog entry, a user-submitted comment, an interactive widget or gadget, or any other independent item of content.

Aber jetzt bleibt natürlich die Frage, ob ein Nutzerkommentar tatsächlich eine self-contained composition und ein independent item of content ist. Und das, würde ich mal sagen, hängt von der betroffenen Webseite bzw. von dem Inhalt der dort produzierten Nutzerkommentare ab. Wenn wir uns z.B. eins der Werke von Ahoi Polloi ansehen, sind die Kommentare dort eher kurz und ohne den Kontext des besprochenen Haupt-Posts unverständlich. Ich denke nicht, dass ein Statement wie Hoil Polloi! eine self-contained composition und ein independent item of content ist. Wenn wir hingegen schauen, was die Besucher bei Stefan Niggemeier an Kommentaren hinterlassen, sieht die Lage anders aus. Ich zitiere mal Kommentar Nummer 7 aus Kein schöner Lanz:

Lanz führt die Tradition von Kerner fort. Besser noch, er hat dessen Stil perfektioniert. Genau dieses Talent hat das ZDF gesucht. Wir sprechen hier immerhin von einer Kernzielgruppe 50 +. Die wollen nicht denken, die wollen berieselt werden. Am besten von einem Schwiegersohn Marke Lanz oder Pilawa. Deshalb passt Lanz auch sehr gut zu Wetten dass. In diesem Sinne, kein Grund sich aufzuregen. Alles so gewollt. Alles gut. Immer diese Ansprüche …

Dieser Abschnitt könnte (wie die meisten Kommentare auf der Seite) ohne Probleme für sich allein stehen und ergibt auch ohne den Originalartikel so viel Sinn, dass man von self-contained composition und independent item of content sprechen kann.

Es ist wie immer bei der Semantik: es kommt darauf an, was man will. Nutzerkommentare bei Youtube oder auf /b/? Eher <ol>. Kommentare bei Zeit Online oder SPON? Eher <article>. Das ist jedenfalls meine Interpretation der Sache …

Weitere Fragen?

Eure Fragen zu HTML5, JavaScript und anderen Webtechnologien beantworte ich gerne! Einfach eine E-Mail schreiben oder Formspring bemühen und ein bisschen Geduld haben – falls ich gerade unterwegs bin, kann es mit Antwort manchmal etwas dauern, doch früher oder später schreibe ich garantiert zurück.