Das HTML5shim ist erforderliche Grundlage, um coole HTML5 Elemente wie canvas, video, audio oder datalist, aber auch die “langweiligen” Sectioning Elemente wie nav, article, section etc. sowie andere langweilige Elemente wie mark, figure, figcaption etc. in älteren IE-Versionen einsetzen zu können.

Da das HTML5shim erfordert, dass der Nutzer JS eingeschaltet hat, wird dies gerade im Zusammenhang mit den Sectioning Elementen als problematisch gesehen, da diese im wesentlichen zur Strukturierung und letztlich zum Styling genutzt werden und damit im Widerspruch zum Schichtenmodell der Frontendentwicklung stehen.

Skepsis ist erlaubt

Ich stehe dem heutigen Einsatz dieser Elemente bei 90% aller Webseiten, grundsätzlich negativ gegenüber. Der Grund ist einfach, diese Elemente haben einerseits keine funktionalen Features und ihre Semantik ist schlechter unterstützt als WAI ARIA (Landmarks), andererseits machen sie erheblich mehr Probleme.

Der diskutierte Einsatz von Sectioning Elementen

Eine diskutierte Variante ist zwar HTML5 Elemente einzusetzen, hier jedoch zusätzliche div-Wrapper vorzusehen und ausschließlich diese in CSS und JS anzusprechen. In diesem Fall ist es dann in älteren IEs egal, ob sie nutzbar sind oder nicht.

Letztendlich kann ich dem nicht viel abgewinnen, da in diesem Fall nur zusätzlicher Ballast erzeugt und letztlich in keinem Browser wirklich HTML5 angesprochen wird. Zudem unterscheidet sich die HTML Struktur in den unterschiedlichen Browsern, so dass hierdurch andere Bugs entstehen können und beispielsweise oft keine Kind- sowie Nachfolgeselektoren eingesetzt werden können.

Die konträre Extrem-Position setzt auf das HTML5shim und erklärt das Trennungsprinzip mit HTML5 und seinen reichhaltigen DOM-/JS-APIs sowieso für grundsätzlich erledigt. Webseiten müssen hiernach nicht mehr ohne JS funktionieren und der Aufbau einer Webseite soll nach anderen Prinzipien erfolgen (wobei die neuen Prinzipien, dann nicht mehr erklärt werden bzw. offen gesagt wird, dass man noch auf der Suche nach solchen ist).

Ich halte letztere Position zwar für richtig, aber die Argumentation für extrem gefährlich. Extrem gefährlich deshalb, weil “HTML5 Entwickler” sowieso schon zu dumm sind, um zu erkennen, dass ein button-Element, die richtige Struktur für einen Abspielbutton des eigenen HTML5 Videoplayers wäre. Soviel Dummheit kann man nicht mit den Worten, “Die Spielregeln haben sich verändert, irgendwann erklär ich sie dir”, auf die Welt los lassen.

HTML5 ist nichts anderes als die Weiterentwicklung von HTML und HTML4 bot bereits eine sehr reichhaltige DOM-API. Dass man nun mit noch mehr APIs, mehr und featurereichere Webapplikationen umsetzen kann, welche selbstverständlich JS voraussetzen müssen, ist kein Argument schnöde Webseiten mit ein paar Tabs, Accordions und Galerien so umzusetzen, dass sie ohne JS nicht funktionieren. Es ist letztendlich auch nicht so, dass Webentwickler vor der grossen Herausforderung stehen, sich zu fragen wie man JS abhängige Webapplikationen sauber strukturiert. Die steigende Anzahl und das ebenso steigende Interesse an Templating-Scripten sowie JS-Frameworks, die das MVC-Pattern sowie ähnliche Konzepte mit aufnehmen, dürfte dies deutlich machen.

technik- und nutzerzentrierte Vereinbarung des Schichtenmodells mit HTML5shim

Als erstes gilt es festzustellen, dass das Trennungsprinzip ein Entwicklungsmodell ist, welches beim Entwickeln ungemein hilft. Man schaue sich hier das in die Jahre gekommene DOM-Tab Script an, quasi das Paradebeispiel des Trennungsprinzips und unobtrusiven JS. Ist es nicht schön zu sehen, wie die semantische Information des HTML (Verbindung eines Links mit einem Element durch href-Verweis auf die id dieses Elements) als Konfigurationsgrundlage für das JS aufgegriffen wird. Es gibt viele Beispiele für eine gute HTML-Struktur die nicht nur ohne JS alleine funktioniert, sondern beim stückweisen Aufbau der Webseite mit JS hilft. Soll ich auf so etwas geniales verzichten, obwohl mir gerade HTML5 mit den data-* Attributen und vielem mehr, weitere “Semantik” als [custom-]Konfigurationsmöglichkeiten zwischen Backend und Frontend in die Hände drückt, nur weil irgendwelche alten Browsergenerationen einer einzelnen Firma, bestimmtes HTML bei ausgeschaltetem JS nicht richtig parsen? Nein mit Sicherheit nicht! Warum sollten Frontendentwickler gerade heute anfangen, ihre Konzepte am IE8 und nicht am IE9 auszurichten. Wer unobtrusives JS in Kombination mit HTML5 Sectioning Elementen schreibt, bekommt in jedem Fall ein sauberes Entwicklungsprinzip für eine Webseite und im Fall moderner Browser wird diese wie gewohnt auch weiterhin ohne JS funktionieren. Soviel zur Technik.

Letztendlich kommt es nicht allein auf die Technik, sondern auf den Nutzer an. Hat eine Webseite viele Besucher mit IE8 (und ausgeschaltetem JS), sollte man ohne Zweifel auf HTML5 Sectioning Elemente schlichtweg verzichten. Aber auch in Fällen in denen kaum Nutzer des IE8 mit ausgeschaltetem JS zu erwarten sind, muss man den Nutzer nicht im Regen stehen lassen. Durch geschickte Vermischung von Konditionellen Kommentaren und dem so verhassten noscript Element, lässt sich auf einfache Weise erreichen, dass auch der IE8 bei ausgeschaltetem JS ein (IE6-)universelles Stylesheet bekommt und ansonsten das HTML5 Stylesheet. Und man kann sich dabei auch ganz toll HTML5 fühlen. Denn erst ab HTML5 ist es erlaubt das noscript Element innerhalb des head-Elements zu platzieren.

