Eins der schönsten Features von HTML5 könnten die Audio- und Videoelemente sein. Mit <audio> und <video> ist es kinderleicht Ton und Bewegtbild in Webseiten einzubetten und die sehr durchdachte API lädt zum Programmieren eigener Player-Interfaces geradezu ein. Leider gibt es das Codec-Problem: kein einziger Audio- oder Videocodec wird von allen Browsern unterstützt. Die beteiligten Parteien (die Browserhersteller) haben auch sehr gute Gründe – wirtschaftliche Gründe – sich dem jeweiligen Feindes-Codec zu verweigern und es ist nicht wirklich abzusehen, wo in nächster Zeit eine Einigung unter den Browserherstellern herkommen soll. Fakt ist also: <audio> und <video> sind bis auf weiteres praktisch unbrauchbar.

Weil ich zum Glück keinen Browserhersteller gehöre, sondern unabhängiger HTML5-Erklärbär bin, darf ich das am Ende eines Workshops auch immer so offen formulieren. Meine Vorschläge für den Umgang mit dieser Situation sind immer die gleichen: entweder weiterhin das bewärhte Flash benutzen oder den fehlenden Codec in JavaScript nachbauen. Letzteres wird dabei meist nicht ganz ernst genommen, aber wenn es Dinge wie einen in JS geschriebenen PC-Emulator gibt, sehe ich nicht ein, dass es nicht Möglich sein soll, seinen eigenen Decoder im Browser zu programmieren. Dank Audio Data API und <canvas> ist es schließlich möglich, jedwede Ton- oder Bildinformation in einem modernen Browser abzubilden – es müsste halt nur mal jemand wagen.

Und nun hat es endlich mal jemand gewagt: JSmad ist das Script, das dem Firefox 4 MP3-Support beibringt. Das Projekt ist noch recht jung und es hat so seine Performance-Probleme, aber in diesem Fall zählt wirklich vor allem erst mal der Grundgedanke: es gibt keinen Grund, sich HTML5 von den Browserherstellern kaputt machen zu lassen! Sie geben uns ein kaputtes DOM und wir werfen so lange jQuery darauf, bis es funktioniert. Sie liefern uns keine Codecs, wir bauen sie. Das ist genau die richtige Einstellung für ein entspannt-produktives Verhältnis zu HTML5 – denn von Klagen und Jammern allein wird es nicht besser.

Langfristig gesehen wäre es vermutlich rechtlich unbedenklicher, die freien Codecs für die proprietären Browser nachzubauen statt wie im Fall von JSmad umgekehrt. Dazu müssten sich Safari und Internet Explorer zwar erst mal die Audio Data API zulegen, aber auch dieser Tag kann so fern nicht sein. Das wird schon.