Eléments multimédia
- <video> et <audio>
Les balises <video> et <audio> constituent les deux balises souvent mises en avant pour qualifier les avancées novatrices de HTML 5. Elles traduisent notamment l'omniprésence de la vidéo sur le Web, poussée par des services comme Youtube, qui y associent également des fonctions de partage et de commentaires. Si pour l'heure, la majeure partie des plates-formes de vidéo utilisent des technologies de plug-ins pour lire ces vidéos (comme Flash, Quicktime ou encore Windows Media), c'est bien parce que HTML ne donnait pas la possibilité de contrôler en natif des vidéos ou d'autres fichiers multimédia, comme le son. C'est désormais chose faite avec HTML 5 grâce ces deux balises.
HTML 5 fournit non seulement la possibilité d'intégrer en natif du multimédia, mais offre également une API (Interface de programmation – des méthodes et des événements pour contrôler la lecture) pour manipuler les fichiers. Il permet ainsi de réaliser un lecteur au sein même du navigateur, et non dans une machine virtuelle, comme peut l'être par exemple le lecteur Flash.
<video controls poster="fond.jpg" width="320" height="240">
<source src="video.3gp" type="video/3gp" media="handheld">
<source src="video.ogv" type="video/ogg; codecs=theora, vorbis">
<source src="video.mp4" type="video/mp4">
</video>
Dans ce code, une vidéo est intégrée simplement. L'attribut Poster détermine l'image que l'on souhaite afficher lorsque la vidéo n'est pas lue. Si l'attribut Controls est présent – c'est le cas ici – l'utilisateur spécifie qu'il souhaite afficher l'interface par défaut du lecteur. L'attribut Source quant à lui permet d'indiquer plusieurs sources – ici suivant le format de la vidéo – alors que media spécifie pour quel appareil ou périphérique cette vidéo se destine et type spécifie le codec (le format d'encodage de la vidéo) supporté.
Notons que la balise <audio> partage la même API et les mêmes possibilités de contrôles.
La balise <figure> permet quant à elle de rassembler les éléments de description d'un fichier multimedia, une vidéo, d'un son ou d'une image et de lui associer une légende ou un commentaire par l'élément <legend>, par exemple (voir sur le site du W3C).
- <canvas>
HTML 5 propose cette balise afin de permettre la génération dynamique de graphiques en 2D par des scripts Javascript. Cet élément, une fois de plus, s'attaque à un pan de fonctions généralement réservés aux interfaces riches. <canvas> délimite une zone dans le contenu de la page Web et permet de « dessiner » à l'intérieur de cette zone par le biais de scripts. Cela peut-être des tableaux et graphes, mais également des éléments d'interface, par exemple.
Apple, le concepteur de cette balise, décrit son fonctionnement sur son site. La firme de Cupertino a été le premier éditeur à l'implémenter dans son navigateur Safari. Elle l'est également depuis la version 1.5 Firefox, navigateur Open Source de Mozilla. Ce dernier livre une méthode complète d'utilisation dont voici un extrait :
<html>
<head>
</head>
<body onload="draw()">
<canvas id="canvas" width="300" height="300"></canvas>
</body>
</html>
Voir sur le site du W3C.
- Sécurité et Réseaux,
- Developpement,
- html ,
- 5 ,
- web