Die wahren Probleme von neuen Elementen im IE8

Das erste Problem dürfte mit Erscheinen von jQuery 1.7 bekannter werden und gleichzeitig zumindest für die jQuery-Welt auch gelöst sein. Das HTML5shim hilft nämlich bei dynamisch erstellten Elementen nicht viel. Will man beispielsweise seinen schönen HTML5 content mit AJAX in eine Lightbox laden, hat man das selbe Problem wie mit ausgeschaltetem JS. Das dynamisch erstellte HTML[5] weist dann i.d.R. die selben Fehler auf, wie ohne HTML5shim.

Das andere Problem ist die fehlende Möglichkeit HTML5 Elemente zu drucken. Dies erscheint auf den ersten Blick nicht so schlimm, aber man kann letztlich bei fast keinem Projekt im voraus ausschließen, dass es zumindest irgendwann eine Druckvariante geben wird. Die einzige Möglichkeit besteht derzeit in der Verwendung von IEPP (wird vom aktuellen HTML5shim inzwischen genutzt), welches jedoch im Vergleich zu dem reinen klassischen HTML5shim kein einfacher Workaround, sondern ein gigantischer Hack ist. In der Natur von IEPP liegt es, dass der IE kurz vor dem Druck entweder sehr kurz oder recht lang bis hin zum Absturz einfriert. Ebenso in der Natur des Hacks liegt es, dass das Resultat mal dem definierten CSS mal eher weniger diesem entspricht, da IEPP an HTML sowie CSS für die Zeit des Drucks grosse Veränderungen durchführt. Ob es zu solchen Performanceproblemen oder solchen Fehlern kommt, hängt entscheidend vom Umfang des CSS und dem Schreibstil des jeweiligen Entwicklers ab. IEPP ist noch ein recht junges Projekt, welches sich noch deutlich weiterentwickeln kann und muss. Leider sind Verbesserungen häufig nur zu Lasten anderer Kenngrößen des Scripts(Performance vs. Genauigkeit vs. Dateigröße) zu erreichen.

Es ist merkwürdig, dass über dieses Problem kaum gesprochen wird bzw. kaum Entwickler, welche HTML5 gerade anfangen einzusetzen, diese wirklich kennen. Das kennen dieser Probleme sollte jedoch für jeden Entwickler, der über den Einsatz von HTML5 “Sectioning Elementen” nachdenkt, Pflicht sein. Zusätzlich kann zur Verbesserung des Problems einiges getan werden: Entwickler könnten darüber diskutieren, wie sie ihr CSS einbinden/schreiben, damit IEPP dieses schneller parsen kann. JavaScript-Entwickler könnten sich an die Verbesserung des Scripts machen etc..

HTML5 Formularfeatures dürften Anfang nächsten Jahres auf größeres Interesse stoßen. Von einem Feature nämlich der validationMessage-Eigenschaft, läßt sich tatsächlich (rein zufällig natürlich) auf Umfang und Qualität der derzeitigen HTML5 From Implementierung in den unterschiedlichen Browsern schließen:

• Opera: Qualität/Umfang: gut, in Details verbesserbar
• Safari: Umfang gut, aber letztendlich nicht zu gebrauchen
• FF: Umfang gering, aber dafür mit hoher Qualität

Tabelle in eigenem Fenster

Angestachelt durch Robert´s Post/Script zu “Adding HTML5 placeholder attribute support through progressive enhancement” und vor allen Dingen einigen Kommentaren habe ich mein eigenes HTML5 Placeholder-Script nochmals überarbeitet.

Eine Sache, die ich verändert habe, betrifft die Frage, ob das placeholder-Attribut ein Ersatz des label-Elements darstellen kann oder nicht. Laut HTML5 Spezifikation stellt das placeholder-Attribut keinen Ersatz für das label-Element dar, sondern dient nur als zusätzlicher Hint. Meiner Meinung nach ist dies ein weiterer kleiner Fail der Zugänglichkeit in der HTML5 Spezifikation. HTML5 wollte sich doch eigentlich an der Praxis orientieren und das was man mit dem placeholder-Attribut optisch erreicht, wird heutzuage millionenfach als platzsparender Ersatz eines label-Elements praktiziert (Stichwort: overLabel).

Das nun verbesserte Script kann letztendlich als stark vereinfachter Implementierungsvorschlag für Browser dienen. Wird ein placeholder-Attribut entdeckt, wird eine a11y-Namen Berechnung durchgeführt, wird diese nicht fündig, wird der Text des placeholder-Attributs zum a11y-Namen gemacht. Dies mag nicht ganz der Spezifikation entsprechen, ist jedoch deutlich näher an der Realität. Wird dagegen sowohl eine a11y-namengebende Auszeichnung als auch das placeholder-Attribut verwendet, bleibt es selbstverständlich bei dem ursprünglichen Namen und das placeholder-Attribut wird lediglich als zusätzlicher Hint angesehen.

Es gibt zwei Dinge mit denen mein jMediaelement Projekt allein nicht beschrieben wäre: HTML5 audio / video einerseits und Player-Script andererseits. Die von jme genutzen HTML5 Media-Elemente sind nur eine Abspieltechnologie von insgesamt dreien. Würde man den HTML5 Teil weglassen und damit lediglich Flash und VLC als Abspieltechnik dienen, hätte jme weiterhin imense Vorteile für Frontendentwickler. Das liegt unter anderem daran, daß jme eben kein reines Player-Script ist.

jme besteht aus 2 Hauptkomponeten:

1. einem leichtgewichtigem, kugelsicheren reinen embed-Teil
2. der “Vollversion”, welche neben dem embed-Teil, auch die DOM-API und die Markup-API (Controls) enthält

Media-Elemente einbinden schnell und einfach wie ein Bild

In vielen Fällen, in denen ein Entwickler einen Videoplayer einbinden muß, ist kein spezielles Design und kein besonderes Feature verlangt. Es geht schlicht weg darum einen Player zum Abspieln von Videos/Audios zu haben.

