Adaptation de l’article publié dans le numéro 123 du magazine « Programmez !»  paru le 30 septembre 2009.

Principes de base de HTML 5

Jusqu’ici, les langages HTML et XHTML étaient deux langages distincts et définis par leur syntaxe.

La spécification HTML 5 définit un langage unique nommé HTML 5. Ce langage :

• est défini par sa structure DOM (Document Object Model, qui permet de représenter un document par une structure arborescente) et donc indépendamment de la syntaxe ;
• peut être écrit par une syntaxe HTML ou une syntaxe XML : il ne s’agit donc que de deux sérialisations possibles parmi d’autres.

Cette spécification définit de nouveaux éléments, attributs et API plus adaptés aux applications Web, ainsi que des consignes afin d’encourager des implémentations interopérables.

Notez que HTML 5 est conçu pour être compatible avec ses anciennes versions : les navigateurs qui implémenteront la spécification HTML 5 devront toujours être capables d’interpréter les documents HTML plus anciens.

Apports « basiques » de HTML 5

Sémantique

Des éléments ont été ajoutés afin de donner plus de structure aux documents : section, article, aside, header, footer et nav, notamment. Leur nom est explicite quant à leur utilisation.

Ainsi, on utilisera ces éléments natifs plutôt que de donner de la sémantique à des div (par exemple) en leur attribuant des identifiants ou classes CSS particuliers :

<div id="header">

devient :

<header>

L’article http://www.alistapart.com/articles/previewofhtml5 vous fait une excellente présentation de ces éléments.

HTML 5 fournit également un élément dialog pour représenter une discussion, ainsi qu’un élément figure permettant d’ajouter un titre à un élément donné (une image, par exemple).

Contrôles

Plusieurs nouveaux contrôles sont prévus.

Champs de saisie

L’élément input est doté de nouvelles valeurs pour sa propriété type. Essentiellement :

• datetime
• date
• month
• week
• time
• number
• range
• email
• url
• search
• color

Ainsi les navigateurs pourront proposer nativement l’interface utilisateur adéquate comme par exemple, un sélecteur de dates.

Les navigateurs prendront également en charge l’envoi au serveur non pas de la valeur saisie, mais d’une valeur formatée. On retrouve ici un principe largement mis en œuvre dans la plupart des frameworks : si on reprend notre exemple du sélecteur de dates, l’utilisateur pourra choisir des dates qui lui seront présentées au format local (JJ/MM/AAAA pour la France) mais les données envoyées au serveur pourront être toujours de la forme AAAA/MM/JJ, après avoir été validées.

Justement, l’attribut required permettra nativement de valider qu’un champ a bien été renseigné.

La page http://html5doctor.com/designing-a-blog-with-html5/ vous donne quelques exemples.

Combo-boxes

La combo-box fait son apparition dans le langage HTML ! L’élément datalist permet en effet de bénéficier d’une combo-box native, et donc de s’affranchir des frameworks qui nous le fournissaient, sous le nom « auto-complete » ou « suggest » :

Langue :

<input list="langues">

<datalist>

   <option>Francais</option>

   <option>English</option>

   <option>Deutsch</option>

</datalist>

Datagrids

La datagrid fait également son apparition dans le langage HTML. Elle permet de représenter et manipuler des arbres, des listes et des tableaux.

Une datagrid est initialisée à partir d’un élément HTML :

<datagrid>

   <table>

      <tr><td>1</td><td>Item 1</td></tr>

      <tr><td>2</td><td>Item 2</td></tr>

      <tr><td>3</td><td>Item 3</td></tr>

   </table>

</datagrid>

Dans cet exemple, la datagrid est peuplée à partir d’un tableau. Mais on aurait également pu utiliser un élément select afin de peupler la datagrid à partir d’une liste. Et même un ensemble d’éléments HTML, chacun représentant une ligne de la datagrid.

Il faut bien comprendre l’intérêt de la datagrid par rapport aux éléments HTML traditionnels : les éléments table et select ne sont pas manipulables par l’utilisateur, ils ne servent qu’à présenter des informations. La datagrid permet à l’utilisateur de les manipuler : sélectionner des lignes, des colonnes, des cellules, éditer des cellules, supprimer des lignes, des colonnes, trier les données, etc. Elle propose également une API qui permet de la manipuler programmatiquement. Là encore, le but est de fournir nativement ce que les frameworks nous apportent.

