La balise <video>
Par Laurentj le mardi, avril 17 2007, 14:35 - Technologies Web - Lien permanent
Le whatwg propose une nouvelle balise,<video> dans HTML5, pour incorporer facilement des vidéos dans une page html. Certains ne voient pas l'intérêt de cette balise, dans la mesure où la balise <object> (ou <embed>) rempli soit disant très bien ce rôle. Je ne suis pas d'accord avec eux, et voici pourquoi je trouve que cette balise <video> est une bonne chose. (Mise à jour : une version plus récente de cet article est disponible !)
Écriture de la balise
La balise <video> est plus simple à écrire, car il y a moins de paramètres que la balise <object>.
Simplicité de l'API
Au niveau de l'API : alors que chaque plugin propose au travers de la balise <object>, une API différente (voire pas du tout quand c'est une video embarquée dans du flash), la balise <video> propose une API unifiée. On a ainsi toujours les mêmes méthodes, start(), stop() etc, quelque soit le codec (qui pourrait être livré sous forme de plugin).
Meilleure ergonomie
Il est possible d'indiquer dans la balise <video>, l'interface que l'on veut utiliser : soit on veut que le navigateur affiche des boutons par défaut (lecture, arret etc..), soit on affiche soit même ses propres boutons (en html). Cela permet alors une meilleure intégration dans le navigateur et interactivité avec le navigateur dans le premier cas (en facilitant le travail du développeur), ou une meilleure intégration dans la page HTML pour le deuxième cas. Fini les lecteurs flash qui jurent avec le design du site, et que l'on ne peut modifier.
Et bien sûr, on peut imaginer que l'utilisateur puisse configurer son navigateur de façon à toujours afficher les boutons par défaut, de telle manière que l'interface de pilotage de lecture de la vidéo soit toujours la même.
Meilleure Accessibilité
Bien entendu, la balise video a une valeur sémantique, qui permet à tout navigateur de savoir implicitement qu'à l'endroit où il y a la balise <video>, il y a une vidéo. Un navigateur prenant en compte un handicap spécifique, peut alors mieux agir sur le contenu. Et comme il y a une API unifiée, il peut piloter la lecture de la vidéo : il peut en effet proposer une interface spécifique pour l'utilisateur, pour lire le contenu. Par exemple, afficher des gros boutons pour les mal-voyants, lancer la vidéo dans une autre fenêtre en zoomant dessus etc..
Format libre préconisé
La spécification du whatwg propose que les navigateurs embarquent par défaut les codecs du format ouvert et libre OGG. Cela garanti d'une part que n'importe quel éditeur de navigateur puisse comme tout le monde proposer un lecteur vidéo sans avoir à reverser des royalties à quiconque. Et cela permet à l'utilisateur de ne rien avoir à installer (au moins pour lire les fichiers OGG), et moins de souci aussi pour le développeur du site : si il propose sa vidéo en OGG, il est sûr que ses internautes n'auront rien à installer (et comme il existe pléthore d'encodeur OGG libres et gratuits...).
Mais bien sûr, le navigateur peut embarquer en plus tout autre codec (soit nativement, soit après une installation manuelle). Cerise sur le gateau, OGG est très performant en terme de compression et de très bonne qualité. (Personnellement, j'ai toute ma CDTèque stockée sur mon disque dur en OGG).
À noter que dans les spécifications de HTML5, il y a aussi une balise <audio> pour laquelle on retrouve les mêmes avantages que la balise <video> par rapport à la balise <object>.
Commentaires
Corrige-moi si je me trompe mais tu n'as sans doute pas encodé ta CDthèque dans un format vidéo...
Le format OGG est un conteneur au même titre que AVI, comme le dit la spécification:
Le format préconisé pour la balise
<video>est donc un container OGG, dans lequel la vidéo est encodée au format Theora, et le son au format Vorbis.Ceci dit, c'est une très bonne chose que la spec encourage l'utilisation de ces formats libres, très communs sous Linux mais trop souvent illisible sous Windows. Ce format est en effet libre de brevets et redevances (au contraire de ses concurrents MPEG-4, WMV, Real, ou Quicktime), et donc préféré pour la génération de vidéos par les logiciels libres. Je pense d'ailleurs que c'est d'abord cet élément (plutôt que les qualités intrinsèques du format) qui a joué en faveur de son utilisation par défaut.
Ceci dit je pense qu'une "standardisation" de l'API relative à la balise <object> pour les types de formats de données courants (bien que cette API puisse rester extensible) et la mise en avant de formats précis aurait été tout aussi bien.
non bien sûr, j'ai oublié de préciser en effet que j'ai utilisé Ogg Vorbis.
non, parce que object n'a aucune valeur sémantique, donc on n'a pas les avantages au niveau accessibilité, ergonomie et.. Et puis avoir une méthode start() sur une balise object n'aurait aucun sens si le contenu affiché par la balise object est une image par exemple...
vivement que ça sorte après il faudra le temps pour que ça se répande
Il y a eu une discussion là dessus sur le HTML WG. Malheureusement à ce que j'ai pu lire (j'ai 1200 mails en retard là...) le format n'est pas encoré défini. Theora a beaucoup d'avantages bien sûr, mais il ne faut pas oublier que Microsoft et Apple font également partie du WG et ont leur mot à dire, et justement ils ne sont pas vraiment d'accord sur Theora. C'est une discussion assez épineuse...
Au final c'est vrai que <video> a beaucoup d'avantages, mais d'abord il y a beaucoup à définir. Après (et comme d'habitude) il faut que ça soit implémenté dans les navigateurs, et ça c'est une autre histoire.
Moi je vois le HTML5 comme le langage pour personne qui n'y connait rien, et dans ce sens <video> est largement mieux que <object>. Essayez d'expliquer à votre grand mère que si vous mettez <object> vous pouvez avoir une vidéo...
Et pour cause ! Si un format libre comme OGG est préconisé, cela veut dire la mort de leurs formats propriétaires ! En effet, si le développeur web sait que OGG est pris en charge par tous les navigateurs (parce que c'est dans le standard), pourquoi irait-il s'embêter avec des formats proprios avec lesquels il lui faudrait débourser des sous pour les encodeurs ?
Maintenant, peut être que cette préconisation sautera, mais c'est pas ça qui va empêcher la balise video d'exister (au lieu d'avoir un codec embarqué, l'utilisateur l'installera, comme il le fait déjà avec les plugins pour object)
Certes cette balise semblerait nous faciliter le travail d'écriture, mais HTML est un langage pour structurer du contenu et non pour importer d'autres formats de documents, c'est pourquoi il est nécessaire que les autres formats externes (animations, images, vidéos, tableurs, etc.) au code HTML (bien que graphiquement rendu avec la page HTML) soit traités de manière identique en tant qu'objet externe. Les images devraient également être implémentées via cette balise <object>. Bien que cela pourrait faciliter notre boulo, il est nécessaire de ne pas oublier que le HTML est là pour structuer le contenu et non pour faire des plaquettes commerciales.
Nico : je ne suis pas du tout d'accord avec toi. Une video, une image, c'est du contenu. Il n'y a pas que le texte qui définit un contenu documentaire. Y a qu'à voir le web d'aujourd'hui : les nouveaux sites sont fait de contenu divers et variés. C'est ce qu'on appel le multimedia.
D'autre part, la balise object est totalement inaccessible, ne décrit rien du tout (à part "un truc"). Elle est très bien pour inclure des nouveaux types de contenu non pris en charge nativement par les navigateurs. Mais pour du contenu utilisé régulièrement de nos jours (ici les videos), elle n'est plus adaptée. Il est temps d'avoir une sémantique spécifique pour les types de contenu utilisés intensivement.
Entièrement d'accord avec toi. La vidéo est aujourd'hui un élément majeur du web et le HTML ne peut pas l'ignorer. Cette balise <video> est indispensable si l'on ne veut pas que le standard de lecture vidéo soit l'inclusion de Flash dans un générique <object>.
De même qu'il y a une <img>, il doit y avoir une <video>.
Je doute que créer une balise <video> pour simplifier le taf du type qui tape son HTML changera le problème actuel qui est de savoir si l'internaute à le codec qui va bien ou pas.
Voir du Ogg Théora implémenté en natif dans les navigateur est un doux rêve de libriste (que je suis) mais je 'y crois pas vraiment.
Bref, les vidéos en flash on encore un bel avenir devant eux vu le taux de pénétration de flash dans les navigateur par rapport à tel ou tel codec vidéo...
@laurent : tu es bien trop pessimiste. Tu oublie juste une chose dans ton raisonnement : la spec du WHATWG a été co-écrite en collaboration avec Mozilla, Opera et Apple. Ce qui veut dire que cette balise video, pourrait bien débarquer en force une fois la spec terminée. Et encore, sûrement plutôt que prévu.
Mozilla par exemple n'hésite pas à déjà implémenter certaines parties de cette spec : api pour les applis en mode offline, storage, evenements drag and drop etc...
Et puis la balise video a d'autant plus de chance d'être acceptée, quand on voit le nombre de bug qu'il y a avec tel ou tel plugin
@laurent Et puis tiens, voici à quel point ta vision du futur est erronée : Opera a déjà une version experimentale avec cette balise video. À n'en pas douter, les autres vont suivre.. (sauf peut etre MS, mais IE perd du terrain chaque jour...)
Oula cela m'a l'air très intéressant, mais si on dispose de balises nativement gérée par les navigateurs pour les médias audio et vidéo, que devient la balise object? Elle servirait uniquement pour les anim' flash, ou bien aurait-elle aussi sa propre balise ?
@simay : la balise object continuera a avoir le même rôle et son existance n'est pas du tout remis en cause : pouvoir incorporer dans une page du contenu non pris en charge par le navigateur ou par le langage HTML. Il n'y a pas que flash, mais il y a aussi les applets java, le nouveau silverlight, etc. Ça peut être des plugins pour afficher des documents conçu avec un langage 3D. Il y avait aussi celui pour SVG (mais devenu inutile pour firefox). Bref, ça peut être utile pour tout et n'importe quoi.
Je ne vois par contre pas l'interêt d'avoir une balise "flash", ça n'apporterait à mon avis aucun avantage.
Ogg est un conteneur du groupe Xiph.org, conçu pour être utilisé avec leurs codecs vidéo et audio. Ce format peut tout de même être utilisé avec d'autres codecs. Leurs codecs audio les plus connus sont Vorbis, FLAC et Speex, et pour la vidéo Theora.
Theora fait partie des quatre meilleurs formats vidéo du moment, qui sont Theora, xvid, h264 et VC-1. Theora étant le seul étant royalty et patent-free, mais c'est probablement aussi le moins bien des quatre. Pour VC-1, il n'y a même pas d'implémentation libre actuellement.
Aucun des arguments dans cet article ne me convainc.
Voir les commentaires de
Je trouve le dernier commentaire de Matthew Ratzloff vraiment très bon et je partage tout à faire les mêmes idées. Cette solution me semble vraiment plus appréciable qu'un tag <video>, <audio>, <img>, etc ...
En effet, le code en est relativement plus simplifié, de même que son traitement. Bien sûr on perd un côté sémantique au niveau du langage et du sens de chaque balise si on part du principe que <video> doit représenter une vidéo et pas autre chose. Maintenant, si on se dit que <object> représente une information sous forme d'un *objet* (son, image, vidéo, etc), la nature de cette information n'a pas d'importance, c'est son contenu qui importe.
Il s'agit bien sûr de mon avis personnel et je suis ouvert à vos remarques.
@nicolas : je trouve les arguments donnés par les protagonistes que tu pointes, plutôt pauvres, creux et surtout faisant preuve d'une profonde aversion au changement (ça me rappelle les types qui ne veulent pas passer aux standards, et qui se complaisent dans leurs soupes de balises).
@florent
Simplifié en quoi ? il donne des exemples de balises object avec paramètres dans tous les sens. Ça simplifie quoi franchement ?
C'est bien là le problème de la balise object : c'est que ça ne represente absolument rien. Elle n'a aucun sens. Trop générique.
TOUT est objet dans un document. Du texte, c'est un objet. Un paragraphe c'est un objet. Le balisage HTML est là justement pour différencier les différents type d'objet, les différent type de contenu.
Tout l'intérêt du HTML et du XML est là : c'est de pouvoir décrire du contenu, et non pas juste embarquer du contenu.
Si, justement, donner la nature de l'information, cela a extrêmement d'importance, car alors le navigateur (quel qu'il soit) peut mieux interagir avec le contenu, il a plus d'information pour traiter au mieux ce contenu et donc le restituer au mieux à l'utilisateur.
@florent et @nicolas : à la limite, proposez de simplifier le html, et ne mettons plus qu'une seule balise : <content> (adieu <p>, <ul> etc...). On pourra y mettre ce qu'on veut : du texte, du son, de la video. Bon courage ensuite pour produire vos documents.
« je trouve les arguments donnés par les protagonistes que tu pointes, plutôt pauvres, creux et surtout faisant preuve d'une profonde aversion au changement » (LaurentJ)
Je trouve certains termes choisis pour cette phrase (« pauvres », « creux », « profonde aversion au changement ») exagérément dépréciatifs, mais l'ensemble reponse sur un fond de vérité, puisque les commentaires que j'indique (ainsi que le mien) se contentent de demander quels sont les avantages d'un élément video par rapport à l'élément object.