Der reine embed-Teil von jme ist daher in einer separaten Version als leichtgewichtiger Helper eingebunden.

Der notwendige HTML-Code ist identisch mit dem HTML5 Code:

<video src="myvideo.webm" poster="mein-poster.jpg" controls="controls">
	<!-- Fallback Content -->
</video>

Damit dies auch ohne Bugs und mit älteren Browsern funktioniert, kopiert man einfach die mm.embed.min.js aus dem packages Ordner vom jMediaelement-Download zusammen mit der player.swf und – falls man youtube-videos einbinden will – der yt.swf in einen gemeinsamen Ordner.

Danach kann man bei DOM-Ready seine HTML5 Media-Elemente mit jmeEmbed registieren:

$(document).ready(function(){
	$('audio, video').jmeEmbed({showFallback: true});
});

Der embed Teil kümmert sich um die Erkennung von Browser- und Plugin-Features, deren Einbindung/Initialisierung, der Normalisierung der HTML5 Mediaelement Attribute sowie der hiermit zusammenhängenden Bugs. Ist die Vollversion von jme eingebunden, wird hierdurch auch die DOM-API initialisiert. Die Vorteile für den Entwickler:

• er hat einen einfachen, intuitiven und semantischen Einbindecode
• Sofern ein Video mit richtigem Container/Codec eingebunden wird, erhöht sich die Zugänglichkeit für bestimmte Endgeräte
• der Entwickler ist nicht gezwungen mehrere Video-Formate anzubieten. Letztendlich können auch nicht HTML5-Formate wie zum Beispiel flv-Dateien oder Youtube-Seiten als Datengrundlage genommen werden.
• Die jeweiligen Browser-, Plugin-Player rendern die Kontrolelemente automatisch, so daß keine weiteren HTML-/CSS-Anpassungen anfallen.

Kurz: Gegenüber der Art wie man derzeit Videos einbindet, kommt man hier mit jme schneller, semantischer und manchmal auch zugänglicher ans Ziel.

HTML ist die Schnittstelle zwischen JavaScript und CSS oder “divide et impera” – Teile und herrsche

Der zweite Teil ist keine reine JavaScript API, sondern gliedert sich in DOM-API und Markup-API auf. Dieser Aufbau ist der Erkenntnis geschuldet, daß JavaScript nur wenig HTML diktieren sollte und HTML unter anderem eine Schnittstelle zwischen einerseits JavaScript und CSS und andererseits zwischen Frontend und Backend darstellt.

Die Erstellung von funktionsfähigen Kontrollelementen ist Aufgabe der Markup-API. Features welche nicht über die Markup-API realisiert sind, können mit Hilfe der DOM-API erledigt werden.

HTML6 Control-Elemente = jme Markup-API/Kontrollklassen

Anstatt, daß durch einen JavaScript-Aufruf ein Haufen unsemantischer HTML-Code um den Player gepackt wird, besteht jme aus kleinen Bausteinen, die einfach zusammengesetzt werden können und so einen individuellen Player ermöglichen. Hierbei besteht als oberstes Prinzip, daß sich die verwendeten Bausteine flexibel in die HTML-/DOM-Welt integrieren laßen müßen.

Stell Dir vor HTML5 ist Schnee von gestern und das W3C würde mit HTML6 einige neue Elemente spezifizieren, welche als Kontrollelemente für das audio- und video-element dienen. Ein Abspiel-/-Pause Button könnte wie folgt aussehen:

<button type="play-pause">play / pause</button>

Das schöne daran, der Browser kümmert sich um Funktionalität und Zugänglichkeit und der Entwickler besitzt die Flexibilität die Kontrollelemente erstens frei zu platzieren und zweitens mit weiterem HTML anzureichen, um Sie dann beispielsweise per CSS besser zu stylen oder um ein gewünschtes Userinterface-Verhalten zu erreichen.

Damit der Browser weiß, mit welchem Mediaelement das jeweilige Kontrollelement verbunden ist, werden die Kontrollelemente gemeinsam mit dem Mediaelement in einem ebenfalls neuen Element mit dem Namen player gewrappt. Das Ergebnis sieht dann wie folgt aus:

<player>
	<video src="myvideo.webm"></video>
	<button type="play-pause">play / pause</button>
</player>

Die jme Kontrollelement-Bausteine funktionieren hierbei auf ähnliche Weise. Die neuen Kontrollelemente werden durch beliebige valide Elemente mit bestimmten HTML-Klassen symbolisiert und lediglich das Wrapper-Element “player” wird durch einen JavaScript Aufruf ersetzt:

<div class="player-wrapper">
	<video src="myvideo.webm" controls="controls"></video>
	<button class="play-pause">play / pause</button>
</div>

Das jQuery-Plugin ‘jmeControl’, welches auf dem wrapper-Element aufgerufen wird, registriert hierbei sozusagen die einzelnen Kontrolelemente und ruft bei Bedarf, die embed-Methode auf. Genau wie bei der jmeEmbed-Methode muß grundsätzlich keine weitere Konfiguration vorgenommen werden.

$('div.player-wrapper').jmeControl();

Werden die nativen Kontrollelemente nicht angezeigt, wird der Flashplayer – sofern nicht ausdrücklich anders konfiguriert – automatisch in den wmode=transparent Zustand versetzt, um auch schöne Overlay-Kontrollelemente oder Overlay-Logos über dem Video erstellen zu können.

Man kann selbstverständlich auch mehrere Kontrollelemente unterbringen:

<div class="player-wrapper">
	<video src="myvideo.webm" controls="controls"></video>
	<button class="play-pause">play / pause</button>
	<span class="current-time">--:--</span>
</div>

jme kümmert sich hierbei nicht nur um die Funktionalität und rendert die jeweils aktuelle Zeit in das span-Element und erstellt ein Play-Pause-Toggle Verhalten aus dem button-element, sondern auch um die Zugänglichkeit. Insbesondere dann, wenn zum einfacheren Stylen statt dem button-Element ein span-Element genommen wird, fügt jme die gewollte Semantik per WAI-ARIA ein. Folgendes geschriebenes HTML ….

<div class="player-wrapper">
	<video src="myvideo.webm" controls="controls"></video>
	<span class="play-pause">play / pause</span>
	<span class="current-time">--:--</span>