Menus

HTML définit un élément menu qui permet de définir des menus et des barres d’outils.

Voici un exemple de barre d’outils :

<menu>

   <li>

      <menu label="File">

         <button>New...</button>

         <button>Open...</button>

         <button>Save</button>

         <button>Save as...</button>

      </menu>

   </li>

   <li>

      <menu label="Edit">

         <button>Copy</button>

         <button>Cut</button>

         <button>Paste</button>

      </menu>

   </li>

</menu>

Pour créer un menu contextuel il suffirait de modifier l’attribut type du menu de toolbar à context. Les éléments peuvent alors référencer ce menu contextuel grâce à un nouvel attribut contextmenu.

Les éléments de ce menu peuvent être d’autres éléments menu (comme dans l’exemple ci-dessus), des séparateurs ou des commandes : une commande peut être représentée par un élément a, button, input, option, ou command.

Ce dernier élément command est apparu avec HTML 5. Il permet une sémantique plus fine :

<command label="Undo" />

Barres de progression

L’élément progress permet de présenter la progression d’une tâche :

Progress: <progress><span>0</span>%</progress></p>

<script>

   var progressBar = document.getElementById('p');

   function updateProgress(newValue) {

      progressBar.textContent = newValue;

   }

</script>

Notez que l’appel à cette fonction updateProgress() devra être fait manuellement.

Dans le même esprit, un élément meter est également prévu, pour afficher des mesures : pourcentages de votes, utilisation d’espace disque…

Multimédia

Vu la pauvreté du HTML 4 en la matière, le Flash Player est la référence de facto dans le domaine de la diffusion audio/vidéo embarquée dans les pages Web, avec sa compatibilité multi-navigateurs et ses API de manipulation.

HTML 5 fournit deux éléments video et audio dont l’objectif est de supporter nativement l’intégration et le contrôle des médias dans les pages Web :

<video src="video.mp4"></video>

<script>

   var video = document.getElementById("video");

</script>

<button>Play</button>

<button>Pause</button>

<button>Rewind</button>

Il sera donc possible de personnaliser l’interface utilisateur de manipulation des médias. Si ce n’est pas souhaité, l’attribut controls permettra d’indiquer au navigateur que c’est à lui de fournir cette interface.

Ce sera aux navigateurs de choisir les bons codecs. Il sera possible de spécifier différents formats via l’élément source :

<video>

   <source src="video.ogv">

   <source src="video.mp4">

</video>

L’élément audio est prévu pour fonctionner d’une manière similaire :

<audio>

  <source src="audio.oga">

  <source src="audio.mp3">

</audio>

Là encore, l’objectif est donc de fournir nativement ce que les solutions RIA nous ont proposé via des frameworks ou plugins.

Compléments

Les frames disparaissent ! Les éléments frame, frameset et noframes ne sont pas dans la spécification HTML 5 car leur utilisation a rendu difficiles l’expérience utilisateur et l’accessibilité.

Beaucoup d’attributs de présentation ont également été retirés afin d’inciter l’utilisation des équivalents CSS, bien plus adéquate : align, bgcolor, border, cellpadding, cellspacing, width, height…

Apports « avancés » de HTML 5

Drag and drop et copier/coller

Le « drag and drop », ou « glisser/déposer », est aujourd’hui un besoin courant dans les applications Web riches. Il est donc aujourd’hui largement proposé par la plupart des frameworks RIA. Il semblerait donc presque banal qu’il soit défini dans la spécification HTML 5.

Cependant, il faut savoir que dans les navigateurs actuels, qui implémentent HTML 4, les opérations « drag » sont limitées : vous ne pouvez lâcher des éléments qu’à l’intérieur de la fenêtre du navigateur. Si cela n’est pas gênant dans beaucoup de cas, il s’agit là d’une limitation importante, qui vous empêche de partager des données d’une application Web à une autre d’une manière conviviale.

HTLML 5 a pour objectif de casser cette limitation en proposant des interfaces DragEvent et DataTransfer :

