A la découverte de HTML 5
Les éléments multimédias
Le Web est résolument devenu multimédia. Il n’y a qu’à voire l’explosion de la vidéo et de la musique en ligne. Aujourd’hui, tout le monde regarde des vidéos et écoute de la musique en streaming via un simple navigateur Web. Oui mais voilà, HTML 4 n’est pas véritablement fait pour cela. Aujourd’hui, on est obligé de faire appel à des applications tierces. Voilà pourquoi HTML 5 se doit de corriger le tir ! Ainsi, deux nouveaux éléments voient le jour dans HTML 5: audio et video.
Et object / embed alors ???
Comme cela vient d’être dit: le Web est déjà multimédia. Nous n’avons pas attendu l’arrivée de HTML 5 pour afficher des vidéos dans nos pages. Heureusement qu’on a les balises object et embed… Oui mais voilà, c’est loin d’être l’idéal et pour plus d’une raison !
La première raison est purement sémantique. Quand on rencontre une balise object, il est difficile de savoir si il s’agit d’une vidéo, d’un son, d’un jeu ou toute autre application. Et puis il est plus simple d’écrire une balise video ou audio (nous le verrons juste après) qu’une balise object ou embed.
De plus, video et audio ne sont pas de simples balises. En effet, toute une API se cache derrière. Peut importe le format du média (encodage), on trouvera toujours des méthodes telles que play(), pause() ou stop(). En effet, l’acte de lecture est fait par le navigateur et non plus un lecteur tiers (Flash, Silverlight, …). On peut ainsi adapter la vidéo à sa page. Fini les lecteurs tels que Youtube ou Dailymotion qui fusillent le design de vos pages. Là, vous choisissez vous-même vos boutons, leurs emplacements, …
Pour finir, video et audio sont beaucoup mieux en terme d’accessibilité. Ainsi, on peut imaginer un système qui fait un gros zoom sur les boutons de contrôle et sur la vidéo pour les déficients visuels. Aujourd’hui, c’est quelque chose de difficilement réalisable dans les agents utilisateurs avec les pratiques courantes.
La ou les sources de données
Pour indiquer où se trouve le média que l’on souhaite proposer à l’utilisateur, c’est simple: on reprend le modèle habituel avec l’attribut src. Ainsi, cela donne:
Maintenant, admettons que nous ayons plusieurs sources média qui représentent la même chose. Cela peut être utile pour proposer différents niveaux de qualité et différentes sources réseau. C’est possible grâce à l’élément source. Chaque élément source fils d’un élément video ou audio représente une source média différente. Concrètement, ça se traduirait comme cela:
L’agent utilisateur pourra donc sélectionner la source qui lui convient le mieux en fonction des formats qu’il prend en charge et des ressources réseau disponibles (ou non).
Le contrôle des médias
La lecture des médias peut être contrôlée via tout une série de méthodes DOM. Typiquement, on a les méthodes play() et pause(). Une autre méthode qui peut s’avérer pratique: load(). En effet, tant que celle-ci n’a pas été appelée, le média n’est pas téléchargé par l’agent utilisateur. Cela permet d’éviter une consommation inutile de bande passante (par exemple: l’utilisateur n’est pas intéressé par le média embarqué).
On trouve aussi d’autres options intéressantes telles que le contrôle du volume, la position courante de lecture (idéal pour faire une avance rapide). Bref, c’est parfait pour faire un lecteur média complet en quelques lignes et totalement personalisable !
Préconisation des formats libres
Dans l’actuel brouillon, le W3C préconise l’utilisation par défaut de codecs ouverts et libres. Clairement, c’est le container OGG (et ses codecs libres) qui est visé. L’idée est que chaque agent utilisateur embarque avec lui les codecs libres OGG. Le fait qu’ils soient libres supprime tout problèmes de royalties. Et puis ils sont en général assez performants.
Ainsi, on aurait un format de base dans lequel on est certains que l’utilisateur pourra lire le fichier sans avoir à télécharger un composant annexe. Bien évidement, l’utilisation d’autres codecs (DivX, Xvid, Flash …) n’est pas écartée. Il faudrait juste que tout les agents utilisateurs gèrent au moins OGG en natif.
En conclusion …
Bref, l’inclusion des éléments audio et video à HTML 5 est une très bonne idée. Cela permettra d’offrir à l’utilisateur du contenu multimédia sans avoir à passer par une application tierce telle que Flash ou Silverlight. L’inconvénient est que c’est une charge de travail en plus pour l’agent utilisateur. Espérons que l’implémentation de ces éléments se fera de façon homogène sur tout les navigateurs. Dans le cas contraire, tout ceci n’aura servi à rien car les développeurs et utilisateurs préféreront garder les outils tiers actuels.
Quel sera l’impact de HTML5 sur la vidéo en ligne ? | Webd a écrit
le 2 août 2008 à 19:13
[...] 2010)… L’une des grandes nouveautés de cette spécification, c’est la gestion native des médias vidéo et audio embarqués. Concrètement, il sera aussi simple d’insérer une vidéo qu’une image dans une page. [...]