Introduction. Public visé

Transcription

1 Introduction Bienvenue dans la seconde édition du spectacle de Remy et Bruce. Depuis la sortie de la première édition en juillet 2010, beaucoup de choses ont changé : HTML5 est désormais bien plus répandu et Internet Explorer 9 a fini par voir le jour ; Google Chrome a annoncé qu il abandonnerait le format H.264 pour les vidéos ; Opera a travaillé sur les flux vidéo émis par la webcam de l utilisateur la fièvre HTML5 est devenue l hystérie HTML5 car toute nouvelle technologie est baptisée HTML5 par les clients, les responsables et les journalistes. Toutes ces modifications, et bien plus encore, sont présentées dans cette nouvelle édition qui inclut également un nouveau chapitre consacré aux réalités de l implémentation de ces nouvelles technologies avec les anciens navigateurs. Nous avons également corrigé quelques bogues et des erreurs de frappe, réécrit certaines parties un peu trop obscures et, évidemment, nous n avons pas pu résister à la tentation d ajouter au moins une blague. Nous sommes deux développeurs qui pratiquons HTML5 depuis Noël 2008 en le testant, en participant à la liste de diffusion et, de façon générale, en essayant de contribuer à l apprentissage de ce langage. Étant développeurs, nous nous intéressons surtout à la mise en place de solutions : c est la raison pour laquelle ce livre est consacré aux problèmes que HTML5 peut résoudre plutôt qu à une étude académique du langage lui-même. Bien que Bruce travaille pour Opera Software, qui a initié le processus conduisant à HTML5, il n est pas membre de l équipe chargée de la spécification du langage : il ne s intéresse qu à l utilisation du langage en tant que développeur. Public visé Bien qu aucune connaissance préalable de HTML5 ne soit requise, nous supposons que vous connaissez bien (X)HTML et que vous êtes habitué au concept de marquage sémantique. Peu importe que vous connaissiez mieux HTML ou XHTML : il suffit que vous sachiez utiliser un système de marquage strict. Vous n avez pas besoin d être un expert en JavaScript, mais vous devez comprendre le rôle sans cesse croissant qu il joue dans le développement web moderne des termes comme DOM et API ne devraient pas vous faire peur. Vous êtes toujours là? Bien!

2 2 INTRODUCTION À HTML5 Ce que ce livre n est pas Cet ouvrage n est pas un manuel de référence. Nous ne passerons pas en revue chaque élément ou chaque API de façon linéaire, en les décrivant les uns après les autres. La spécification se charge déjà parfaitement de ce travail et constitue donc une ressource essentielle. En revanche, la spécification ne montre pas comment utiliser les éléments ou les API, ni comment ils interagissent les uns avec les autres. Nous présenterons donc des exemples en décrivant les éléments à mesure de nos besoins, en y revenant éventuellement plus tard. En lisant le titre de ce livre, puis en le parcourant, confortablement installé, vous remarquerez également qu il n est pas exhaustif. L explication d une spécification de 700 pages (à titre de comparaison, la première spécification de HTML faisait trois pages) dans un livre de taille raisonnable nécessiterait l utilisation de techniques futuristes ce qui pourrait être intéressant ou de polices microscopiques ce qui le serait moins. Qu entendons-nous par HTML5? Cette question pourrait sembler saugrenue, mais l on a souvent tendance à désigner sous le terme HTML5 toutes les nouvelles technologies du Web. Nous avons par exemple déjà vu SVG (Scalable Vector Graphics) désigné comme l une des technologies de la famille HTML5, alors que c est une spécification du W3C qui a déjà dix ans! Une confusion supplémentaire vient du fait que la spécification officielle du W3C est un peu comme un virus : des parties s en détachent et deviennent leurs propres spécifications, comme Web Sockets ou Web Storage (bien qu elles proviennent du même groupe de travail et des mêmes éditeurs). Dans ce livre, nous présentons HTML5 et les spécifications apparentées qui proviennent du WHATWG (nous décrirons cet acronyme un peu plus loin). Nous ajouterons également un petit plus la géolocalisation qui n a rien à voir avec notre définition de HTML5, mais que nous inclurons ici parce qu elle nous intéresse beaucoup et qu elle fait partie de la nouvelle vague des technologies des applications web modernes.