interface DragEvent : MouseEvent {

   readonly attribute DataTransfer dataTransfer;

}

De manière assez traditionnelle pour ce genre de problématiques, les événements suivants sont gérés au fur et à mesure du drag and drop : dragstart, drag, dragenter, dragleave, dragover, drop, dragend. Lors de l’événement dragstart, l’objet DataTransfer est initialisé à une valeur qui pourra être récupérée lors de l’événement drop. Cette valeur pourra contenir des informations concernant l’objet déplacé. Cet objet doit être marqué comme étant déplaçable (attribut draggable).

Voici un exemple très simple permettant de déplacer un élément div d’un conteneur à un autre :

<div>

   <div

        draggable="true"

        ondragstart="return dragStart(event)"

        ondragend="return dragEnd(event)">

      Item ‘draggable’

   </div>

</div>

<div

     ondrop="return dragDrop(event)"

     ondragover="return dragOver(event)">

</div>

On notera l’utilisation de nouveaux attributs dont le rôle est assez explicite. Voici le code des fonctions JavaScript qui traitent les événements générés :

<script>

   function dragStart(event) {

      ev.dataTransfer.setData(
         "ElemId",
         event.target.getAttribute('id')
      );

      return true;

   }

   function dragOver(event) {

      // Ici on peut aussi retourner ‘true’
      // si on souhaite empêcher le dépôt
      // sur l’élément survolé

      return false;

   }

   function dragEnd(event) {

      ev.dataTransfer.clearData("ElemId");

      return true;

   }

   function dragDrop(event) {

      var elemId = ev.dataTransfer.getData("ElemId");

      event.target.appendChild(
         document.getElementById(elemId)
      );

      // On empêche la propagation de l’événement

      ev.stopPropagation();

      return false;

   }

</script>

Petite particularité : la notion de drag and drop n’est pas définie explicitement dans la spécification, elle reste ouverte. Cela ouvre la voie à de nombreuses possibilités, comme celle d’effectuer des « copier/coller ».

Le site http://html5demos.com/drag vous propose quelques démonstrations.

Géolocalisation

Cet aspect n’est pas directement inclus dans la spécification HTML 5 mais il y est souvent lié. Une API de Géolocalisation est également en cours de spécifications : http://www.w3.org/TR/geolocation-API/.

Son objectif est de permettre l’accès à la latitude et la longitude du périphérique sur lequel est exécuté le navigateur. Ces informations sont déterminées par analyse de diverses sources d’information : GPS, adresse IP, RFID, WiFi, Bluetooth, GSM…

Voici un exemple d’utilisation de cette API :

function traiterPosition(position) {

   // Utilisation des coordonnées
   // (ex : affichage d’une carte)

   // position.coords.latitude,
   // position.coords.longitude

}

navigator.geolocation.getCurrentPosition(
   traiterPosition
);

Cet exemple montre un appel unique à l’API : celle-ci propose un mécanisme de cache configurable en cas de besoin d’appels répétés.

Là encore vous pourrez effectuer des tests vous-mêmes sur le site http://html5demos.com/geo. Les plus inquiets pourront constater que le navigateur vous demande votre permission avant de récupérer vos coordonnées.

Graphisme 2D

HTML 5 définit un élément canvas qui permet de faire du dessin en JavaScript : formes, graphes, retouches photographiques, et même animations.

<canvas width="150" height="150"></canvas>

Les dessins se font en travaillant sur des rendering contexts. Nous resterons ici dans le cadre du contexte 2D, mais il existe également un contexte 3D (en cours de spécification, basé sur Open GL ES). Voici le code permettant de dessiner un rectangle bleu :

<script>

   var canvas = document.getElementById("monCanvas");

   if (canvas.getContext) {

      var ctx = canvas.getContext("2d");

      ctx.fillStyle = "rgb(0,0,255)";

      ctx.fillRect (10, 10, 50, 50);

   }

</script>

Cet exemple est très simple mais cette API propose de nombreuses possibilités : rectangles, lignes droites, arcs de cercle, courbes cubiques et quadratiques, intégration d’images, translations, homothéties, rotations, gestion de la transparence, dégradés, ombres, animations, interactions avec la souris…

