HTML5, aujourd’hui

<div itemscope itemtype="http://microformats.org/profile/hcard">
Vous pouvez contacter <span itemprop="given-name">JP Vincent</span> 
pour toute question HTML5 sur 
<a itemprop="email" href="mailto:jp@braincracking.org">ce mail</a>
../..
</div>

<ol>
  <li>KevinDu75: Kikoo ^__^
</ol>

<ol role="log">
  <li>KevinDu75: Kikoo ^__^
  <li>DarkBlackWarrior666 : LOL !!!!!
</ol>

<?php
class validation {
  // d'abord on met public l'expression rationnelle pour l'utiliser plus tard
  public static $regMail="^[w-]+(?:.[w-]+)*@(?:[w-]+.)+[a-zA-Z]{2,7}$";
  public static $regNickname="#^[a-zA-Z0-9àáâãäåèéêëìíîïòóôõöùúûüýýÿçñ _-.']{2,50}$#i";
  // fonctions appellées par le serveur
  static function isValidMail( $email ) {
    return preg_match("/".self::$regMail."/",$email));
  }
  static function isValidNickname( $nickname ) {
    return preg_match("/".self::$regNickname ."/",$nickname));
  }
}
</pre>

</figure>
On voit dans le listing 4 que l'on a isolé les expressions régulières utilisées pour valider le formulaire dans des variables statiques, et nous allons en fait les réutiliser dans le HTML. En HTML5 nous avons l'attribut pattern pour donner des expressions régulières au navigateur qu'il va exécuter pour vérifier l'entrée utilisateur, comme ci-après.


<form>
  <label >Votre mail : <input type="email" pattern="<?= validation:: $regMail ?>" required />
  </label>
  <label >Votre surnom : <input type="text" pattern="<?= validation:: $regNickname ?"> required />
  </label>
</form>
</pre>

</figure>

[caption id="attachment_928" align="aligncenter" width="234" caption="interface de validation de formulaire, sous Chrome"][/caption]

