Jusqu'à il y a peu de temps, intégrer de l'audio ou de la vidéo sur des sites Web nécessitait quasi-obligatoirement l'utilisation de Flash. Cette solution fonctionne correctement mais elle est un peu lourde et nécessite la présente du plugin correspondant. Et, surtout, elle ne fonctionne pas sur les appareils iOS comme l'iPhone ou l'iPad. HTML5 permet d'y palier et cela s’annonçait simple et élégant. C'est raté.
C'est en travaillant sur le site de Saint-Nicolas que l'idée m'est venue : utiliser la balise "audio" de HTML5 pour intégrer l'écoute des morceaux.
Jusqu'à présent, j'utilisais l'excellent Dewplayer, un petit lecteur de MP3 en Flash™ à la fois simple, pratique et avec un look sympa. Seulement voilà, comme énoncé plus haut, cela ne fonctionne pas sur les iTrucs de la pomme. Qu'à cela ne tienne, le support des balises "audio" et "video" se généralisant à vitesse grand V dans les navigateurs, me voilà en quête de la syntaxe des balises en question sur le Web.
Et là, c'est la douche froide : deux familles de navigateurs s'opposent en supportant un format audio différent pour cette balise. D'un côté nous avons Mozilla et Opera qui supportent le format libre Ogg ; de l'autre côté nous retrouvons Apple et Microsoft pour lesquels la balise doit utiliser des fichiers MP3. Enfin, Google, avec Chrome, ne chipote pas et accepte les deux formats. Pour l'instant en tout cas, car Google ne va-t-il pas abandonner le support du MP3 comme ils le font pour le H264 en vidéo ?
Pour terminer ce tour d'horizon, notons qu'Internet Explorer ne supportera les deux balises que dans sa future version 9. Pour les versions actuelles et passées (plus de 50% du trafic web tout de même) c'est Flash™ ou rien.
Alors ben moi je fais comment si je veux utiliser la dernière balise super-hype-de-la-mort-qui-tue ?!? Et bien il va tout simplement falloir mettre les fichiers en double exemplaire : des Ogg et des MP3. Ca c'est de l'optimisation au niveau du stockage, heureusement qu'il n'y en a pas des centaines ! Et pour les vieux coucous, il faudra aussi prévoir un fallback en Flash™. Voici donc à quoi ressemble l'insertion d'un tag "audio" sur le site :
<audio controls="controls" preload="none" autobuffer="false">
<source src="mon_son.mp3" />
<source src="mon_son.ogg" />
<object type="application/x-shockwave-flash" data="dewplayer.swf" width="200" height="20">
<param name="wmode" value="transparent" />
<param name="movie" value="dewplayer.swf" />
<param name="flashvars" value="mp3=mon_son.mp3" />
</object>
</audio>Voilà qui permet d'avoir du son sur presque tous les navigateurs, c'est bien : Firefox et Opera utilisent le Ogg, Safari (OS X, Windows et iOS) utilise le MP3 et les IE se rabattent sur Dewplayer. C'est du tout bon. Ou presque.
*Soupirs*
Car il subsiste un petit problème : le pré-chargement des morceaux qui n'est pas géré de la même façon par tous. En positionnant l'attribut "preload", on empêche Safari de pré-charger. Bien. Mais pas Chrome ! Alors j'ajoute l'attribut "autobuffer". Nickel pour Chrome aussi maintenant. Mais mais mais... Firefox en version 3.6 se fiche totalement des deux attributs et pré-charge quand même... En version 4, tout rentre dans l'ordre. Vivement qu'elle sorte en version définitive celle-là.
Allez, pour finir, cerise sur le gâteau : il reste un soucis avec Safari sous OS X : sans preload, un click sur le bouton de lecture ne fait strictement rien. Il faut bouger le curseur de position pour que la lecture démarre. Après tout, pourquoi pas : ça rappellera aux plus anciens les automobiles des années 50 qui nécessitaient un coup de manivelle pour démarrer !
Ces balises "audio" et "video" ont été faites pour nous simplifier la vie. Pour l'instant, franchement, on est loin du compte. Finalement, c'est pas si mal que ça Flash™ !