Pour en savoir plus, vous pouvez par exemple consulter le site de Mozilla : https://developer.mozilla.org/en/Canvas_tutorial.

Gestion du Content-Type et de l’encodage des caractères

HTML 5 définit de nouveaux algorithmes de détection du Content-Type et de l’encodage des caractères. Du côté des développeurs, spécifier l’encodage utilisé devrait être bien plus simple. On retiendra les deux méthodes suivantes :

• Renseigner l’entête Content-Type des requêtes HTTP
• Renseigner un élément meta de la page avec l’attribut charset comme suit :

<meta charset="UTF-8">

Plus besoin, donc, de la traditionnelle syntaxe verbeuse suivante :

<meta http-equiv="Content-Type"
   content="text/html; charset=UTF-8">

Cette syntaxe sera cependant toujours supportée, toujours dans un souci de rétro-compatibilité.

Gestion de l’historique et du bouton « Back »

HTML 5 définit la notion de browsing contexts : il s’agit d’environnements dans lesquels les objets Document sont présentés aux utilisateurs. Ainsi, une fenêtre possède un browsing context, tout comme un onglet, une iframe ou une frame…

L’ensemble des documents d’un browsing context est nommé session history. Des objets History sont ainsi constitués, empilant les URL (ou des objets représentant un état) associées aux documents.

Cet historique est manipulable via une API dédiée :

interface History {

  readonly attribute long length;

  void go(optional in long delta);

  void back();

  void forward();

  void pushState(
     in any data,
     in DOMString title,
     optional in DOMString url
  );

  void clearState();

};

Ainsi l’appel suivant suffit à revenir à l’état précédent de l’historique :

window.history.back();

Cette API ressemble fortement à celle qui existait auparavant. Elle devrait cependant être plus poussée grâce à cette notion d’état, qui facilitera la gestion de l’historique dans les applications AJAX, de la même manière que l’ont proposé les frameworks.

Historique d’annulations

Il s’agit là d’une nouveauté qui n’est pas encore prête : la spécification nous indique que plusieurs points pourraient bien être à revoir, nous allons donc en rester à une présentation brève.

L’idée de cette API nommée UndoManager est d’associer un historique d’annulations à chaque document. Cet historique sera manipulable et composé d’une liste d’éléments, pouvant être de deux types :

• DOM changes : il s’agit d’objets représentant des modifications de la structure DOM opérés suite à une manipulation utilisateur (changement du contenu d’un nœud ou de la valeur d’un de ses attributs) ;
• Undo objects : il s’agit d’objets représentant des informations de plus haut niveau (état avant une action utilisateur ou l’envoi d’une requête au serveur, par exemple).

Mode offline

HTML 5 est accompagné de la spécification Offline Web Applications : http://www.w3.org/TR/offline-webapps/.

Cette spécification a pour objectif de permettre le développement d’applications Web utilisables en mode déconnecté, ou offline. Pour ce faire, elle apporte deux éléments :

• une base de données embarquée dans le navigateur et manipulable via une API reposant sur des requêtes SQL ;
• un cache applicatif permettant de stocker dans le navigateur les réponses des requêtes HTTP effectuées.

Base de données

La base de données locale supporte les transactions. Elle sera manipulable de la manière suivante :

var db = openDatabase(
   "notes", "", "The Example Notes App!", 1048576);

function renderNotes() {

   db.transaction(

      function(tx) {

         tx.executeSql(

            'CREATE TABLE IF NOT EXISTS Notes(
               title TEXT, body TEXT
            )',

            []

         );

         tx.executeSql(‘SELECT * FROM Notes’, [],
            function(tx, rs) {

               for(var i=0; i<rs.rows.length; i++) {

                  // Traitement de la note :
                  // rs.rows[i]

               }

            }
         );

      }

   );

}

function insertNote(title, text) {

   db.transaction(

      function(tx) {

         tx.executeSql(

            'INSERT INTO Notes VALUES(?, ?)', 

            [ title, text ],

            function(tx, rs) {

               // …

            },

            function(tx, error) {

               // Traitement

            }

         );

      }

   );

}

