HTML5 tristounet...Même si les grandes lignes du HTML5 sont reconnues par tous les plus récents navigateurs, Internet Explorer inclus, force est de constater l’accueil plutôt tiède qu’il reçoit de la part d’une grande partie de la communauté des développeurs web. Bien sûr il y a les férus de nouveautés qui se font un devoir de connaître un langage avant le « draft » final mais en général l’engouement ressemble plus à un attroupement d’escargot curieux qu’à une ruée vers l’or…

Un des problème qui pourrait expliquer cet état de fait réside peut-être dans les vœux pieux qui ont parsemés l’élaboration du langage lui-même. À mon humble avis, le niveau de compromis était tel que la conséquence a été de ne pas prendre les décisions qui s’imposaient. Alors pour faire un peu plaisir aux gros joueurs autour de la table de concertation, on se ramasse avec des balises tellement permissives ou « floues » que l’implantation requiert une somme de travail plus grande que d’utiliser les technologies déjà présentes, fonctionnelles et fortement répandues.

En écrivant cela, j’ai évidemment en tête les balises <audio> et <video>. Malgré les avantages assurés d’utiliser les fonctionnalités natives du navigateur pour afficher et contrôler ces médias, le problème réside dans les formats de ces mêmes médias car il y en a plus qu’un de possible. Déjà à ce stade, on voit les embûches de loin…

Alors prenons uniquement ce qui arrive avec le tag <audio>. À la base, il y a trois formats d’encodage qui sont permis, soit le OGG, le MP3 et le WAV. Jusque là, c’est plutôt attirant, on dirait qu’on a le choix. Où ça se gâte c’est qu’il n’y a pas un seul de ces formats qui est accepté par tous les navigateurs du « big five » (Explorer, Firefox, Chrome, Safari, Opera). Vous commencez à saisir vers quel endroit je veux en venir?

Donc pour profiter de la puissance de ces balises et que tout le monde puisse y trouver son compte, on a deux choix : soit on inclus une version supplémentaire du média sur le serveur que l’on offre selon une détection additionnelle, soit on met en place, comme il est souvent recommandé, un « fallback » utilisant le plugin Flash, qui est peut-être une technologie propriétaire mais qui a l’avantage d’être multi-plateforme avec une pénétration de marché importante.

La question à se poser : si on doit déjà construire du code pour que Flash prenne la relève, pourquoi ne pas s’en contenter en attendant d’avoir un remplaçant qui ne demande pas d’élever l’effort de développement?

 

 

Commenter