Sans avoir tapé de CSS ou de javascript, certains navigateurs afficheront l'équivalent de la figure 5 à l'utilisateur. Vous trouverez quelques librairies Javascript qui permettent d'émuler la même chose sur tous les navigateurs.
vidéo native
Les balises audio et video ont été calquées sur le modèle de la balise img : permettre très simplement d'insérer du multimédia dans une  page Web. La promesse est bien sur de se passer de Flash pour lire de la vidéo, et d'offrir à vos utilisateurs plus de fluidité (pas de démarrage de Flash ou d'un autre plugin), une meilleure utilisation du CPU sur les environnements que Flash n'adressait pas (Mac OS, Linux, les mobiles) et une interface par défaut qu'ils connaissent déjà. Pour le développeur, pouvoir utiliser JavaScript et CSS pour contrôler une vidéo est très naturel et promet donc de belles intégrations.

Tempérons cela par plusieurs points :

  
les implémentations actuelles   des navigateurs sont encore un cran en dessous de ce que permet   Flash. Notoirement mettre une interface en CSS en vrai plein écran  n'est encore possible sur aucun navigateur, il faut pour cela   attendre une autre spécification : la Fullscreen API, en cours de  test chez Firefox et Chrome
  
la guerre des codecs continue de  faire rage : le standard de l'industrie vidéo est h.264 et ils  n'ont aucune envie d'adapter tous les outils de leur chaîne de  production pour le Web. De l'autre côté WebM, pourtant offert à   la communauté par Google, ne peut être décodé que sur Firefox,  Chrome et Opéra et on attend depuis un an qu'Adobe fasse de même  pour que les sites Web n'aient pas à stocker en deux encodages  leurs vidéos.
  
le W3C n'a pas l'intention  d'adresser le marché particulier du streaming payant ou des  vidéos protégées, car c'est contraire à la philosophie  d'ouverture du Web. Cela signifie que pour ces marchés Flash  restera très longtemps la seule technologie utilisable.

En bref, les éléments multimédia sont déjà indispensables sur des environnements où Flash n'est pas présent, et vous pouvez déjà essayer de l'intégrer en complément de Flash sur vos sites Web, mais il est peu probable que ce soit votre seul lecteur.
Géolocalisation
La géolocalisation permet à une page Web de savoir (après autorisation de l'utilisateur) où celui-ci se trouve. Au contraire de la géolocalisation par IP qui peut au mieux vous donner le nom de la ville de votre point d'entrée sur le Net (en ADSL, cela peut être une erreur de 5 kms), les implémentations navigateur se basent sur des données matérielles plus précises :

  
sur bureau, l'adresse MAC de la   carte Wifi est envoyée sur les systèmes de Google (pour Firefox,  Opéra et Chrome) ou de Microsoft, qui ont scanné à grande échelle   les zones les plus densément peuplées, et qui y ont associé des   coordonnées GPS. En gros, si la « streetview » de   Google Maps ou de Bing est disponible pour votre quartier, vous   serez repéré précisément (de l'ordre de la centaine de mètres)
  
sur mobile, c'est le GPS embarqué   qui est directement interrogé. A défaut de GPS, c'est la  triangulation par antenne relai.

Dans tous les cas si aucune donnée n'est disponible, c'est au final l'adresse IP qui est utilisée, avec l'imprécision que l'on sait.

Voici un exemple d'implémentation qui essaye d'utiliser l'API du navigateur, mais qui à défaut va utiliser les solutions traditionnelles de détection par IP :


// test du support navigateur
if( navigator.geolocation ) {
  // appel asynchrone à l'API
  navigator.geolocation.getCurrentPosition( function( position ) {
  // l'objet position un sous-objet contient toutes les informations
    console.log( position.coords.latitude,  position.coords.longitude );
  });
} else {
  // retour à une solution moins précise
  var oXHR = new XMLHTTPRequest();
  // appel d'un script PHP qui va récupérer l'IP et trouver la ville
  oXHR.open('GET', '/getlocation.php');
  // on peut supposer que le script répond avec des coordonnées
  oXHR.onload = function( e ) {
    console.log( e.currentTarget.responseText );
  };
  oXHR.send();
}
</pre>

</figure>


Les solutions de correspondance IP / ville sont généralement payantes, même si il en existe des gratuites. Elle se présentent sous la forme de script et de base de données à installer chez soi et à exploiter en PHP. Dans l'un ou l'autre cas vous n'êtes bien sur absolument pas certain de la véracité des données. La géolocalisation des navigateurs permet à tout le moins d'avoir une solution IP gratuite, et dans la plupart des cas d'obtenir des informations beaucoup plus précises.

L'API prévoit aussi de demander des coordonnées plus précises, de pouvoir surveiller les déplacements et de fournir des données de vitesse, d'altitude, d'orientation par rapport au nord. Certaines implémentations peuvent également y rajouter la ville ou l'adresse !

Le fait que géolocalisation existe, et marche depuis déjà deux ans est majeur pour les technologies du Web, car c'est la première fois qu'une page Web peut interagir avec le matériel de l'utilisateur, privilège réservé jusqu'ici aux applications natives.
L'ère des applications Web
Websocket et Server Sent Events
WebSocket implémente ce que les développeurs Web devaient jusque là simuler : de la communication temps réel bi-directionnelle entre le client et le serveur. Le protocole HTTP montre en effet ses limites lorsqu'il s'agit d'attendre des informations venant du serveur ou d'écrire un jeu vidéo avec un flux d'informations continu client / serveur. Chaque envoi d'information est encapsulé par parfois plusieurs ko de headers tandis qu'avec websocket il ne s'agit plus que de quelques octect superflus. De plus la connection reste ouverte en permanence ce qui réduit très fortement la latence, chose indispensable pour des applications aussi réactives que des jeux. Il y a un article dans ce numéro qui trait plus en profondeur de WebSocket

Le problème de WebSocket pour le développeur PHP, c'est que cela remet en cause beaucoup de choses côté serveur : les serveurs WebSocket d'aujourd'hui sont écrits dans des langages tels que JavaScript (sur serveur Node.js) qui sont taillés pour exécuter du code de manière asynchrone et qui supportent en théorie des milliers de connexions ouvertes simultanément. Il existe bien une implémentation WebSocket en PHP, mais on ne sait pas vraiment quelle charge elle peut tenir en production, l'empreinte mémoire et la consommation CPU d'un processus PHP étant généralement assez gourmande : après tout pour tenir un socket ouvert, il n'y a pas d'autre moyen qu'une boucle infinie entrecoupée de sleep() et PHP n'a pas été pensé dans ce sens !

A côté de WebSocket, il y a la spécification « Server Sent Events », qui elle ne permet d'avoir que la communication du serveur au client, ce qui peut suffire à la plupart des applications : surveiller un flux twitter, un cours boursier, avoir un dashboard etc … Pour envoyer des informations au serveur, il reste bien sur XMLHTTPRequest, qui est un peu plus lent que WebSocket et qui crée un nouveau thread sur le serveur. En fait SSE remplace efficacement et formalise la technique dite « forever iframe » où PHP et JavaScript gardaient la connexion ouverte via une iframe où du HTML était régulièrement injecté, même lorsqu'aucun événement ne devait être envoyé.

L'avantage de Server Sent Events, c'est qu'elle permet de réutiliser pratiquement le même code côté PHP, avec quelques ajouts que nous allons commenter, tout en optimisant le trafic réseau et en formalisant les échanges de données. Regardons d'abord comment on faisait en PHP pour maintenir la connexion ouverte par une iframe :


<?php
// désactivation des caches navigateurs et proxys
header('Cache-Control: no-cache');
// boucle infinie
while(true) {
  // méthode métier de récupération des données
  $data = my_get_data();
  // encodage en JSON pour interprétation directe en JavaScript
  $data = json_encode( $data );
  // on fait exécuter une fonction JavaScript qui contient nos données
  print '<script> fonction_rappel('. $data .'); </script>';
  // même si les données sont vides, la connexion est maintenue car du HTML est envoyé
  flush();
  // on laisse respirer le CPU avant la prochaine itération
  sleep(1);
}
</pre>

</figure>


Voici maintenant les lignes que nous devrions ajouter pour renvoyer des informations à un navigateur supportant SSE :



<?php
// détection du support par le navigateur
$hasSSE = ($_SERVER['HTTP_ACCEPT'] === 'text/event-stream');
// désactivation des caches navigateurs et proxys
header('Cache-Control: no-cache');
// on informe le navigateur qu'on va lui répondre au format SSE
if( $hasSSE === true)
  header('Content-Type: text/event-stream');
// boucle infinie
while(true) {
  // méthode métier de récupération des données
  $data = my_get_data();
  // encodage en JSON pour interprétation directe en JavaScript
  $data = json_encode( $data );
  if( $hasSSE === true)
    // le standard prévoit que les données arrivent après la chaîne data:
    print 'data: '. $data;
  else
    // on fait exécuter une fonction JavaScript qui contient nos données
    print '<script> fonction_rappel('. $data .'); </script>';

  // le standard sépare les données sur plusieurs lignes par un double retour chariot
  print PHP_EOL.PHP_EOL;
  flush();
  sleep(1);
}
</pre>

</figure>

On le voit, on envoie simplement un entête supplémentaire, puis chaque ligne de donnée est préfixée par data: (avec ou sans espace), et les blocs de données sont séparées par un double retour chariot.

Côté client il suffit d'instancier l'objet EventSource avec l'URL du serveur et d'écouter les événements, comme ici :


// on se branche sur le PHP
var connexion = new EventSource('/get_data.php');
// programmation événementielle
connexion.onmessage = function( e ) {
  // la propriété data de l'événement contient directement la chaîne JSON qu'on a créé en PHP
  console.log( e.data );
};
</pre>

</figure>

L'API va beaucoup plus loin et en plus de la reconnexion automatique gère également :

  
les tickets, généralement un  marqueur de temps ou un numéro de ligne qui peut servir de repère   à PHP lorsque le navigateur se reconnecte,
  
des événements nommés, qui  permettent de créer des catégories de dialogue,
  
des événements comme les  erreurs, l'ouverture et la fermeture de la connexion

Il existe d'hors et déjà des librairies JavaScript permettant de simuler l'API Server Sent Events sur tous les navigateurs, et donc de réutiliser votre code PHP.
Offline
De plus en plus d'utilisateurs sont en situation de mobilité lorsqu'ils consultent des sites Web, qu'ils soient sur smartphone ou qu'ils utilisent un laptop dans un café avec une connexion Wifi défectueuse ou inexistante. Le grand avantage qu'ont les applications dites natives, c'est que l'interface se lance immédiatement, qu'il y ait du réseau ou pas. Hors certaines applications Web comme les jeux casual n'ont parfois pas du tout besoin de connexion, tandis que d'autres comme les webmails n'ont besoin d'une connexion que pour aller chercher de nouvelles données.

La gestion de l'offline vise à mettre les applications Web au même niveau que les applications natives en :

  
ne faisant télécharger qu'une fois pour   toute l'interface et le cœur applicatif,
  
donnant de  quoi gérer les versions de l'application,
  
permettant de réagir et détecter les situations de déconnexion.

Concrètement vous allez référencer un fichier .manifest dans votre HTML :
<!doctype html>
<html manifest="mapage.manifest">
…

Puis vous allez servir ce fichier (avec un entête type mime "text/manifest") qui référence plusieurs choses :

  
les dépendance (CSS, JS,  images..) à garder pour une utilisation offline (section   CACHE) ,
  
les URLs qui doivent absolument   accéder au réseau (section NETWORK),
  
les pages par défaut lorsque le   réseau ne répond pas (section FALLBACK)

L'exemple suivant serait une application Web qui n'aurait que deux dépendances, qui irait chercher le reste sur le réseau, et qui affiche la page offline.html pour toute autre requête sans réseau :


CACHE MANIFEST
# v1.0

CACHE
css/styles.css
js/main.js

FALLBACK:
/ offline.html

NETWORK:
*
</pre>

</figure>

La déclaration est simple, c'est dans la programmation métier de votre application que les choses se compliquent. Par défaut les navigateurs vont donc afficher la version qu'ils ont en local, puis aller vérifier si le manifeste de cache a changé ne serait ce que d'un octet (c'est pour cela qu'on met généralement en commentaire le numéro de version de l'application). Si c'est le cas, il va télécharger de manière transparente toutes les ressources, qu'elles aient changé ou non, et envoyer un événement Javascript pour dire qu'il a mis à jour le cœur applicatif. Il appartient au développeur de gérer ces états de transition entre deux versions de la même application. Il peut être aidé en cela par une série d'événement JavaScript et de fonctions situées dans l'objet global applicationCache, et qui lui donneront l'état de la mise à jour et un contrôle sur celle ci.