</div>

…wird durch jme in folgendes HTML umgewandelt:

<div class="player-wrapper">
	<video src="myvideo.webm"></video>
	<span role="button" tabindex="0" class="play-pause">play / pause</span>
	<span role="timer" class="current-time">--:--</span>
</div>

Neben allgemein üblichen Video/Audio Kontroll-Elementen bietet jme über Plugins auch Verhaltensklassen für eine Playliste und Captions an.

Die Tatsache, daß wir eine Markup-API verwenden, die nicht von JavaScript diktiert wird, heißt aber nicht, daß wir nun alle möglichen Kontroll-/Verhaltensklassen auswendig lernen und wieder und wieder ins HTML schreiben müßen. jme bietet im utils-Ordner das jmeEmbedControls-Plugin an, welches nichts anderes macht, als einen Haufen Kontrollelemente in das Element, auf dem es aufgerufen wurde, einzufügen, um dann hierauf die jmeControl-Methode auszuführen. Diese Methode ist sozusagen das Schnellstarter-Kit für jme. Er ist bewußt ausgelagert, um jedem Webentwickler eine projektspezifische Anpassung zu ermöglichen.

einheitliche DOM-API statt vereinheitlichte JavaScript-API

Die vereinheitlichte JavaScript-API ist bei jme bewußt eine DOM-API, da nur so sich Mediaelemente, sei es nun HTML5, Flash oder VLC, in den normalen Workflow eines Frontendentwicklers integrieren können.

Ein Beispiel: JW-Player for HTML5 ist das erste HTML5 Player-Script, welches eine dokumentierte API vorweisen kann. Und obwohl jQuery, also ein klassischer DOM-Wrapper, als JavaScript Grundlage gewählt wurde, wurde keine DOM-API implementiert. Um einen Player zu scripten, sieht der Code wie folgt aus:

$.jwplayer().play();

Laut Dokumentation wird nun immer auf dem ersten eingebundenen Mediaelement die Methode play aufgerufen, möchte man nun jedoch auf einem anderen Mediaelement Methoden ausführen, muß man bereits zum Zeitpunkt der Initialisierung die Referenz auf dieses Objekt speichern und sicherstellen, daß alle Module die hiermit interagieren müßen an diese Referenz kommen:

//holen der Referenz auf ein bestimmtes Video bei der Initialisierung
var player = $('#stage video').jwplayer({
	flashplayer:'/static/files/player.swf',
	skin:'/static/files/five.xml'
});

//initialisieren aller anderen videos
$('video').not('#stage video').jwplayer({
	flashplayer:'/static/files/player.swf',
	skin:'/static/files/five.xml'
});

//arbeiten mit der gespeicherten Referenz
//irgendwo ganz anders im script
player.play();

Mit einer DOM-API sieht die Sache dagegen anders aus, denn die API ist Teil des DOMs und kann wie jede DOM-API mit der jQuery-Selektorengine selektiert werden.:

$('#stage video').play();

Ebenso wie man bei anderen DOM-Elementen auf Events horcht, Methoden chained etc., funktioniert dies auch bei jme. Das video bzw. das audio Element bleiben hierbei immer das zentrale API Element, gleichgültig ob tatsächlich HTML5 oder eben ein Plugin zur Anzeige der Mediainahlte genutzt wird.

$('video').bind('ended', function(){
	$(this).attr('autoplay', true).loadSrc('my-video2.webm');
});

Kurz: nur so kann Scripten Spaß machen.

Fazit

Merkwürdig aber wahr: jme stellt in vielen Punkten einige Weltrekorde auf:

1. jme ist das erste audio/video Script mit Fallback, welches eine dokumentierte DOM-API besitzt (das werden garantiert einige nachmachen, da es sooo nahe liegt)
2. jme ist das erste audio/video Script, welches eine Markup-API für Kontroll- und Zustandselemente verwendet
3. jme ist – und das ist wirklich traurig – das erste Script seiner Art, welches semantischen Code erlaubt/nutzt (notfalls mit WAI-ARIA forciert)

Oder anders gesagt: jme versucht nicht aus HTML5 Flash zu machen, sondern aus Flash HTML5.

HTML 5 Mediaelemente für alle – Warum und Wie video-/audio- Elemente schon heute genutzt werden sollten

Ich gehöre mit Sicherheit nicht zu denjenigen, welche die Nutzung von HTML5 in seiner reinen Form bereits heute propagieren. Die Probleme der Rückwärtskompatibilität mit HTML5-Elementen sind zu groß und können eben nicht mit dem document.createElement – Trick behoben werden. Ausnahmen bestätigen jedoch die Regel und eine hiervon sind mit Sicherheit die HTML5 Mediaelemente, audio und video. Warum sollten diese Elemente also zum Einbinden von Multimediainhalten genutzt werden, wenn immernoch Flash oder andere Plugins – zumindest als Fallback genutzt werden müßen?

audio/video Elemente sind einfacher zu Handhaben als object-/embed-Elemente

Im Laufe der Zeit haben sich eine Menge Einbindetechniken für Flash-Player entwicklet. Diese Menge an Einbindetechniken sind jedoch kein Zeichen von Flexibilität, sondern Ausdruck für die Unzulänglichkeiten jeder jeweils anderen Einbindetechnik. Ein paar Beispiele:

• verschachtelte object-Elemente bzw. verschachtelte object-/embed – Elemente

  fehleranfällig, da unterschiedlicher Code für unterschiedliche Browser; kaum ein Entwickler kann sich den genauen Einbindecode merken; unelegantes HTML

• Einbindung mit swfobject oder ähnlichem

  kann nicht ohne Javascript funktionieren; kaum ein Entwickler kann sich den Einbindecode merken; Herausforderungen dies elegant mit einem CMS zu lösen

• Javascript transformiert ein HTML-Element automatisch zum Videoplayer-Code (z. B.: a.video -> object)

  kann nicht ohne Javascript funktionieren; angesichts der Vorhandenen HTML5-Semantik ist diese Einbindung semantisch überholt

