Wenn Sie Webseiten programmieren und gestalten, kennen Sie das Problem schon seit Beginn Ihrer Arbeit: Jeder Browser interpretiert Ihre HTML-Codes auf seine Weise, einige sogar überhaupt nicht. Unrühmliche Ikone ist hier der Internet Explorer vom Microsoft, für den Webseiten-Entwickler stets ein ganz eigenes Süppchen kochen mussten, weil er sich mit Konfektionsware nicht zufrieden geben wollte. Aber was sollte man machen, solange dieser Browser der am weitesten verbreitete war? Kröte schlucken und die Webseite mit vielen Tricks und Workarounds aufwendig „tunen“, damit auch der Microsoft-Browser daraus eine vernünftige Darstellung ableiten konnte.
Inzwischen hat sich vieles geändert. Der Internet Explorer krebst nach meiner Statistik irgendwo bei 10% Marktanteil herum, dicht gefolgt von Safari von Apple, die Mozilla-Browser (wie Firefox und SeaMonkey) haben großflächig das Kommando übernommen und mit HTML5 steht ein neuer Web-Standard vor dem Durchbruch. Damit habe ich schon vor einiger Zeit ein wenig herumprobiert, aber mit geringem Erfolg, weil eigentlich nur Safari mit Spielereien wie embedded audio und video problemlos klarkam.
So sieht der embedded audio player in Safari 5.1 aus (Ausschnitt aus meiner Webseite)
Das fand ich aus zwei Gründen ziemlich schade: Erstens könnte man bei größerer Verbreitung völlig auf die von mir ungeliebte Adobe-Flash-Technologie verzichten und zweitens bin ich bekanntlich Audio-Produzent und arbeite nebenher auch noch für’s Fernsehen, also interessiert mich auch die Einbindung von Videos auf der Webseite.
Mein – zugegebenermaßen etwas vorsintflutliches – Werkzeug für solche Spielereien ist der Composer der SeaMonkey-Suite, bei dem HTML5-Elemente nur als reine html-Befehle eingegeben werden und vor dem Upload nicht auf volle Funktionsfähigkeit überprüft werden können. Deshalb, und weil ich als Standard-Browser Camino verwende (der ohnehin nichts mit HTML5 anfangen kann und für den ich als fallback beim Text „und so klingt’s“ einen Hyperlink auf die Audiodatei gesetzt habe), ist mir wohl der Lapsus passiert, dass das als autoplay definierte HTML5-audio element auf meiner Startseite zwar unter Safari, aber nicht unter Firefox und Co. funktionierte, obwohl auch dort das Control-Panel zu sehen war; allerdings mit einem großen weißen X auf grauem Grund darüber.
Das korrekt eingebundene HTML5-Audio-Element unter Firefox 3.6.10 (alles auf MacOS 10.6.4)
Nach einigem Suchen und Herumprobieren konnte ich das Rätsel lösen (das bei Experten wohl eher ein Gähnen auslöst, mir aber ziemliche Kopfschmerzen bereitete und mich eine halbe Nacht kostete): Die mit dem audio element verknüpfte Audio-Datei war im MP3-Format. Damit kommt zwar Safari klar (ebenso wie mit AAC-Dateien), aber nicht Firefox. Der weigert sich einfach, solche Dateien zu laden und besteht auf WAVE- oder Ogg-Container. Wobei WAVE ein ziemlicher Unsinn ist (wenn’s nicht auf die höchste Soundqualität und die Möglichkeit der Weiterbearbeitung ankommt), weil die Dateien um Welten größer sind als bei Vorbis-Ogg- oder MP3-Komprimierung. Ähnliche Unterschiede gibt’s natürlich auch bei Video-Dateien.
Und jetzt kommt mit dem Internet Explorer 9 noch ein neuer Mitspieler auf’s HTML5-Feld, der ebenfalls besondere Ansprüche hat. Aber halt: Die hat er ja gar nicht! Er mag genau wie Safari MP3 und AAC bei Audios sowie MP4-Container, h.264, alle Profile, bei Videos. Was für ein glücklicher Zufall und welch ein Unterschied zu den historischen Extrawürsten des Microsoft-Browsers.
Und wie löst nun der genervte Webseiten-Designer das Problem, mundgerechte HTML5-Elemente für alle HTML5-fähigen Browser zu basteln? Ganz einfach: Er lädt Audios und Videos mindestens doppelt in verschiedenen Formaten hoch und bindet sie dann nacheinander in den Programmcode ein. Etwa so:
<audio controls=controls> |
<source src="mySong.aac"> |
<source src="mySong.ogg"> |
</audio |
Eine gesonderte Browser-Erkennung ist nicht notwendig; jeder holt sich im Idealfall das passende Format und überspringt die anderen Angebote. Die bei älteren Firefox-Versionen eingebaute Divenhaftigkeit, dass das passende Ogg-File nur dann erkannt wird, wenn es ganz oben in den Liste steht, wurde inzwischen ausgemerzt. Wer ganz sicher gehen will, kann dem Browser auch noch eine kleine MIME-type-Hilfestellung geben:
<audio controls=controls> |
<source src="mySong.aac" type="audio/mp4"> |
<source src="mySong.ogg" type="audio/ogg"> |
</audio> |
Diese Zeilen sollten nun problemlos erkannt und das Audio-File abgespielt werden können. Absichtlich weggelassen habe ich bei den Beispielen die zahlreichen möglichen Attribute wie autoplay, autobuffer und loop sowie die Größenvorgaben für das Control-Panel (unnötig, wenn man mit der default-Standardgröße klarkommt).
Vielleicht geschehen aber auch noch Zeichen und Wunder und der kommende Firefox 4.0 reiht sich in die Riege der MP3-Versteher ein. Dann könnte man auf das multiple Hochladen verzichten. Oder eine der nächsten Safari-Versionen gibt sich mit (den auch bei Wikimedia üblichen) Vorbis-Audio-Dateien im Ogg-Container zufrieden… – ach nee, das versteht ja der neue Internet Explorer noch nicht. Und vermutlich werden Sie in diesem Blog HTML5-Elemente auch erst nach dem Jahr 2020 sehen, denn der 1&1-Blogbausatz erlaubt keine extravaganten Befehle und hinkt mehrere Jahre hinter der sonstigen WordPress-Entwicklung und dessen zahlreichen plug-ins hinterher.