Notons par ailleurs que l'on a accès à la propriété window.navigator.onLine (valeur booléenne), censée donner l'état de la connexion, et aux événements ononline et onoffline, qui avertissent du changement d'état. Malheureusement seul Internet Explorer, et encore à partir de la version 8, implémente de manière utile cette propriété et ces événements.
XHR 2
XMLHTTPRequest a été la base technique à ce que l'on a appelé le « Web 2.0 » et permet de faire des requêtes asynchrones au serveur pour récupérer ou envoyer des informations. Dans HTML5, la version 2 déjà implémentée dans la plupart des navigateurs donne plus de contrôle et d'informations sur les requêtes :

  
indications de progression : si   la taille totale de votre envoi de fichier ou de votre  téléchargement est connue, vous avez accès à l’évènement progress, et aux  propriétés total et  loaded. Vous pouvez  maintenant afficher à votre utilisateur de vraies barres de   progression.
  
création de formulaires à la  volée : l'API FormData permet de créer ou de modifier des formulaires à la volée et  le navigateur les formate en mode POST.  Ceci permet de gérer facilement l'envoi de fichiers envoyés en  drag and drop depuis le bureau ou en sélection multiple, le  tout sans rechargement de page

En bref, là aussi cette API modernise les applications Web en faisant évoluer un des outils principaux des développeurs.
Local Storage
Que l'on gère un site Web classique avec des formulaires sur plusieurs pages ou une application Web lourde type google Docs, on a besoin de stocker les informations que l'utilisateur génère, sans forcément passer par le réseau pour stocker ces informations sur le serveur. On pouvait jusqu'ici utiliser les cookies, mais on était limité en taille (4ko tout compris) et on pouvait dégrader sérieusement les performances : sur la plupart des sites les cookies sont envoyés avec chaque requête HTTP et une page Web moyenne est composée de 80 requêtes HTTP, soit un trafic réseau énorme et surtout inutile. La solution préconisée par PHP est d'ailleurs de ne stocker dans le cookie qu'un court identifiant de session, pour retrouver côté serveur les données.