Auf der anderen Seite stehen die HTML5-Elemente audio/video, welche die Einbindung von Mediainhalten so einfach machen, wie die Einbindung von Bildern.

	<video src="mein-video.mp4" poster="mein-poster-bild.jpg" controls="controls"></video>

Unterstützt der Browser nicht das video-Element bzw. das Video-Format kann dies mit Javascript erkannt und in ein unterstütztes object-Element umgewandelt werden. Was bleibt ist jedoch ein klarer Einbindecode, der semantisch und elegant ist und in modernen Browsern grundsätzlich auch ohne Javascript und vor allem ohne weitere Plugins funktioniert.

Es funktioniert auf mehr Endgeräten

Spätestens seit der unsäglichen iPhone/iPad – Flash Diskussion wissen alle, daß Flash nicht auf allen Geräten installiert ist. Bindet man Mediainhalte per HTML5 ein und fällt – bei nicht Unterstützung – auf ein oder besser mehrere mögliche Plugin(s) (Flash, Quicktime, VLC etc.) zurück, erreicht man schlichtweg mehr User.

jMediaelement – Video/Audio für alle

Das jMediaelement-Script auf Basis von jQuery stellt eine Lösung dar, welche erkennt, ob die HTML5-Mediaelemente im allgemeinen und die konkreten Mediadaten im besonderen unterstützt werden. Bei Bedarf bindet es unterstützte Plugins ein (derzeit Flash auf JW Player Basis sowie VLC), normalisiert die unterschiedlichen APIs und hilft bei der Erstellung von stylbaren Kontrollelementen für die Player.

Mediainhalte mit jMediaelement einbinden

Die Einbindung von Video- und Audio – Dateien mit jMediaelement ist dementsprechend sehr einfach. Als Grundlage muß man lediglich den HTML Code schreiben, wie er durch HTML 5 vorgesehen ist. Die Attribute poster, loop, autoplay, controls werden hierbei unterstützt. Man kann statt einer Source-Datei auch mehrere Dateien verwenden. Als mögliche Source-Dateien kommen neben MP3, MP4 und OGG auch FLV, MOV und weitere in Frage.

Nachfolgend ein paar Beispiele:

<video src="mein-video.mp4" poster="mein-poster-bild.jpg" controls="controls"></video>

<video loop="loop">
	<a class="source" href="mein-video.flv" controls="controls">Video als flv</a>
	<source src="mein-video.flv" />
</video>

<video poster="mein-bild.png" autoplay="autoplay" controls="controls">
	<a class="source" href="mein-video.ogg">Video als ogg</a>
	<source src="mein-video.ogg" />
	<a class="source" href="mein-video.mp4">Video alsmp4</a>
	<source src="mein-video.mp4" />
</video>

Anschließend ruft man einfach das jQuery Plugin auf den Audio/Video Elementen auf. In der Regel muß man hier nur den Pfad zur Flashplayerdatei konfigurieren:

$('audio, video').jmeEmbed({
    jwPlayer: {
        path: '../mediaplayers/player.swf'
    }
});

Zur “kugelsicheren” Einbindung mit schönem Fallback, falls alle Stricke reißen, kann noch etwas mehr getan werden, aber dies soll hier erstmal reichen.

Multimedia scripten war noch nie so einfach

Eine Sache die mit jMediaelement wirklich Spaß macht, ist das Scripten der Player. Zum einen ist die API für die unterschiedlichen Player normalisiert, zum anderen erweitern diese jQuery selbst. Gleichgültig welche API und welcher Browser verwendet wird, ist und bleibt das HTML5-Element hierbei das anzusprechende Element, so daß mit den Mediaplayern gearbeitet werden kann, wie man dies von jQuery gewohnt ist. Eine Auflistung der meisten Methoden findet sich im jMediaelement-Wiki.

Hier ein paar Beispiele:

Sind mehrere Video- und/oder Audio-Player auf einer Seite und sollen, sobald der User einen Player startet, alle anderen pausiert werden, könnte dies folgender einfacher Code bewerkstelligen:

$(document).bind('play', function(e){
	$('audio, video').not(e.target).pause();
});

Wir wollen Sprungmarken in das Video erlauben. Klickt der User auf eine Sprungmarke springt der Player an diese Stelle und fängt an zu spielen. Wir haben hierfür folgendes HTML vorbereitet:

<video class="skip-video" src="mein-video.mp4" poster="mein-poster-bild.jpg" controls="controls"></video>
<ul class="skip-links">
	<li><a href="#" data-time="10">jump to 10</a></li>
	<li><a href="#" data-time="20">jump to 20</a></li>
	<li><a href="#" data-time="30">jump to 30</a></li>
</ul>

Dann würde unser Javascript wie folgt aussehen:

$('ul.skip-links').delegate('a', 'click', function(e){
	var time 	= parseInt($(this).attr('data-time'), 10);
	if(isNaN(time)){return false;}
	$('video.skip-video')
		.currentTime(time)
		.play()
	;
	return false;
});

Wir wollen, daß ein Video automatisch, aber im gemuteten Zustand, abspielt. Zwar kennt der HTML5 Standard das Attribut autoplay, aber für den mute-Zustand gibt es keine Markup-API. Unser HTML könnte dann so aussehen:

<video class="automute" autoplay="autoplay" src="mein-video.mp4" poster="mein-poster-bild.jpg" controls="controls"></video>

… und unser Javascript wie folgt:

$('video.automute').muted(true);

Bisher haben wir die Player nur in verschiedene Zustände versetzt (currentTime, play, pause, muted). Es ist aber genauso möglich, Zustände auszulesen. Hierzu müßen wir allerdings abwarten, bis die API bereit ist, ausgelesen zu werden. Dies sagt uns die Methode jmeReady. Hier ein kleines Beispiel:

$('video.myvideo').jmeReady(function(){
	var muted = $(this).muted(); //true|false
	var time = $(this).currentTime(); //am Anfang wohl in der Regel 0
	//etc.
});

Manche Daten wie beispielsweise die Länge des Videos/Audios sind erst noch später verfügbar, nämlich dann, wenn die Metadaten geladen wurden, wofür das Event loadedmeta zur Verfügung steht. Hier ein Beispiel:

