Il y a des matins où j’aimerais rester au lit. Bon, après réflexion ça ne changerait rien vu que même de mon lit je pourrais lire des aberrations tel que “10 Flash Things You Can’t Do With HTML5” (« 10 trucs Flash qu’on ne peut pas faire en HTML5 »).
Ce genre d’articles m’énerve. Si je mets de côté le débat « qui a la plus grosse
liste de possibilités
», il n’empêche que ces comparaisons sont foireuses, car HTML5 y est souvent mal compris. Ça craint, le HTML c’est quand même la base du web.
On a pu en avoir la preuve avec la dernière conférence Adobe MAX. Il y a été présenté un « convertisseur Flash vers HTML5 ». Je veux bien concéder le raccourcis marketing « trucs cools = HTML5 », mais c’est quand même se tirer une balle dans le pied. Le but de HTML est, et restera, de structurer des données. Si on parle d’animations, il faut inclure CSS et/ou Javascript (après il y a un autre débat pour définir si une animation est de la présentation ou du comportement). En bref, il ne faut pas dire « regarde c’est cool, c’est du HTML5 » puisque ça n’a rien de sexy en soit. Par contre, utiliser les dernières avancées des trois langages fondamentaux du web permet de faire des trucs vraiment cools. Si vous n’êtes pas convaincu, je vous présente Paul Rouget.
Je suis encore assez étonné de l’incompréhension du travail du W3C sur HTML5. Le but de HTML5 n’est pas d’innover, mais de standardiser. C’est déjà énorme en soit. Il y a énormément de choses en HTML5 qu’on pouvait déjà faire (à quelques exceptions). Le W3C ne fait que regarder l’existant et propose une façon cohérente pour le faire (via des balises et/ou des API).
Bon, maintenant qu’on a ça en tête, prenons les 10 trucs
super cools
qu’on peut faire en Flash et pas en HTML/CSS/Javascript :
Le buzz, si je puis dire (ah, on me dit que je devrais écrire « ramdam »), autour de HTML5 a créé beaucoup d’articles comme celui-ci. Je comprends tout à fait l’engouement que des développeurs peuvent avoir pour les technologies qu’ils affectionnent (ce billet n’existerait pas si je n’en faisais pas partie). Mais le vrai problème est que tout cela est un débat stérile et qu’on en oublie l’essentiel. Pire, ces articles vont être relayés, référencés, lu, mal-compris et faire partie d’un tout estampillé HTML5.
Par exemple, j’ai déjà vu des présentations sur HTML5 qui parlaient de la balise
C’est un conseil que je donne quand je fais mon cours sur HTML5 : Méfiez-vous de ce que vous pouvez lire sur le web. Il y a beaucoup d’articles périmés ou prématurés.
Pendant que j’y suis, ignorez, oubliez, offusquez toutes dates concernant HTML5. Tout d’abord, parce qu’elles ne signifient rien, ce ne sont que des estimations. Ensuite, il ne faut surtout pas attendre un quelconque aval du W3C pour se lancer sur HTML5 (à moins que vous n’ayez attendu le 8 septembre 2009 avant de faire du CSS 2.1 ?). Et, pour finir, justement, la dernière étape de la spécification est la recommandation. Pour avoir ce statut la technologie doit avoir fait ses preuves comme étant stable. Si vous attendez… Elle ne deviendra jamais une recommandation. J’ai même envie de dire, si vous attendez, elle mettra encore plus de temps avant de devenir une recommandation.
Bon, maintenant que vous avez tout lu, allez apprendre HTML5 ou me faire un truc de folie avec les nouvelles API.
liste de possibilités
», il n’empêche que ces comparaisons sont foireuses, car HTML5 y est souvent mal compris. Ça craint, le HTML c’est quand même la base du web.
On a pu en avoir la preuve avec la dernière conférence Adobe MAX. Il y a été présenté un « convertisseur Flash vers HTML5 ». Je veux bien concéder le raccourcis marketing « trucs cools = HTML5 », mais c’est quand même se tirer une balle dans le pied. Le but de HTML est, et restera, de structurer des données. Si on parle d’animations, il faut inclure CSS et/ou Javascript (après il y a un autre débat pour définir si une animation est de la présentation ou du comportement). En bref, il ne faut pas dire « regarde c’est cool, c’est du HTML5 » puisque ça n’a rien de sexy en soit. Par contre, utiliser les dernières avancées des trois langages fondamentaux du web permet de faire des trucs vraiment cools. Si vous n’êtes pas convaincu, je vous présente Paul Rouget.
Je suis encore assez étonné de l’incompréhension du travail du W3C sur HTML5. Le but de HTML5 n’est pas d’innover, mais de standardiser. C’est déjà énorme en soit. Il y a énormément de choses en HTML5 qu’on pouvait déjà faire (à quelques exceptions). Le W3C ne fait que regarder l’existant et propose une façon cohérente pour le faire (via des balises et/ou des API).
Bon, maintenant qu’on a ça en tête, prenons les 10 trucs
super cools
qu’on peut faire en Flash et pas en HTML/CSS/Javascript :
-
HTML5 can’t interact with webcam — HTML5 ne peut pas utiliser la webcam
Soit, pour l’instant.<device>est précisément en cours de conceptualisation pour faire ça. Petite précision, il faut bien évidemment se dire que ça sera à utiliser via une API et donc en Javascript.
D’un point de vue plus personnel je trouve l’intérêt relatif. J’ai très rarement utilisé ma webcam dans Flash.
-
HTML5 video cannot be used on a 3D plane — Les vidéos HTML5 ne peuvent pas être utilisées avec de la 3D
Bon, toujours d’un point de vue personnel, l’intérêt est toujours aussi limité hormis le côté bling-bling.
Ensuite,<video>+ CSS3 transform + Javascript ça ne permet pas de le faire ?
-
HTML5 cannot record audio from your microphone — HTML5 ne peut pas enregistrer à partir du microphone
Voir 1).
-
HTML5 cannot do any sort of web conferencing — HTML5 ne permet pas de faire de visioconférence
Ce point était vraiment gratuit à partir du moment où il n’est pas possible d’utiliser ni la webcam ni le micro. L’usage est particulièrement ciblé ce qui réduit les cas d’utilisation (<troll>mon MacBook Pro i5 flambant neuf a déjà du mal à lire une pauvre vidéo Flash alors de la visioconférence…</troll>).
Ensuite, j’imagine qu’en combinant<video>,<device>et les WebSockets (en mode binaire, j’en fait la demande. Mozilla tu me lis ?) j’imagine que c’est largement faisable. (Voir aussi P2P connections)
-
HTML5 cannot add dynamic objects to go over the video, like captions, titles, or navigational items — HTML5 ne permet pas d’afficher des objets sur une vidéo comme des sous-titres, des titres, ou une navigation
Bon, là c’est clairement du bullshit. Oui, on ne peut pas faire ça en HTML5. Mais on ne peut pas le faire non plus en MXML. Il faudra forcément utiliser autre chose, comme de l’ActionScript. Oh ! Mais on peut faire la même chose avec Javascript ! Sans parler de<track>qui permet de baliser des éléments à synchroniser, SMIL qui est un standard spécialement conçu pour ça ou encore de la possibilité de le faire avec n’importe quelle balise et du Javascript.
-
HTML5 cannot record from your webcam — HTML5 ne peut pas enregistrer à partir de la webcam
Voir 1). En rajoutant localStorage c’est faisable.
-
HTML5 cannot create desktop apps — HTML5 ne permet pas de créer des applications
Quoi ? HTML5 n’est pas un poney ? Grosse déception.
Allez, pour ceux qui n’ont toujours pas compris, HTML5 permet de structurer des données, ce n’est pas à lui de se lancer en mode desktop, c’est le boulot du navigateur. Et puis c’est un peu ridicule de parler de AIR qui permet d’utiliser du Flash en mode desktop ET aussi du web.
-
HTML5 can’t handle video with alpha channels — HTML5 ne gère pas les vidéo qui ont un canal alpha
Bon, une fois de plus une utilisation de niche. Par contre, on peut effectivement utiliser le canal alpha d’une vidéo en utilisant<canvas>.
-
HTML5 doesn’t yet support P2P — HTML5 ne permet pas le P2P
Je crois que j’ai déjà répondu au point 4). WebSockets FTW!
-
HTML5 doesn’t do fullscreen mode — HTML5 ne permet pas le plein écran
J’imagine que l’auteur parlait essentiellement de la vidéo. Je veux bien accorder ce point. Autant je comprends la position du W3C qui n’autorise pas ces pratiques pour des raisons de sécurité et de confort utilisateur. Autant c’est une demande constante chez les clients et une grosse cause de déception. Cela dit, le fullwindows c’est joli (ça change quoi).
Le buzz, si je puis dire (ah, on me dit que je devrais écrire « ramdam »), autour de HTML5 a créé beaucoup d’articles comme celui-ci. Je comprends tout à fait l’engouement que des développeurs peuvent avoir pour les technologies qu’ils affectionnent (ce billet n’existerait pas si je n’en faisais pas partie). Mais le vrai problème est que tout cela est un débat stérile et qu’on en oublie l’essentiel. Pire, ces articles vont être relayés, référencés, lu, mal-compris et faire partie d’un tout estampillé HTML5.
Par exemple, j’ai déjà vu des présentations sur HTML5 qui parlaient de la balise
<dialog>. C’est une balise morte-née mais qui existe tout de même dans l’inconscient du web. Peu sont ceux qui vont consulter la spécification pour s’assurer que ce qu’ils lisent est correct.C’est un conseil que je donne quand je fais mon cours sur HTML5 : Méfiez-vous de ce que vous pouvez lire sur le web. Il y a beaucoup d’articles périmés ou prématurés.
Pendant que j’y suis, ignorez, oubliez, offusquez toutes dates concernant HTML5. Tout d’abord, parce qu’elles ne signifient rien, ce ne sont que des estimations. Ensuite, il ne faut surtout pas attendre un quelconque aval du W3C pour se lancer sur HTML5 (à moins que vous n’ayez attendu le 8 septembre 2009 avant de faire du CSS 2.1 ?). Et, pour finir, justement, la dernière étape de la spécification est la recommandation. Pour avoir ce statut la technologie doit avoir fait ses preuves comme étant stable. Si vous attendez… Elle ne deviendra jamais une recommandation. J’ai même envie de dire, si vous attendez, elle mettra encore plus de temps avant de devenir une recommandation.
Bon, maintenant que vous avez tout lu, allez apprendre HTML5 ou me faire un truc de folie avec les nouvelles API.