Cette API s’inspire donc très fortement du plugin Google Gears. Sauf qu’au lieu d’un plugin, cette base de données sera fournie nativement par les navigateurs.

Cache applicatif

Ce cache reposera sur l’attribut manifest de l’élément html, qui pointe vers l’URI d’un fichier nommé « manifest ».

Ce fichier indique simplement la liste des fichiers à mettre en cache (section CACHE MANIFEST), ainsi que ceux qui ne doivent pas être mis en cache (section NETWORK) :

CACHE MANIFEST

index.html

help.html

style/default.css

images/logo.png

images/backgound.png

NETWORK:

server.cgi

La spécification prévoit d’autres moyens de définir le cache, via un préfixe par exemple. Elle prévoit également une API permettant aux scripts d’ajouter et retirer dynamiquement des fichiers du cache.

Aspects communs

Pour déterminer si le client est connecté ou non, il suffira d’invoquer :

var isOnline = navigator.onLine;

Web workers

Cet aspect non plus n’est pas directement inclus dans la spécification HTML 5 mais souvent lié. Une API est également en cours de spécifications : http://www.whatwg.org/specs/web-workers/current-work/.

Cette spécification définit une API pour exécuter des scripts en tâche de fond, donc indépendamment des scripts de l’interface utilisateur.

Elle permet ainsi l’exécution de scripts « longs » :

• sans interruption par des scripts de traitement d’actions utilisateur (clics par exemple) ;
• sans besoin de mécanisme permettant de conserver une page réactive.

Mais cette API est très claire : les Workers sont lourds et sont à utiliser avec parcimonie, et uniquement si réel besoin.

Voici un exemple très simple issu de la spécification : la tâche de fond est ici un algorithme naïf de recherche de nombres premiers :

The highest prime number discovered so far is:

<output></output>

<script>

   var worker = new Worker('worker.js');

   worker.onmessage = function (event) {

      var result = document.getElementById('result');
      result.textContent = event.data;

   };

</script>

Voici le contenu du fichier worker.js :

var n = 1;

search: while (true) {

  n += 1;

  for (var i = 2; i <= Math.sqrt(n); i += 1)

    if (n % i == 0)

     continue search;

  // found a prime!

  postMessage(n);

}

La spécification regorge d’exemples variés, à complexité et intérêt croissants.

Web sockets

HTML 5 introduit l’API Web Sockets, qui permettra de communiquer avec le serveur de manière bi-directionnelle à la manière de Comet et AJAX, mais avec les deux avantages suivants :

• cette API sera native ;
• elle ne nécessitera qu’une seule connexion avec le serveur, au lieu de deux dans le cas de Comet et AJAX.

En effet, Comet et AJAX reposent sur le protocole HTTP donc nécessitent une connexion pour envoyer des données et une autre pour en récupérer du serveur.

Cette API n’est pas encore détaillée dans la spécification HTML 5.

Cross-document messaging

Un des grands soucis avec AJAX était jusqu’ici l’impossibilité d’interactions entre des scripts de documents situés sur des domaines différents, pour des raisons de sécurité. Même si cette sécurité est justifiée, cela empêche des pages de communiquer même si elles ne sont pas dangereuses.

La spécification HTML 5 définit un système de communication entre documents à base de messages. Ce, quelque soit leur domaine, tout en conservant un niveau de sécurité optimal.

Voici un cas concret provenant de la spécification :

• un document A contient une iframe contenant un document B ;
• un script du document A invoque une certaine fonction window.postMessage() sur le document B ;
• Un événement message est alors déclenché sur le document B : ce message est marqué comme provenant de l’objet Window du document A.

Voici le code qui correspond à cet exemple (script du document A) :

var docB = document.getElementsByTagName('iframe')[0];

docB.contentWindow.postMessage(
   'Hello world',
   'http://url/'
);

Et voici le script nécessaire dans le document B afin de surveiller l’arrivée de tels messages :

window.addEventListener('message', receiver, false);

function receiver(e) {

   if (e.origin == 'http://url/') {

      if (e.data == 'Hello world') {

         e.source.postMessage('Hello', e.origin);

      }

      else {

         alert(e.data);

      }

   }

}