$('video.myvideo').bind('loadedmeta', function(){
	var duration = $(this).getDuration(); //das video dauert xxx Sekunden
});

Unter meinen jMediaelement-Demos befindet sich eine Audioplayer-Demo, welche zeigt, wie einfach mit der Methode loadSrc eine Playliste erstellt werden kann.

Stylebare Kontrollelemente erstellen

Die Erstellung von stylbaren HTML-Kontrollelementen wird durch jMediaelement ebenfalls unterstützt. Hierbei ging es mir um die größtmögliche Flexibilität für den Webautoren. Anstatt Kontrollelemente in einer mehr oder – in der Regel – weniger konfigurierbaren, lokalisierbaren und barrierearmen Form mit Javascript in das HTML zu Rendern, darf(/muß) der Entwickler sein HTML selber schreiben. Das einzige was vorgegeben wird, ist eine HTML-Klasse, welche dem Script sagt, wie sich das Kontrollelement verhalten sowie ein Mechanismus, welcher Player hierdurch gesteuert werden soll.

Wir wollen beispielsweise einen Play-/Pause-Togglebutton machen. Die vorgegebene Klasse nennt sich hierfür ‘play-pause’.

Unser HTML könnte dann wie folgt aussehen:

<a href="#" class="play-pause">play / pause</a>
<!-- oder -->
<button class="play-pause">play / pause</button>
<!-- oder, aber nicht empfohlen, da nicht tastaturbenutzbar -->
<span class="play-pause">play / pause</span>

Folgende Schreibweisen wären jQuery UI Themeroller kompatibel:

<a href="#" class="play-pause"><span class="ui-icon"></span> play / pause</a>
<!-- oder -->
<button class="play-pause"><span class="ui-icon"></span> play / pause</button>
<!-- oder, empfohlen: -->
<button class="play-pause"><span class="ui-icon"></span> <span class="button-text">play / pause</span></button>

Für die Assoziierung eines Kontrollelements mit einem bestimmten video-/audio-Element, biete ich im Prinzip 3 Möglichkeiten an:

• gemeinsames wrapper-Element
• data-controls-Attribut am Kontrollelement (HTML5-valide, data-controls=”IDREF”)
• data-controls-Attribut an einem wrapper-Element

gemeinsames wrapper-Element

Wird die jQuery-Methode ‘jmeControl’ auf einem Wrapper-Element ohne data-controls-Attribut aufgerufen, werden alle darin befindlichen Kontrollelemente mit dem ersten gefundenen video/audio-Element assoziiert:

Unser HTML:

<div class="video-wrapper">
	<video src="mein-video.mp4" poster="mein-poster-bild.jpg"></video>
	<a href="#" class="play-pause">abspielen / pausieren</a>
	<a href="#" class="mute-unmute">ton aus / ton an</a>
</div>

Unser Javascript:

$('div.video-wrapper').jmeControl();

data-controls-Attribut am Kontrollelement

Soll das Kontrollelement eigentlich ganz woanders auf die Webseite, gibt es unter Umständen keinen gemeinsamen wrapper, welcher andere video/audio-Elemente ausschließt bzw. wäre obige Schreibweise ineffizient.

Unser HTML:

<div class="video-wrapper">
	<video id="my-video" src="mein-video.mp4" poster="mein-poster-bild.jpg"></video>
</div>
<!-- ganz viel HTML dazwischen -->
<a data-controls="my-video" href="#" class="play-pause">abspielen / pausieren</a>

… und unser Javascript:

$('a.play-pause').jmeControl();

data-controls-Attribut an einem wrapper-Element

Exsistieren mehrere Kontrollelemente weit vom zu kontrollierenden video-/audio-Tag entfernt, wäre es müßig jedem einzelnen Element das data-controls-Attribut zu geben.

Unser HTML:

<div class="video-wrapper">
	<video id="my-video" src="mein-video.mp4" poster="mein-poster-bild.jpg"></video>
</div>
<!-- ganz viel HTML dazwischen -->
<div class="control-wrapper" data-controls="my-video">
	<a href="#" class="play-pause">abspielen / pausieren</a>
	<a href="#" class="mute-unmute">ton aus / ton an</a>
</div>

… und unser Javascript:

$('div.control-wrapper').jmeControl();

Konfiguration der Kontrollelemente

Die Kontrollelemente sind daneben zusätzlich konfigurierbar. Beispielsweise sind alle slider sowie die progressbar Teil von jQuery UI und alle Optionen jQuery UI Optionen können verwendet werden. Wir wollen beispielsweise unsere Klassen Namespacen, da wir in einem ganz anderen Modul bereits die Klasse play-pause verwenden, außerdem wollen wir, daß der bereits abgespielte Teil auf der Timeline anders eingefärbt wird und sich der Sliderhandle animiert auf der Timeline bewegt.

Unser HTML:

<div class="video-wrapper">
	<video id="my-video" src="mein-video.mp4" poster="mein-poster-bild.jpg"></video>
</div>
<div class="control-wrapper" data-controls="my-video">
	<a href="#" class="jme-play-pause">abspielen / pausieren</a>
	<div class="jme-time-slider"></div>
</div>

… und unser Javascript:

$('div.control-wrapper').jmeControl({
	classPrefix: 'jme-',
	timeSlider: {
		range: 'min',
		animate: true
	}
});

Fazit: Eine API sie zu knechten

Als ich mit dem Projekt angefangen habe, stand die Auseinandersetzung mit den HTML5 Mediaelementen im Vordergrund. Als ich dem ganzen einen Sinn verleihen wollte, war für mich der erste Gedanke, so viel HTML 5 wie möglich so wenig Flash/Plugins wie nötig, möglich zu machen. Diese Sichtweise hat sich inwzischen enorm geändert. jMediaelement ist für mich ein Tool, welches es erlaubt Mediainhalte einerseits einfach und elegant einzubinden und gegebenefalls ebenso einfach zu scripten und zu stylen sowie andererseits Mediainhalte auch dort zugänglich zu machen, wo entsprechende Plugins (noch) nicht verfügbar sind. Aber wem mein erster Gedanke eher gefällt, kann jMediaelement auch für seine Zwecke nutzen .