3 INTRODUCTION 3 Qui? Quand? Pourquoi? Bref historique de HTML5 En général, les sections historiques des livres informatiques nous ennuient. Vous n avez pas besoin de connaître l histoire d ARPANET ni celle de HTTP pour savoir utiliser un nouveau langage. Quoi qu il en soit, il est quand même intéressant de connaître l histoire de HTML5 car elle permet de mieux comprendre certains de ses aspects et de répondre aux questions du style Mais pourquoi ont-ils fait ce choix? HTML5 a failli ne jamais exister En 1998, le W3C décida qu il ne ferait plus évoluer HTML. Le futur, d après eux (et les auteurs de ce livre), était représenté par XML : HTML fut donc figé dans sa version 4.01 et une nouvelle spécification, appelée XHTML, vit le jour. XHTML est une version XML de HTML : elle exige par conséquent le respect des règles syntaxiques de XML (valeurs des attributs systématiquement entre guillemets, utilisation de marqueurs autofermants, etc.). Il en existe deux variantes (en fait trois si vous tenez compte des frames HTML qui ont disparu de HTML5) : XHTML transitionnel et XHTML strict, la première ayant été conçue pour faciliter le passage de HTML vers le standard que représente la seconde variante. Ce choix eut le mérite d encourager une génération de développeurs (en tout cas les développeurs professionnels respectueux des standards) à penser en termes de code valide et bien structuré. Le W3C commença ensuite à travailler sur la spécification XHTML 2.0 qui représente une modification radicale du langage puisqu elle brise la compatibilité ascendante afin d être encore plus logique et mieux conçue. Un petit groupe de personnes de la société Opera n était cependant pas convaincu que XML représentait le futur des développeurs web. Pour prouver son intuition, ce groupe élabora une spécification améliorant les formulaires HTML, sans pour autant remettre en cause la compatibilité avec les versions précédentes du langage. Cette spécification devint Web Forms 2.0 et fut ensuite intégrée à la spécification HTML5. Ce groupe fut rapidement rejoint par des développeurs de Mozilla et, sous la houlette de Ian Hixie Hickson, continua à travailler sur la spécification avec le soutien d Apple. Il prit le nom de WHATWG (Web HyperText Application Technology Working Group, www. whatwg.org). Ses origines apparaissent d ailleurs encore dans la notice de copyright de la version WHATWG de la spécification : Copyright Apple Computer, Inc., Mozilla Foundation, and Opera Software ASA (notez que vous avez le droit d utiliser et de reproduire cette spécification, et que vous pouvez en produire des travaux dérivés). Hickson passa d Opera à Google, où il continua de travailler à plein-temps pour HTML5 (qui s appelait alors Web Applications 1.0).

4 4 INTRODUCTION À HTML5 À la recherche de la spécification En 2006, le W3C admit qu il avait été peut-être un peu trop optimiste quant au passage à XML (et, par extension, à XHTML 2.0). Selon les propres termes de Tim Berners-Lee : Nous devons faire évoluer HTML petit à petit. La tentative de passer à XML en introduisant simultanément les guillemets systématiques autour des valeurs des attributs, les slashes dans les marqueurs vides et les espaces de noms, ne fonctionne pas ( node/166). Le groupe de travail HTML ainsi ressuscité vota pour utiliser la spécification Web Applications du WHATWG comme base de la nouvelle version de HTML et commença alors un curieux processus dans lequel la même spécification était développée simultanément par le W3C (codirigé par Sam Ruby d IBM et Chris Wilson de Microsoft, puis, plus tard, par Ruby, Paul Cotton de Microsoft et Maciej Stachowiak d Apple) et par le WHATWG toujours dirigé par Hickson. Ce processus a été inhabituel à bien des égards. D abord par son ouverture extraordinaire : toute personne pouvait rejoindre la liste de diffusion du WHATWG et contribuer à la spécification. Tous les courriers de cette liste étaient lus par Hickson ou l équipe de base du WHATWG (celle-ci comprenait quelques célébrités comme l inventeur de JavaScript, le directeur technique de Mozilla, Brendan Eich, l architecte de Safari et de WebKit, David Hyatt, et l inventeur de CSS et directeur technique d Opera, Håkon Wium Lie). La spécification HTML5 étant développée à la fois par le W3C et le WHATWG, il en existe plusieurs versions. est la version officielle du W3C, tandis que est le dernier brouillon il est donc susceptible d être modifié. Le WHATWG ayant abandonné les numéros de version, le 5 a donc disparu : la spécification s intitule désormais HTML the living standard et se trouve à l URL Mais attention : elle contient un très grand nombre d idées expérimentales ne pensez pas que tout ce qui se trouve dans ce document a été implémenté, voire totalement finalisé. Cette spécification, en revanche, contient un grand nombre d annotations concernant l état de l implémentation par les différents navigateurs. La page présente la totalité de la spécification WHATWG Web Applications 1.0 sous la forme d une page unique, mais elle peut faire planter votre navigateur car elle contient de très nombreux scripts. Une bonne partie de la spécification est formée par les algorithmes qui sont, en réalité, destinés à ceux qui implémentent HTML (les éditeurs des navigateurs web, par exemple). La spécification que nous avons ajoutée à nos favoris se trouve à l URL les parties destinées aux implémentations ont été supprimées et elle utilise une jolie feuille de style CSS, conçue par Ben Schwarz. Elle contient également les parties expérimentales. Si vous êtes perdu, la page énumère et décrit les différentes versions de la spécification. La géolocalisation n est pas une spécification du WHATWG elle est disponible à l URL geolocation-api/.