« Web Storage » permet soit de faire tampon, soit d'éviter carrément le trafic réseau ou la gestion de session en offrant aux développeurs un espace pour stocker au moins 5 Mo de données. Utilisez l'API sessionStorage pour un stockage temporaire (vidé à la fermeture de la page) ou localStorage pour un stockage permanent. Dans les deux cas vous pouvez stocker des paires clé/valeur très simplement :


localStorage.setItem('locale', 'fr_FR');
console.log( localStorage.getItem('locale') );
localStorage.removeItem( 'locale');
</pre>

</figure>

Seules les chaînes de caractère sont acceptées, donc si vous avez besoin de stocker des données plus structurées, utilisez simplement JSON. Si vous avez besoin d'utiliser cette fonctionnalité sur tous les navigateurs, sachez que vous pouvez utiliser Flash ou des techniques propriétaires de chez Microsoft pour y stocker jusqu'à 100ko de données. Il existe déjà plusieurs petites librairies qui font cette abstraction pour vous.
Le futur
Les navigateurs veulent clairement concurrencer les applications dites natives, voici ce sur quoi ils planchent.

La 3D : avec WebGL, qui permet donc de faire des jeux ou des environnements immersifs le tout en 3D. L'interaction avec le DOM permet même de réutiliser d'autres composants : on peut par exemple utiliser en texture un élément <video> ou le contenu d'une <div> sur des éléments de décor. Certaines sociétés éditrices de jeux vidéos console ou PC travaillent déjà sur cette techno pour trouver de nouveaux canaux de distribution et toucher plus de monde, en pariant sur une plus large diffusion des navigateurs et sur l'accélération matérielle généralisée d'ici 2 à 3 ans.