Ich arbeite in letzter Zeit immer wieder mit dem HTML 5 Video Element. Bis auf einige kleinen Problemchen mit der API sowie einigen grausamen Implementierungsbug im Safari (betrifft nicht Chrome), bin ich eigentlich ganz zufrieden.

Es gibt aber letztendlich eine Sache die mich extrem rasend macht. Schaut man sich die Youtube HTML5 Demo an und vergleicht diese mit der Spezifikation wird einem klar, daß Youtube mit HTML5 nie so aussehen kann, wie diese Demo einem glauben machen will.

Die Demo zeigt einen Fullscreen-Button. Leider ist die HTML5 Spezifikation hier sehr einduetig. Einerseits ist keine API für einen möglichen Fullscreen-Modus definiert andererseits werden Browserhersteller mit fetter, roter Schrift ausdrücklich davor gewarnt, eine solche zu implementieren. Als Begründung wird auf mögliche “Nervigkeiten” sowie Angst vor Sicherheitsproblemen, genauer Phishing Attacken, abgestellt.

Letztendlich ist die Begründung vollkommen überholt und daneben. Das Security Argument stimmt nicht, da

• ein Videoelement beim Starten des Vollbildmous grundsätzlich einen entsprechenden Hinweis zeigen soll
• ein Videoelement im Vollbildmodus, unabhängig vom Vorhandensein des controls-Attribut, die Kontrollelemente anzeigen muß
• es im Vollbildmodus gar nicht möglich ist – und das wäre das eigentliche Sicherheitsrisiko – Tastaturevents abzufangen

Auch das Risiko einer Belästigung des Users ist gering, wenn man es mit ähnlichen Einschränkungen implementieren würde wie dies bei Adobe Flash getan wurde. Gerade Flash, welches häufig für nervige Dinge wie Werbebanner eingesetzt wird, hat eine API für den Fullscreenmodus, anstatt daß dies mich nervt, empfinde ich es als extrem nützlich.

Hier lag wohl auch augenscheinlich das Problem. Eine API für den Fullscreenmodus wurde mit Methoden wie window.open oder window.resize verglichen, ohne zu erkennen, daß das Anschauen von Videos im Vollbildmodus ein wesentlich nützlicheres Feature ist als das ungefragte Öffnen von Popups und Verschieben von Browserfenstern.

Meine große Hoffnung liegt nun darin, daß entweder irgendein Browser (zum Beispiel: Chrome 4 oder 5 oder Internet Explorer 9) aus der Reihe tanzt und zeigt wie man ein cooles, sicheres Feature implementiert oder daß bei der Zugänglichkeits- (oder vielleicht auch Usability-) überarbeitung des Elements auffällt, daß ein Fullscreenmodus nicht allein mit der rechten Maustaste als Kontextmenü realisiert werden darf.

Ich kotze.

Ich bin ein großer Freund von HTML5. Allerdings kann ich nicht nachvollziehen, in welcher Form einige – bereits heute – HTML5 nutzen wollen bzw. zu nutzen empfehlen. Die tollen HTML5-Elemente (nav, aside, header, footer..), die wir mit dreckigen Tricks nutzen könnten, bringen nichts. Kein Browser, kein Screenreader und auch keine ernstzunehmende Suchmaschine unterstützen die Semantik der neuen Tags, gleichzeitig bereiten Sie in allen Versionen des Internet Explorer sowie im Firefox 2 erhebliche Probleme und machen einiges kaputt.

Auf der anderen Seite gibt es die schönen WAI-Aria-Landmarks. Sie sind für eine zusätzliche Semantik definitiv der bessere Weg, weil sie im Gegensatz zu den oben genannten HTML 5 Element einfach funktionieren, helfen und nichts kaputt machen.

Andere Elemente wie figure und legend können teilweise durch aria-labelledby/aria-describedby substituiert werden.

Dies ist kein Widerspruch zu HTML 5. Im Gegenteil der HTML 5 Validator validiert inzwischen nicht nur Teile von Wai-Aria, sondern eben auch die Aria-Landmarks.

Neben den problemlos verwendbaren Aria-Attributen, gibt es in HTML5 viele schöne neue Sachen zu entdecken.

• Man kann sich endlich den doctype merken.
• Das canvas-Element wird von allen modernen Browsern unterstützt und kann mit excanvas auch im Internet Explorer zum Laufen gebracht werden (allerdings mit deutlich geringerer Performance).
• Attribute wie autocomplete sind endlich Bestandteil von HTML 5. Ohne dieses Attribut sind mit Javascript erstellte Auto-Suggest-Listen für Eingabefelder unmöglich.
• Es gibt neue, befreiende Verschachtelungsregeln.
• Best practices wie beispielsweise document.documentElement.className += ‘js-on’; erzeugen endlich validen Code.

Vor allem jedoch bietet HTML 5 – insbesondere bei Formularelementen – semantische Extras, die Javascript-Entwickler, gleichgültig von der derzeitigen Unterstützung im Browser, dringend benötigen, um eleganten, unobtrusiven Code schreiben zu können.

Wie zusätzliche semantische HTML5-Attribute beim Aufbau von Javascript helfen

Man stelle sich vor, man möchte einen Slider mit numerischen Werten realisieren. Dieser Slider soll jeweils einen vom Backend vorgegeben Startwert, Mindestwert und Höchstwert kennen. Als Javascript-Fallback soll ein einfaches Texteingabefeld dienen.

Während HTML 4 sowie XHTML 1.0 lediglich ein Attribut für den Startwert bieten, hilft uns HTML 5 ebenso beim Mindest- und Höchstwert unseres unobtrusiv zu erstellenden Sliders.

<input type=“number“ value=“3“ min=“1“ max=“10“ />
<!-- oder in Schritten -->
<input type=“number“ value=“3“ min=“1“ max=“10“ step="1" />
<!-- oder gleich als 'slider' -->
<input type=“range“ value=“3“ min=“1“ max=“10“ />

HTML 5 und progressive enhacement

HTML 5 bietet einige interessante Features, welche bereits heute mit Hilfe von Javascript implementiert werden können.

Das oben beschriebene canvas-Element ist ein Beispiel hierfür, ein weiteres sind die zahlreichen Erweiterungen für Formularelemente, welche in Teilen bereits von Browsern implementiert wurden.