5 INTRODUCTION 5 Les bonnes idées ont été implémentées et les mauvaises rejetées, quelles que soient leurs sources ou la personne qui les a émises. De bonnes idées ont notamment été inspirées par Twitter, les blogs et IRC. En 2009, le W3C cessa ses travaux sur XHTML 2.0 et redirigea ses ressources vers HTML5 : il devint alors clair que HTML5 avait gagné la bataille des philosophies pureté de la conception au prix d une rupture de la compatibilité ascendante contre pragmatisme pour ne pas casser le Web. Le fait que les groupes de travail HTML5 comprenaient des représentants de tous les éditeurs de navigateurs a également joué un rôle important : s ils ne voulaient pas implémenter une partie de la spécification (Microsoft n a pas voulu de <dialog> et Mozilla s est opposé à <bb>), cette partie était supprimée. Selon Hickson, la réalité est que les éditeurs de navigateurs ont un droit de veto sur tout ce qui se trouve dans la spécification puisque, s ils ne l implémentent pas, cette spécification ne sera qu un roman de science-fiction ( webstandards.org/2009/05/13/interview-with-ian-hickson-editor-of-the-html-5- specification/). De nombreux participants considèrent que cette pratique est désastreuse : ils prétendent, non sans raison, que les éditeurs de navigateurs ont kidnappé leur Web. Pour être honnêtes, les relations entre le W3C et le WHATWG n ont pas été aussi chaleureuses qu elles auraient pu l être. Alors que le W3C fonctionne selon une approche par consensus, Hickson a continué à travailler comme il l avait toujours fait au sein du WHATWG comme un dictateur bienveillant (beaucoup critiqueront notre utilisation du mot bienveillant dans ce contexte). Il est certainement vrai qu Hickson avait des idées très arrêtées sur la façon de développer le langage. Les philosophies de HTML5 HTML5 repose sur une suite de principes de conception bien établis ( Il a trois buts principaux : préciser les comportements des navigateurs actuels ; définir pour la première fois le traitement des erreurs ; faire évoluer le langage afin de faciliter le développement des applications web. Ne pas briser la compatibilité avec les pages web existantes De nombreuses méthodes actuelles de développement de sites et d applications web reposent sur des fonctionnalités non documentées (ou non spécifiées) qui ont été ajoutées aux navigateurs au cours du temps. XMLHttpRequest (XHR), par exemple, est employée par un nombre incalculable de sites utilisant Ajax. Cette fonctionnalité a été inventée par Microsoft ; bien qu elle ait été ensuite ajoutée à tous les autres navigateurs par reverse-engineering, elle

6 6 INTRODUCTION À HTML5 n avait jamais été spécifiée comme standard (Anne Van Kesteren d Opera l a finalement spécifiée dans le WHATWG). Une partie aussi vitale pour de nombreux sites reposait donc entièrement sur du reverse-engineering! L une des premières tâches de HTML5 a donc consisté à documenter ce qui ne l était pas, afin d augmenter l interopérabilité en laissant moins de doutes aux développeurs web et à ceux qui implémentent les navigateurs. Il fallait également définir sans ambiguïté la façon dont les navigateurs et les autres agents utilisateurs devaient traiter les pages non valides. Ce n était pas un problème avec XML car ce dernier définit une gestion des erreurs draconienne dans laquelle le navigateur doit cesser le rendu de la page dès qu il rencontre une erreur. Nous pensons que l une des raisons principales du succès rapide du Web est qu une page utilisant un marquage incorrect avait quand même une chance de s afficher sur certains navigateurs, voire tous. Le ticket d entrée pour publier sur le Web était donc très bas, à charge pour chaque navigateur de décider de la façon d afficher une page incorrecte. Un code aussi simple que <b><i>bonjour maman!</b></i> (notez les marqueurs mal imbriqués) produit des DOM différents selon les navigateurs, ce qui implique que la même CSS peut donner un résultat totalement différent également et que l écriture de code JavaScript portable sur tous les navigateurs est bien plus difficile qu elle ne devrait l être. Un DOM cohérent est un élément si important de la conception de HTML5 que le langage lui-même est défini en termes du DOM. Pour une plus grande interopérabilité, il est vital que tous les navigateurs traitent les erreurs de la même façon et produisent donc le même DOM, même lorsqu ils sont confrontés à un code HTML incorrect. Il a donc été nécessaire de spécifier cet aspect : parmi les 700 pages de la spécification HTML5, 300 seulement sont consacrées aux développeurs web (c est-à-dire vous et moi) ; le reste est destiné à ceux qui implémentent des navigateurs et leur explique exactement comment analyser les marqueurs, même si le marquage est incorrect. Applications web Un nombre sans cesse croissant de sites web sont des applications web ; ils imitent les applications que l on trouve sur un ordinateur au lieu de se contenter de proposer des documents statiques composés d images, de textes et de liens, comme ceux qui constituent l essentiel du Web. À titre d exemple, nous pouvons citer les traitements de texte en ligne, les outils d édition de photos, les sites de cartographie, etc. Utilisant fortement JavaScript, ces sites ont poussé HTML 4 dans ses derniers retranchements. HTML5 spécifie de nouvelles API DOM pour le glisser-déposer, les événements envoyés par le serveur, le graphisme, la vidéo, etc. Ces nouvelles interfaces exposées par HTML à JavaScript au moyen d objets du DOM facilitent l écriture de ce type

7 INTRODUCTION 7 d applications en utilisant désormais des standards bien établis à la place de bricolages à peine documentés. L existence d un standard ouvert (libre d utilisation et d implémentation) pouvant rivaliser avec les standards propriétaires comme Flash d Adobe ou Silverlight de Microsoft est très importante. Quoi que vous pensiez de ces technologies et de ces sociétés, nous croyons que le Web est trop vital pour la société, le commerce et la communication pour être entre les mains d un seul éditeur de logiciels. Qu aurait été la Renaissance si Caxton avait détenu un brevet et un monopole pour la peinture sur toile? Ne pas casser le Web Il existe déjà des gazillions de pages web qui doivent impérativement continuer à fonctionner. HTML5 est donc (essentiellement) un sur-ensemble de HTML 4 qui continue de définir la façon dont les navigateurs doivent traiter les marqueurs historiques comme <font>, <center> et les autres marqueurs de présentation : des millions de pages web les utilisent (même si les développeurs ne devraient pas s en servir puisqu ils sont obsolètes). Pour ces développeurs, le marquage sémantique continue de régner (chaque lecteur pourra se faire sa propre idée quant au fait de savoir si la sémantique de HTML5 est suffisante ou si le langage contient trop d éléments). À titre de bonus, les règles d analyse non ambiguës de HTML5 devraient garantir que les anciennes pages fonctionneront encore, car l analyseur de HTML5 sera utilisé pour tous les documents HTML (aucun navigateur ne fournit encore un analyseur HTML5 par défaut, bien qu au moment où ce livre est écrit, Firefox dispose d un analyseur expérimental qui peut être activé à partir de la page about:config en initialisant le choix html5.enable à true). Et XML? HTML5 n est pas un langage XML (ce n est même pas un langage SGML, au cas où vous voudriez le savoir). Il doit être servi comme du text/html. Si toutefois vous avez besoin d utiliser XML, vous pouvez vous servir de XHTML5 qui dispose des mêmes fonctionnalités mais exige une syntaxe plus stricte (c est exactement la même que celle de XHTML). Le document doit alors être un document XML bien formé et doit être servi avec un type MIME XML. Cela dit, Internet Explorer 8 et ses prédécesseurs ne sauront pas le traiter (ils proposeront de le télécharger au lieu de l afficher) : c est la raison pour laquelle nous utilisons la syntaxe HTML et non XHTML dans ce livre.

8 8 INTRODUCTION À HTML5 Support de HTML5 HTML5 progresse désormais très rapidement ; bien que la dernière spécification W3C ait été publiée en mai 2011, les navigateurs implémentaient déjà le support HTML5 (notamment les API) bien avant cette date. En outre, ce support de HTML5 continue de croître à mesure que les navigateurs implémentent ses fonctionnalités les endroits où nous écrivons ceci n est disponible qu avec le navigateur X seront donc rapidement obsolètes, ce qui est une bonne chose. Les nouvelles fonctionnalités des navigateurs sont très intéressantes et nombreux sont les créateurs de sites web qui prétendent tester le support HTML5 pour en tirer parti. Malheureusement, beaucoup confondent un peu toutes les spécifications en mélangeant HTML5, les spécifications dérivées du WHATWG comme Web Workers et se gargarisent de termes à la mode comme WebGL, SVG, l API File du W3C, Media Queries et certains ajouts propriétaires d Apple N accordez pas trop d importance à ces sites. Leur intérêt est quelconque et leur définition de HTML5 est fausse et trompeuse. Comme le fait remarquer Patrick Lauke, notre éditeur, HTML5 n est pas une compétition. Le principe n est pas que le premier navigateur à tout implémenter sera celui qui gagnera la course de l Internet. L objectif de la spécification est que tous les navigateurs proposent le même ensemble de fonctionnalités. Si vous voulez connaître l état de l art concernant le support de ces nouvelles technologies web, rendez-vous à l URL Allons-y Nous terminerons ici notre leçon d histoire avec un peu de philosophie. C est vrai que HTML5 est parfois en désaccord avec d autres spécifications pour des raisons de compatibilité ascendante et qu il définit souvent ce que font les navigateurs plutôt que d attendre qu une RFC spécifie ce qu ils doivent faire. C est vrai que HTML5 ressemble parfois à un bricolage ou à un compromis car c en est un. Mais si c est le prix que nous devons payer pour disposer d un Web interopérable, nous disons : Vive le pragmatisme! Vous avez attaché votre ceinture? C est parti.

9 CHAPITRE 11 Temps réel Remy Sharp LE WEB EN TEMPS RÉEL fait partie de ces aspects d Internet qu on apprécie d utiliser mais qui peuvent être assez effrayants quand il faut les mettre en place. Ce chapitre présente les différentes technologies et la simplicité du code client. Pour ajouter du temps réel à une application web, deux options s offrent à vous : WebSockets et Server-Sent Events. WebSockets permet de créer un flux connecté vers votre serveur (une connexion TCP, donc) afin de mettre en place une communication bidirectionnelle et en temps réel entre le serveur et le client. Un exemple d application classique est un client de chat, mais ses possibilités sont infinies. Les sockets web ont un long chemin à parcourir pour remplacer le code qui repose sur Comet. Ce dernier utilise en effet un grand nombre de techniques qui sont assez souvent du bricolage pour mettre en place un flux de données en temps réel à partir d un serveur. Comme nous le verrons plus loin, WebSockets simplifie ce traitement du côté client.

10 248 INTRODUCTION À HTML5 Server-Sent Events, également appelé EventSource, pousse en temps réel des messages du serveur vers le navigateur client. Cette API convient donc parfaitement aux applications qui attendent des informations d un serveur sans nécessiter d interaction de la part de l utilisateur pour les mises à jour en direct d informations, par exemple. WebSockets et flux de données NOTE Si votre navigateur ne reconnaît pas nativement les sockets web, vous pouvez vous replier sur Flash. Hiroshi Ichikawa a en effet écrit une rustine en Flash pour les sockets web, disponible à l URL web-socket-js. WebSockets, l API des sockets web, ne fait pas partie de la spécification HTML5, mais elle est très importante pour certaines des applications web en temps réel qui sont apparues ces dernières années. Les sockets web fournissent une connexion bidirectionnelle entre le serveur et le client. Cette connexion est en temps réel et reste ouverte tant qu elle n est pas fermée explicitement. Lorsque le serveur veut envoyer un message au client, ce message est donc immédiatement poussé vers le navigateur. C est exactement le but que poursuivait Comet : Comet permet de créer une connexion en temps réel vers un serveur, mais en passant par plusieurs astuces différentes. Si aucune de ces astuces ne fonctionne, il se replie vers une interrogation Ajax qui accède constamment au serveur et ne s adapte donc pas très bien à la montée en charge. Si vous disposez d une socket ouverte, en revanche, le serveur peut pousser les données vers toutes les sockets connectées et n a pas besoin de répondre constamment aux requêtes Ajax. On passe donc du polling au pushing du réactif au proactif. Ce que Comet tentait d obtenir par des astuces, les sockets web l intègrent nativement dans le navigateur. Diminution de la latence des applications temps réel Un énorme avantage des sockets web est la diminution de la latence. Une socket étant toujours ouverte et en écoute, les données n ont plus qu à parvenir à votre navigateur dès qu elles ont été poussées par le serveur : la latence est donc extrêmement faible par rapport à celle d une requête Ajax reposant sur XMLHttpRequest. En théorie, avec Google Wave (ce projet a, depuis, été abandonné par Google), les personnes qui partageaient un document voyaient immédiatement toutes les touches tapées par les autres à mesure qu elles saisissaient du texte. Avec de l Ajax de base, en revanche, vous devriez créer un objet XHR chaque fois qu une touche est pressée et il faudrait donc envoyer tous les en-têtes d une requête XHR classique : agent utilisateur, types de contenus acceptés, etc. Cela fait beaucoup pour une seule frappe de touche

11 Chapitre 11 : TEMPS réel 249 Avec les sockets, la connexion étant toujours ouverte, il suffit d envoyer le caractère saisi, qui sera ensuite diffusé à tous les clients connectés au serveur. Seule cette information sera envoyée. Le volume des données transmises passe donc de octets (avec Ajax) à octets (avec une socket) : l ensemble sera donc plus réactif et les données seront transmises plus rapidement aux clients connectés. NOTE La mise en place d un serveur pour le protocole ws:// sort du cadre de ce livre, mais il existe déjà plusieurs bibliothèques permettant de l ajouter. En utilisant des serveurs comme Node.js, on peut obtenir un serveur de sockets web en moins de 20 minutes. Cette mise en œuvre est décrite dans l article slicehost-nodejs-websockets/. CONSEIL L URL utilisée pour la socket web ne doit pas nécessairement avoir la même origine que votre document. Cela signifie que vous pouvez vous connecter à des serveurs tiers, ce qui étend d autant plus les possibilités qui s offrent à vous. L API WebSocket L API WebSocket est très simple à utiliser. Comme nous l avons vu avec l API de messagerie et les Web Workers, les navigateurs actuels (à l exception de Firefox et des Web Workers) ne savent envoyer que des chaînes avec postmessage et onmessage. Il en va de même pour les sockets. Cela signifie que vous ne pouvez pas (actuellement) envoyer des données binaires. Mais, dans le monde du Web, nous avons l habitude de travailler avec JSON et il n est pas très difficile d encoder les messages en JSON à mesure qu ils arrivent d une socket, puisque c est ce que nous faisons déjà pour les requêtes JSON Ajax. L API se borne à créer la connexion, à envoyer et recevoir des données sur la socket, et à fermer celle-ci. Elle propose également un gestionnaire d erreur et un indicateur d état signalant que la connexion est en cours d établissement, qu elle est ouverte, en cours de fermeture ou fermée. Une socket fermée est définitivement inutilisable et ne peut plus être rouverte : vous devrez créer une nouvelle socket. La création d une socket web est très simple et ressemble beaucoup à celle d un Web Worker. Le protocole de l URL doit être ws://, mais le reste peut être structuré comme n importe quelle autre URL : var socket = new WebSocket( ws://monserveur.com/tweets:8080/ ); Dans cet exemple, j attends les messages provenant de l URL tweets. Chacun d eux est un nouveau tweet de Twitter, que mon serveur écoute puisqu il a été configuré pour cela (voir Figure 10.4). Les messages du serveur, récupérés à partir de l API Twitter, sont délivrés en JSON. Quand ils arrivent, il faut donc extraire les données et afficher le tweet à l écran : socket.onmessage = function(event) { var tweetnode = rendertweet(json.parse (event.data)); document.getelementbyid( tweets ).appendchild(tweetnode); }; En quatre lignes de JavaScript (si l on ne tient pas compte du code de la fonction rendertweet, qui se contente de transformer les données JSON en fragment HTML pour l ajouter à la page), je peux donc afficher en temps réel les tweets sur ma page.

12 250 INTRODUCTION À HTML5 FIGURE 11.1 Connexion montrant les tweets que mon serveur écoute. Manipulation d une socket Comme nous l avons mentionné, il existe également des méthodes permettant de faire autre chose que simplement écouter une socket. À titre d exemple, voici à quoi ressemblerait le code d un client chat programmé avec WebSocket : var socket = new WebSocket( ws://mon_serveur_chat.com:8080/ ), me = getusername(); socket.onmessage = function(event) { var data = JSON.parse(event.data); if (data.action == joined ) { initialisechat(); } else { shownewmessage(data.who, data.text); } };

13 Chapitre 11 : TEMPS réel 251 socket.onclose = function () { socket.send(json.stringify({ action: logoff, username: me })); showdisconnectmsg(); }; socket.onopen = function() { socket.send(json.stringify ({ action: join, username: me })); }; Cet extrait utilise les mêmes techniques que celles que nous avons employées avec l API de messagerie pour contourner la limite des messages en texte pur : l API des sockets est aussi simple que cela. Toute la négociation de la communication est prise en charge par le navigateur, sans que vous ayez à vous en soucier, et il en va de même pour la gestion du tampon (bien que vous puissiez vérifier la valeur de la propriété bufferedamount de la socket). En fait, le processus de communication est encore plus simple que la configuration d un objet XHR! Server-Sent Events Dans certaines situations, vous avez simplement besoin que le serveur envoie des messages à votre application. L API Server-Sent Events est particulièrement bien adaptée aux applications qui affichent en temps réel des changements de prix, ou les dernières dépêches, ou toute information devant parvenir unilatéralement au navigateur en temps réel si, en revanche, vous avez besoin d une communication en temps réel bidirectionnelle, c est WebSockets qu il vous faut. Server-Sent Events fournit EventSource, dont le fonctionnement ressemble beaucoup à celui d une socket web : on crée un nouvel EventSource en lui passant l URL à laquelle se connecter et le navigateur commence immédiatement à établir une connexion. Un objet EventSource reconnaît trois événements simples : open. Lorsque la connexion a été établie. message. Lorsqu un nouveau message arrive la propriété data de l événement contient alors le message brut. error. Si une erreur est survenue. Ce qui rend un EventSource unique est la façon dont il gère les connexions coupées et le suivi des messages.

14 252 INTRODUCTION À HTML5 Si la connexion d un objet EventSource est coupée pour une raison ou une autre, l API tentera automatiquement de se reconnecter. Si vous utilisez des identifiants de message, l objet indiquera au serveur lors de sa reconnexion l identifiant du dernier message qu il a reçu, ce qui permettra au serveur (si votre application le demande) d envoyer au client la liste des messages qu il a manqués. Supposons, par exemple, que votre application trace un graphique en temps réel représentant le nombre de fois où Bruce évoque sa peluche rose favorite sur Twitter. Cette application représentera donc les sentiments de Bruce au cours du temps vous saurez ainsi s il est content ou non de la couleur, de la texture et de l aspect général de l objet. Le navigateur se contentant de recevoir passivement des données du serveur, l API Server-Sent Events semble tout particulièrement adaptée. Supposons maintenant que votre connexion se coupe alors que vous surveillez attentivement les émerveillements de Bruce. Lorsque vous vous reconnecterez, EventSource indiquera au serveur que le dernier message avait l identifiant 69. Si le serveur en est au message 78, l application sur le serveur réalisera qu elle en a manqué un certain nombre et le serveur lui renverra alors tous les messages à partir du 70. Le code du client n a pas besoin d être modifié car chacun de ces messages manquants déclenchera simplement l événement message et tout sera représenté correctement sur le graphique. Voici un exemple de code de cette application : var es = new EventSource( /bruces-pink-toy ); es.onopen = function () { initialisechart(); }; es.onmessage = function (event) { var data = JSON.parse(event.data); chart.plot(data.time, data.sentiment); }; Server-Side Events technologie côté serveur Côté serveur, vous pourriez utiliser une configuration reposant sur PHP (LAMP, par exemple) mais, Apache (le A de LAMP) ne supportant pas très bien les connexions persistantes, la connexion sera sans cesse coupée. L objet EventSource passera donc son temps à se reconnecter automatiquement, ce qui produira un résultat semblable à une application Ajax de type polling. Ce n est donc pas la meilleure façon de procéder, mais il faut bien reconnaître que PHP est sûrement le ticket d entrée le moins cher pour la plupart d entre nous. Quoi qu il en soit, pour vraiment tirer parti d un EventSource, vous avez besoin d une connexion persistante au serveur ce qu une configuration LAMP classique ne peut pas vous fournir. Vous pouvez, et vous devriez sûrement, choisir un serveur reposant sur les événements. Entrer dans les détails sort du cadre de ce livre mais je vous conseille d étudier Node.js (une plateforme serveur reposant sur JavaScript) ou Twisted for Python.

15 Chapitre 11 : TEMPS réel 253 Le serveur doit garder ouverte la connexion avec le client et il doit lui envoyer un en-tête avec le type MIME text/event-stream. Il doit envoyer les nouveaux messages sous la forme suivante : id: 1\n data: { sentiment : aime, time : :43:23 }\n\n Les deux retours à la ligne servent à signaler la fin du message. L API permet également d envoyer plusieurs lignes, grâce à quoi nous pouvons envoyer des phrases en texte clair (et non en JSON comme ci-dessus) : data: C est ma première ligne vraiment, vraiment, vraiment très très\n data : longue, mais je n ai pas encore fini.\n\n data: Comme je suis placé après deux retours à la ligne, je suis un data: nouveau message.\n\n Dans cet exemple deux messages seulement seront envoyés. En outre, vous noterez qu aucun identifiant n est utilisé ils ne sont pas obligatoires mais vous en aurez besoin si vous voulez pouvoir reprendre à partir d où vous avez été coupé. Exemple de serveur EventSource simple Voici un code Node.js très simple qui accepte les connexions à un serveur EventSource et qui envoie des messages. Là encore, nous n expliquerons pas le fonctionnement du serveur car cela sortirait du cadre de ce livre, mais ce code devrait vous donner un bon point de départ. Nous avons également simplifié la solution afin que le serveur se contente de prévenir les utilisateurs connectés en leur envoyant le nom de l agent utilisateur des autres visiteurs connectés au même service. Nous garderons les graphiques sur le jouet spécial de Bruce pour un autre jour! /** Lorsqu ils créent un nouvel EventSource */ response.writehead(200, { Content-Type : text/event-stream, Cache-Control : no-cache }); // on récupère le dernier événement et on force sa conversion en nombre var lastid = req.headers[ last-event-id ]*1; if (lastid) { for (var i = lastid; i < eventid; i++) { response.write( data: + JSON.stringify(history[eventId]) + \ nid: + eventid + \n\n ); } } // Enfin, on met en cache la réponse connections.push(response); /** Réception d une requête web classique */

16 254 INTRODUCTION À HTML5 connections.foreach(function (response) { history[++eventid] = { agent: request.headers[ user-agent ], time: + new Date }; response.write( data: + JSON.stringify(history[eventId]) + nid: + eventid + \n\n ); }); Le code client ressemble à celui-ci : var es = new EventSource( /eventsource ); es.onmessage = function (event) { var data = JSON.parse(event.data); log.innerhtml += <li><strong> + data.agent + </strong><br> connecté le <em> + (new Date(data.time)) + </em></li> ; }; C est donc une application très simple mais, en coulisse, tout le travail s effectue à l aide d événements push produits en temps réel par le serveur. Implémentations disponibles EventSource est assez bien reconnu. Chrome, Safari, Firefox et Opera le gèrent très bien à l heure où ce livre est écrit, on ne sait pas très bien s il en sera de même pour IE10. Cependant, EventSource se repliant vers le polling, il est très facile de simuler cette API pour créer une rustine en JavaScript et en Ajax (vous trouverez quelques exemples à l URL Modernizr/wiki/HTML5-Cross-browser-Polyfills sous la rubrique EventSource ). J ai également remarqué que si l on créait un EventSource pendant ou immédiatement après le chargement d une page, certains navigateurs continuaient à afficher leur icône de chargement, ce qui pourrait laisser croire que le chargement de la page n est pas terminé alors que ce n est pas le cas. Je ne sais pas si c est un bogue dans l implémentation ou une fonctionnalité pour garder les développeurs en éveil, mais il suffit d attendre que le document ait fini son chargement et d envelopper le code d initialisation de l objet EventSource dans un appel à settimeout(init, 10) pour éviter ce problème. Résumé Ce chapitre vous a présenté un terme à la mode : temps réel. Cela dit, l ajout du temps réel à un site web permet de le rendre vraiment attractif maintenant que vous savez qu il est très simple à mettre en œuvre en JavaScript, je suis sûr que vous ne pourrez plus résister. Il reste bien sûr un peu de configuration à effectuer sur le serveur mais, une fois cela mis en place, vous pourrez capter l attention de tous ceux qui ont tendance à zapper de site en site. Passons maintenant à un sujet épous-tou-flant.