Le multithread : la spécification Web Workers permet d'exécuter du javascript dans un processus différent du navigateur, et même d'exploiter un second processeur. Cela permet d'avoir des applications avec des calculs lourds telles de la manipulation de photo ou de vidéo, des jeux vidéo ou des applications scientifiques.

L'accès au matériel : la géolocalisation permet déjà d'accéder au GPS des mobiles, getUserMedia permet d'accéder à la caméra, et DeviceOrientation pointe sur les informations du gyroscope. Il y a déjà des implémentations sur Firefox, Chrome et certains mobiles.

Le peer to peer : des expérimentations ont été menées et permettent de faire dialoguer directement deux navigateurs de deux machines différentes sans passer par un serveur pour maintenir la connexion. Oui le prochain Skype pourrait être écrit en JavaScript.

L'accès au bureau : plein écran, notifications, contacts … il y a plusieurs expérimentations autour de ces fonctionnalités qui vont permettre aux pages, pardon aux applications Web de s'intégrer complètement à votre OS, que vous soyez sur mobile ou sur PC classique.

Et je n'ai listé ici que les API qui ont au moins une implémentation, fusse-t-elle expérimentale. L'idée vous l'aurez compris est de donner les pleins pouvoirs aux « sites » Web qui sont aujourd'hui les interfaces privilégiées par le grand public. Cela ne se fait pas sans soulever des questions sur la sécurité, mais le W3C veille et chaque API est prévue pour passer par une demande de permission à l'utilisateur.

Conclusion
HTML5 et les navigateurs apportent toutes ces nouvelles capacités qui rivalisent avec les applications natives. Avec la puissance de diffusion du Web qui est de fait multi-plateforme, HTML5 termine le travail commencé par PHP et Linux car les logiciels de demain pourront être écrits avec des langages non propriétaires. C'est une grande victoire pour le monde du libre.

Références :
Sur Internet

  
http://braincracking.org/ – [FR] le site de l'auteur : veille technologique sur HTML5,   Javascript et les performances Web,
  
http://livre-html5.com/ – [FR] le site du livre HTML5, avec les démos,
  
http://html5-css3.fr/ – [FR] formation et tutoriaux à HTML5 et CSS3,
  
http://alsacreations.com/ – [FR] tutoriaux, forums et actualité des technos frontend,
  
http://html5doctor.com/ – [EN] site d'information sur la sémantique de HTML5,
  
http://www.html5rocks.com/ – [EN] maintenu par Google : tutoriaux et présentation  générale avec démos de HTML5 au sens large.