Comme en AJAX, il est essentiel de vérifier que le domaine d’origine est celui attendu.

Petit bilan

Nous venons de dresser une synthèse des apports essentiels de la spécification HTML 5. Ces apports sont nombreux et ont pour objectifs de :

• rendre HTML plus adapté aux problématiques actuelles des applications Web ;
• casser la dépendance du Web vis-à-vis des frameworks propriétaires, comme Flash, Flex, ou Silverlight.

Où en est HTML 5 aujourd’hui ?

Les éléments que nous avons abordés dans cet article ne sont pas figés puisque la spécification est une version de travail. Certains exemples ne sont même peut-être plus d’actualité !

Les navigateurs ont déjà commencé à implémenter HTML 5, mais deux problèmes se posent :

• les implémentations dans les différents navigateurs sont hétérogènes et n’avancent pas à la même vitesse ;
• il est en outre très difficile de savoir où en sont les navigateurs dans cette implémentation : les sites Web des éditeurs des navigateurs ne sont guère bavards sur le sujet, et si le Web regorge de pages de qui traitent le sujet, les informations qu’on trouve sont parfois contradictoires.

En résumé, pour celui qui souhaite savoir si la version X du navigateur Y implémente déjà la caractéristique Z de HTML 5, il vaut mieux jeter un œil sur le Web et surtout effectuer des tests !

Côté outils de développement et de débogage, rien de particulier pour le moment : gardez sous le coude vos outils HTML habituels !

Cette spécification précise qu’elle ne sera finalisée que lorsqu’au moins deux implémentations complètes en auront été réalisées, afin de s’assurer de son adéquation avec les besoins des développeurs d’applications Web et les contraintes des éditeurs de navigateurs. Ian Hickson, co-rédacteur de la spécification, nous précise dans une interview (http://blogs.techrepublic.com.com/programming-and-development/?p=718) que cela arrivera en … 2022 ! Le planning est donc long, à cause de l’historique et des objectifs à atteindre.

En effet, le travail est considérable : la spécification en est consciente et tente de ne pas reproduire les erreurs du passé. Ainsi, elle sépare clairement les requirements à destination des développeurs de ceux à destination des éditeurs de navigateurs. De même, au lieu de donner des définitions abstraites comme dans les versions précédentes, elle donne des définitions impératives afin de favoriser l’interopérabilité entre les implémentations. La « bataille » entre navigateurs ayant repris de plus belle, il s’agit là d’une problématique très importante. Ce planning ne serait-il pas trop long, tout de même ?

HTML 5, « killer » de Flex et Silverlight ?

Ce titre vous surprendra peut-être, mais on peut lire plusieurs articles sur Internet qui présentent HTML 5 comme le langage qui va conquérir le monde des RIA. Pourquoi ? Parce que les apports de HTML 5 comblent plusieurs manques de HTML vis-à-vis de ces technologies : vidéo, audio, mode offline, drag and drop…

Sauf que ces technologies sont déjà disponibles, plus évoluées et largement mises en œuvre pour certaines. Le Flash Player, après plus de 10 ans, est présent sur 99% des navigateurs. HTML 5 est « plus RIA » que HTML 4, oui. Rattrape-t-il son retard sur Flex ou Silverlight ? Non. D’autant plus que lorsque HTML 5 sera finalisé en 2022, le monde des RIA aura largement eu le temps d’évoluer ! Le planning semble donc trop long. Mais il est primordial que le W3C définisse des normes adéquates aux problématiques actuelles afin de limiter le recours à des technologies non natives et propriétaires.

Cette comparaison entre HTML 5 et les autres technologies RIA a été mise en avant lors de l’annonce officielle de Google Wave : l’application Web de Google Wave, impressionnante, repose sur certains apports de HTML 5 et Google a largement communiqué sur ce sujet.

Quelques liens pour approfondir

Sites officiels de la spécification :

http://www.w3.org/TR/html5/

http://www.w3.org/TR/html5-diff/

Deux pages qui synthétisent l’état d’avancement de l’implémentation par les navigateurs :

http://a.deveria.com/caniuse/

http://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28HTML_5%29#Web_Applications_1.0