Dites moi si je me trompe mais le HTML n'est pas plutôt une implémentation du SGML? (et non un descendant, le descendant du SGML étant XML, et XHTML une implémentation du XML).
C'est bien joli tout ça, mais tant qu'IE aura plus de 60% de part de marché et que Microsoft continuera à ignorer royalement les normes en vigueur tout cela n'est pas près de changer.
Et il ne faut pas oublier non plus qu'une grande partie des webdesigner sont à la base des graphistes qui se moquent royalement du code HTML sous-jacent quand ils créent la charte graphique d'un site.
Et comme c'est Adobe qui propose à la fois Photoshop, Dreamweaver et Flash, il n'a aucun intérêt à faciliter l'utilisation correcte de ces nouveaux standards Web au détriment de Flash...
Pour ma part, je trouve que le passage de html 4.01 au XHTML a été une excellente chose car elle oblige les développeurs à travailler proprement (en fermant toujours les tags qui ont été ouverts, et surtout en obligeant le développeur à fermer les tags dans l'ordre dans lequel ils ont été ouverts, ...).

Deplus, pour des applications web spécifiques, il est possible de définir ses propres tags (puisque c'est de l'xml) et finalement ca permet d'inclure façilement du code xhtml dans un template xml par exemple sans devoir utiliser de CDATA...
Un développeur qui connait le html, apprenait le xhtml en 30 minutes... et pour ceux qui utilisent des softs comme dreamweaver, go live, etc... il faut simplement changer un paramètre...
De coup je trouve ca dommage de porposer du HTML5 et du XHTML5 au lieu de seulement proposer seulement la version X.
C'est plus de boulot pour les concepteurs de navigateurs, on risque de se retrouver avec un mic-mac de html & xhtml (comme c'est encore bien souvent le cas à l'heure actuelle)... bref porposer 2 versions c'est pas vraiment l'idée que je me fait d'une standardisation !!!
C'est bien joli tout ça, mais tant qu'IE aura plus de 60% de part de marché et que Microsoft continuera à ignorer royalement les normes en vigueur tout cela n'est pas près de changer. Et il ne faut pas oublier non plus qu'une grande partie des webdesigner sont à la base des graphistes qui se moquent royalement du code HTML sous-jacent quand ils créent la charte graphique d'un site. Et comme c'est Adobe qui propose à la fois Photoshop, Dreamweaver et Flash, il n'a aucun intérêt à faciliter l'utilisation correcte de ces nouveaux standards Web au détriment de Flash...
Pour info IE s'améliore à chaque version concernant le suivi des normes W3C, et même les plus réfractaires saluent cet effort de la part de MS... donc mauvaise analyse.
D'autre part, quand il s'agit de standard, je suis assez amusé de voir que tous les navigateurs ont une vision "personnelle" du W3C. Tu as plein de jolis tableaux sur le web qui expliquent ça très bien. Et puis j'ajoute enfin un truc : c'est une demande du quidam que d'avoir de jolis sites avec plein de trucs qui font sapin de noël. Dans l'absolu, un site ça peut se résumer à du HTML brut, sans CSS, sans javascript ni quoi que ce soit. Pourtant, ce n'est pas, mais alors pas du tout conseillé de multiplier les truc exotiques, mais c'est pour ainsi dire la norme. Faut attirer le chaland
Article intéressant, dommage juste que le XHTML 5 n'ait pas été très expliqué.
Ben oui mais le Web ce n'est pas que du texte avec 2 videos et 2 MP3 au milieu...
C'est bien gentil le coté structuré du HTML, mais ça a un peu ses limites parfois. flash et Silverlight n'ont pas grand chose à craindre à ce niveau là. Et on peut très bien faire des choses parfaitements ergonomiques en sortant des préceptes de la structure standard made in HTML
Moi ça, ça me fait penser à une chose: Manque de vision à long terme, et aucune tentative d'anticipation sur du plus long terme.
En gros on se contente d'intégrer video et son, quelques éléments "modifiables" coté client et voilà... 15ans pour en arriver là, cool!
Si déjà on met tellement de temps à définir un standard qui se veut etre le point de départ du WEB d'aujourd'hui et de demain, on ne se contente pas de copier ce que les utilisateurs font aujourd'hui. Mais on essai d'anticiper un minimum les besoins de demains.
Ben oui mais le Web ce n'est pas que du texte avec 2 videos et 2 MP3 au milieu...C'est bien gentil le coté structuré du HTML, mais ça a un peu ses limites parfois. flash et Silverlight n'ont pas grand chose à craindre à ce niveau là. Et on peut très bien faire des choses parfaitements ergonomiques en sortant des préceptes de la structure standard made in HTMLMoi ça, ça me fait penser à une chose: Manque de vision à long terme, et aucune tentative d'anticipation sur du plus long terme. En gros on se contente d'intégrer video et son, quelques éléments "modifiables" coté client et voilà... 15ans pour en arriver là, cool!Si déjà on met tellement de temps à définir un standard qui se veut etre le point de départ du WEB d'aujourd'hui et de demain, on ne se contente pas de copier ce que les utilisateurs font aujourd'hui. Mais on essai d'anticiper un minimum les besoins de demains.
J'étais presque à vouloir te dire "totalement d'accord", sauf que:
- Je suis totalement d'accord avec ce que tu dis sur l'enrichissement du web, et surtout des possibilités offertes par flash et silverlight. Seulement, c'est aussi oublier un problème qui est, aujourd'hui encore, d'actualité: les débits. En effet, c'est joli de coller du flash à gogo, mais cela brime littéralement tous ceux qui ne vivent pas à 500m du DSLAM... Enfin bon, j'espère que cette problématique viendra, à terme, à disparaître. J'ajoute aussi un truc plutôt pénible (côté utilisateur): l'absence d'optimisation des contenus flash! C'est limite écoeurant de se prendre 3Mo dans les dents pour trois blings blings et deux conneries qui sonnent!
- Pour ce qui est de l'évolution et l'anticipation, c'est un débat difficile à mener, notamment pour des raisons élémentaires de technologie. Pourquoi? Parce que, fondamentalement, le HTML était au départ prévu pour "tout" faire en interprété. Or, dès que les technologies sont apparues (Javascript, Java, Flash et j'en passe), le HTML s'est vu affublé de balises lui permettant de "contenir" ces composants, sans pour autant réellement les gérer. C'est donc les navigateurs qui se chargent de recoller les morceaux.
A partir de là, un constat s'impose: le HTML, s'il doit se cantonner à la construction d'une armature disposant de conteneurs, sera alors appelé à très peu évoluer. A contrario, s'il devient de plus en plus riche, il sera nécessaire de repenser fondamentalement le langage, car l'interprété se prête assez mal aux contenus plus complexes. J'ajoute enfin que quiconque prétendant pouvoir voir les mutations du web simplement sur cinq ans risque à 99% de se tromper. La seule chose dont on soit sûr, c'est que nombre de machines n'auront pas changées, que nombre d'entreprises exigeront de vieux navigateurs (pour des questions de compatibilité avec l'existant), ceci bridant d'autant tout changement majeur.
Anticiper, c'est jouer les oracles. Dans les technologies, c'est pire encore, car rien n'interdit l'apparition de nouveaux concepts "révolutionnaires"... donc imprévisibles!
J'étais presque à vouloir te dire "totalement d'accord", sauf que:
- Je suis totalement d'accord avec ce que tu dis sur l'enrichissement du web, et surtout des possibilités offertes par flash et silverlight. Seulement, c'est aussi oublier un problème qui est, aujourd'hui encore, d'actualité: les débits. En effet, c'est joli de coller du flash à gogo, mais cela brime littéralement tous ceux qui ne vivent pas à 500m du DSLAM... Enfin bon, j'espère que cette problématique viendra, à terme, à disparaître. J'ajoute aussi un truc plutôt pénible (côté utilisateur): l'absence d'optimisation des contenus flash! C'est limite écoeurant de se prendre 3Mo dans les dents pour trois blings blings et deux conneries qui sonnent!
Là le problème ce n'est pas Flash ou Silverlight.; Il ets parfaitmeent possible de faire une interface avec ces deux techniques sans que l'utilisateur ai besoin d'une ligne 15Mbit/s pour y accéder. Je ne pense pas que le Flash ai attendu l'apogée du "très haut débit" dans le monde pour faire son chemin et il y a presque 10ans on voyait déjà des sites en Flash qui ne demandaient pourtant pas 15jrs de prechargement.
Apres tout un site lourd et mal optimisé ça peut se faire aussi en HTML, là le standard n'y est absolument pour rien…
(…)
Anticiper, c'est jouer les oracles. Dans les technologies, c'est pire encore, car rien n'interdit l'apparition de nouveaux concepts "révolutionnaires"... donc imprévisibles!
Je parlait surtout d'anticiper les usages, pas les technologies (en réponse à la phrase de l'article que j'ai cité). Justement il s'agit là de mettre en place les technologies qui permettront de nouveaux usages… pas l'inverse.
On peut imaginer pleins de choses quant à l'avenir d'internet, des convergences entre médias… Or là tout ce que je vois c'est un standard qui se contente de faire encore et toujours la même chose depuis 15ans: afficher du texte de manière plus ou moins structurée avec un peu de contenu au milieu. La vrai "révolution" viendra quand on sortira de cette approche purement textuelle (ce que font Flash et Silverlight, et donc ce pourquoi ils n'ont rien à craindre de HTML5 à mon sens) en ne considérant le texte que comme un élément parmi d'autres et non plus comme l'élément principal. Mais pour ça il faudra bien sur commencer par le renommer
Présenté comme ça je peux mieux comprendre tes idées, mais encore une fois je rappelle que Flash et consoeurs sont des compilés à télécharger, et qui nécessitent, quoi qu'il arrive (pour le moment) d'être récupérés dans leur intégralité pour fonctionner; A contrario, un site web avec des images manquantes peut continuer à fonctionner. Merci le code interprété!
Personnellement je ne crois guère à la révolution comme tu l'envisages, ceci simplement du fait que cela sera alors une "bête" surcharge de l'existant, et que je doute que cela apporte réellement un bénéfice aux utilisateurs. N'oublions jamais ceci: une norme n'est pour ainsi dire jamais idiote (car normaliser c'est donner de bonnes méthodes), ce sont les codeurs derrière qui sont des nases.
PS: pour les flash à préchargement pourris, prends tous ceux pour présenter les nouveaux films. La plupart sont des enclumes, et à moins d'avoir du 20Mb chez soi, tu es bon pour une à deux minutes d'attente. Pour moi le web ce n'est pas une barre de progression, ça devrait être de l'instantané!
PS2: En complément de la remarque précédente, c'est aussi pour ça que la plupart des webmails restent disponibles dans des versions ultra légères... pour qu'ils soient accessibles depuis n'importe quel navigateur sans dégueuler littéralement en utilisation de bande passante.
Ils feraient mieux de passer enfin à un format qui sépare proprement le contenu de la mise en page...
Ouaiiis, trop la classe : enfin la possibilité de coder comme un porc sans fermer les tags ouverts !!! Ah, bah non, ça c'était déjà dans le HTML 1.0 et ce, jusqu'à la 4.01... Une vraie évolution.. Enfin non, pour reprendre la propagande des souteneurs du HTML 5, un souhait des éditeurs et des développeurs
...
!
Sinon, heureusement qu'on peut continuer dans la voie du XHTML et heureusement que des navigateurs comme Firefox ou Opera signalent les erreurs de syntaxe dans ce cas (et seulement dans ce cas ; pour les ploucs du code, on ne va pas se fatiguer, hein, on affiche ce qu'on peut et tant pis pour les erreurs d'affichage et autres approximations et de rendu). Quand je pense qu'il y a encore des types qui ne comprennent pas pourquoi leur site s'affiche bien avec un navigateur et mal dans un autre (surtout s'il s'agit de Firefox, Opera ou Safari ; avec les plaignants les plus assidus, même pas besoin d'aller chercher à faire entrer IE dans la danse, de toutes façons s'ils le font c'est soit ils codent pour IE et pas pour les autres, soit l'inverse) ça me fait bien marrer
Bon sinon, on jugera sur pièces pour les nouveautés et la suppression de fait des bons vieux DIV-à-tout-faire... Dans l'immédiat, je me "contente" d'XHTML 1.1, mais avec rétropédalage HTML pour les navigateurs qui ne le prennent pas en charge nativement.
Ils feraient mieux de passer enfin à un format qui sépare proprement le contenu de la mise en page...
C'est le but de base de l'XHTML depuis sa naissance (c'est d'ailleurs le concept même de l'XML) : déléguer la mise en page à des fichiers CSS "externes". Si tu le maitrises, c'est propre. Mais rien n'a jamais empêché qui que ce soit d'intégrer du code CSS dans le code HTML via tags et les attributs dédiés. Idem pour le JavaScript. Si c'est bien fait, ça passe, sinon, c'est vite une porcherie.
C'est clair: le principe de CSS permet en outre d'épurer les formulaires en n'ayant qu'une seule et unique mise en page. A partir de là... si les développeurs sont (comme d'habitude hélas) des gorets, c'est vite un carnage, d'autant que l'interprétation de ces CSS est hyper tributaire des navigateurs.
Pour les sceptiques un petit exemple: vous avez déjà constaté qu'un site était bancal sur un navigateur, et pas sur un autre. Potentiellement, "merci" le javascript. Vous avez aussi constaté des mises en page en vrac, voire des textes allant se loger derrière des zones "blanches". "Merci" l'interprétation des CSS...
Avec la description ici faite de ce futur standard, je n'y vois rien d'excitant. J'en vois pas mal qui se plaigne de flash ici, arguant que c'est lourd et déroutant. Pour votre gouverne, si un site en flash est lourd et déroutant, c'est pas la faute a flash mais à son auteur. Il m'arrive a moi aussi d'attendre bêtement qu'une page se charge (sans barre de progression) pour finalement me retrouver devant un site de m#### ou il me faut 15 minute pour trouver une info élémentaire. Et tout ca en HTML. Faut arrêter de se plaindre des outils quand c'est leur manipulateurs qui sont en cause.
Mais je le fais pas, parce que je respecte les internautes et j'aime le travail propre.

Et pour les motivés qui prétendent que flash c'est pas top parce que c'est pas du web instantané, c'est pas l'html5 qui va y changer grand chose a partir du moment ou il faudra lire une vidéo ou une musique... Je développe en Flash, alors c'est sur je pourrais faire le cochon, ne rien optimiser, importer des images 10x trop grandes dans ma librairie, et publier un site a moitié débugger
Et une dernière chose, pour ceux qui se plaignent du poids, la plupart des mes sites, pèsent entre 100 et 500 ko, habillage compris. Pour ce prix la on a de belles fontes, de belles couleurs et de belles animations...
Alors maintenant c'est sur, le même contenu en html pèsera peut être entre 100 et 200ko, mais PUTAIN, QUEL ENNUI