Die HTML 5 – Attribute liefern hierbei die semantische Grundlage für die Aktivierung und Konfiguierung des Javascripts.

Vor der Implementierung mit Javascript sollte man grundsätzlich testen, ob das Feature nicht bereits Teil des Browsers ist. Da die neuen HTML-Attribute in der Regel mit einem DOM-Interface korrelieren, ist dieser Test kinderleicht. Hier einige Beispiele mit jQuery:

(function($){

	var form = $('<form><fieldset><textarea /></fieldset></form>');

	$.extend($.support, {
		//wird die Constrain Validation unterstützt?
		checkValidity: !!(form[0].checkValidity),
		// wird das maxlength-Attribut am textarea-Element unterstützt?
		textareaMaxlength: !!( $('textarea', form)[0].maxLength !== undefined || $('textarea', form)[0].maxlength !== undefined)
	});

})(jQuery);

Eine Beispielimplementierung für das placeholder-Attribut

Das placeholder-Attribut bietet ein Formularfeature, welches Frontend-Entwickler tagtäglich bereits heute mit Javascript in Webseiten nutzen; nämlich das Entfernen von vorbelegten Werten in Eingabefeldern. Hierbei ist das Standardverhalten wie folgt definiert: Der Placeholder stellt einen kurzen Hinweistext dar, welcher dem User als vorläufiger Wert im Eingabefeld angezeigt wird, solange das Feld keinen Wert hat und nicht fokusiert ist. Das placeholder-Attribut ist kein Ersatz für ein assoziertes label-Element!

<label for="birthday">Ihr Geburtstag</label>
<input type="text" placeholder="TT.MM.JJJJ" name="birthday" id="birthday" />

In HTML4/XHTML 1 ist die Unterscheidung ob das Eingabefeld einen Wert, welcher sich wie ein Placeholder verhalten soll oder nicht, nicht gelöst. Die derzeit eleganteste Javascript-Technik verwendet hierzu einen Vergleich zwischen der value- und der defaultValue-Eigenschaft. Diese Form der Implementierung kommt jedoch an Ihre Grenzen, wenn der User beispielsweise ein Suchformular absendet und der Suchbegriff aus Usability-Gründen wiederholt wird, um es dem User zu gestatten, ohne Neueingabe den Suchbegriff zu erweitern, verkürzen oder sonst wie zu modifizieren. Da in diesem Beispiel ausnahmsweise der defaultValue nicht die Aufgabe eines Placeholders besitzt, fehlt dem Javascript die entscheidende Information sich korrekt zu verhalten. Dieses Problem kann letztlich nur durch Hinzufügen dieser Extrainformation gelöst werden. Und die Standardisierung dieser Extrainformation stellt gerade eben das placeholder-Attribut dar.

Wie könnte nun eine placeholder-Implementierung aussehen?

Als erstes erweitern wir unseren oben genannten HTML5-Implementierungstest:

var form = $('<form><fieldset><input type=“text“ /><textarea /></fieldset></form>');

$.extend($.support, {
	checkValidity: !!(form[0].checkValidity),
	textareaMaxlength: !!( $('textarea', form)[0].maxLength !== undefined || $('textarea', form)[0].maxlength !== undefined),
	placeHolder: !!($('input', form)[0].placeholder !== undefined || $('input', form)[0].placeHolder !== undefined)
});

Wird das placeholder-Attribut nicht unterstützt, kann mit der Implementierung durch Javascript fortgefahren werden, was wie folgt aussehen könnte.

if(!$.support.placeHolder){

	function resetInput(){
		if(this.value == this.getAttribute('placeholder')){
			this.value = '';
		}
	}

	function fillInput(){
		if(!this.value){
			this.value = this.getAttribute('placeholder');
		}
	}
	$(function(){
		$('input[placeholder]')
			.each(function(){
				var placeHolder = this.getAttribute('placeholder').replace(/\n|\r|\f|\t/g, '');
				this.setAttribute('placeholder', placeHolder);
				if(!this.value){
					this.value = placeHolder;
				}

			})
			.bind('blur', fillInput)
			.bind('focus', resetInput)
		;
	});
}

Das schöne, das Script kann bereits heute für ein besseres placeholder/input-rest-Script eingesetzt werden. (Ich kenne keines mit einem besseren Verhalten). Bei Browsern (zum Beispiel Safari 4), welche dieses Attribut bereits unterstützen, funktioniert das ganze dann auch ohne Javascript. Die Benutzung ist sehr einfach. Konfiguration und Start des Scripts geschehen komplett automatisch.

<label for="birthday">Ihr Geburtstag</label>
<input type="text" id="birthday" placeholder="TT.MM.JJJJ" name="birthday" />

Hier das gesamte Script (Eine verbesserte Variante des Placeholder-Scripts):

(function($){

var form = $('<form><fieldset><input type=“text“ /><textarea /></fieldset></form>');

$.extend($.support, {
	checkValidity: !!(form[0].checkValidity),
	textareaMaxlength: !!( $('textarea', form)[0].maxLength !== undefined || $('textarea', form)[0].maxlength !== undefined),
	placeHolder: !!($('input', form)[0].placeholder !== undefined || $('input', form)[0].placeHolder !== undefined)
});

if(!$.support.placeHolder){
	$(function(){
		$('input[placeholder]')
			.each(function(){
				var placeHolder = this.getAttribute('placeholder').replace(/\n|\r|\f|\t/g, '');
				this.setAttribute('placeholder', placeHolder);
				if(!this.value){
					this.value = placeHolder;
				}

			})
			.bind('blur', function fillInput(){
				if(!this.value){
					this.value = this.getAttribute('placeholder');
				}
			})
			.bind('focus', function resetInput(){
				if(this.value == this.getAttribute('placeholder')){
					this.value = '';
				}
			})
		;
	});
}
})(jQuery);

Fazit

HTML 5 hat deutlich mehr zu bieten als nicht funktionierende HTML-Elemente. Diese sind oftmals nicht mehr als semantischer „Zuckerguß“. HTML 5 kann jetzt schon vielmehr: Es ermöglicht wirklich elegantes und unobtrusives Javascript.