Les autres nouveautés de l’HTML 5
Standardisation de Google Gears
Le HTML 5 a intégré en standard de nombreuses nouveautés introduites par Google Gears :
- Mettre en cache des pages et scripts pour un accès hors-ligne
- Stocker localement des données
- Faire tourner les scripts en arrière-plan
- Laisser les applications interagir naturellement avec votre environnement
Ces fonctionnalités étaient les prémices du rapprochement les applications natives et les WebApps. On aime ou on aime pas, mais la standardisation du W3C permettra d’accélérer ce phénomène proche du Cloud Computing.
Accès hors-ligne
En HTML 5 il est très aisé de forcer un navigateur à garder des données en cache et ainsi permettre au visiteur de revoir cette page même s’il n’a plus de connexion. Il suffit de créer un fichier manifeste page.manifest listant les fichiers et scripts à garder en cache :
CACHE:
page.htm
style.css
image.jpg
script.js
Ensuite il suffit de rajouter l’attribut au tag HTML :
Et voilà, page.htm, style.css, image.jpg et script.js seront accessibles même hors ligne!
Base de donnée locale
Le HTML 5 définit une nouvelle API JavaScript window.localStorage qui permet de stocker des données dans la mémoire du navigateur. Ses deux principales méthodes sont très simples:
window.localStorage.getItem(key);
Le localStorage est lié à un nom de domaine et les données stockées le restent même si l’utilisateur quitte son navigateur et revient plus tard. Si vos données n’ont pas besoin d’une telle persistance, vous pouvez aussi profiter de l’API sessionStorage qui, comme vous l’aurez compris, permet de stocker des informations tant que l’utilisateur n’a pas quitté le site.
La plupart des navigateurs permettent à chaque domaine de deuxième niveau de stocker 10Mo, mais le W3C recommande de demander l’autorisation de l’utilisateur si l’application a besoin de plus de place.
Attention, même s’ils se ressemblent, le Storage et les cookies n’ont pas la même utilité : n’oubliez pas que les cookies sont envoyés vers le serveur à chaque requête, ce qui pourrait rendre le trafic trop important si vous stockez de nombreuses données. À l’opposé, les données du Storage restent en local, accessibles via JavaScript.
Finalement, pour faire du vrai traitement de bases de données, il suffit de combiner le localStorage avec un JSON ou implémenter votre propre version de l’interface Database standardisée par le W3C.
Scripts en tâche de fond
Lorsqu’il exécute une opération très lourde, un JavaScript immobilise toute la page web. Parfois même l’interface du navigateur ne répond plus tant que le script n’a pas terminé. Heureusement en HTML 5, l’API Worker permet de profiter de faire tourner de tels scripts en tâche de fond.
worker.postMessage(0); /* Lance le Woker avec le paramètre 0 */
worker.onmessage = function (evt) { /* Action lorsque le Worker a fini */
alert(evt.data);
};
Et le worker.js :
// evt.data est le paramètre 0
for (var i=evt.data, il=1000001; i<il; i++) {
postMessage(i);
};
};
Ce code va nécessiter pas mal de travail au cours de ses 1 000 000 itérations mais ne devrait pas immobiliser le navigateur.
Remplacer une application desktop
Finalement, les WebApps peuvent s’enregistrer elles-même pour gérer les liens vers un certain protocole ou un certain type de fichiers. On peut ainsi imaginer un client IRC en ligne qui reconnait les liens irc:// ou un éditeur de documents qui ouvre un nouvel onglet plutôt qu’OpenOffice lorsqu’il y a un lien vers un .odt :
"https://www.example.com/?uri=%s",
"Client IRC en ligne");
navigator.registerContentHandler("application/vnd.oasis.opendocument.text",
"http://www.example.com/?uri=%s",
"Lecteur de documents en ligne");
Malheureusement, pour des raisons de sécurité, un site ne peut s’enregistrer que pour ses propres liens : si vous tombez sur un lien irc:// sur Geekfault.org vous ne serez pas redirigé vers example.com.
Beau tour d’horizon !
Vivement que ça soit finalisé …
Article très intéressant, j’ai appris des choses.
Ah bah nickel, un beau résumé, je ne connaissais pas la moitié des nouveautés décrites ici :p
Moi j’ai salement hâte de pouvoir éditer wikipedia en “deux clics” avec le contenu éditable…
Ça sera tellement plus facile 😀
ruby, rt, rp permet d’intégrer des annotations ruby (WTF?)
“Ruby” are short runs of text alongside the base text, typically used in East Asian documents to indicate pronunciation or to provide a short annotation. This specification defines markup for ruby, in the form of an XHTML module.
Tout à fait WTF, 3 balises pour à moitié rien (ou comment réinventer les tableaux au mieux)…
Très bon article sinon 🙂
P.S.:En postant le commentaire: Catchable fatal error: Object of class stdClass could not be converted to string in /home/geekfault/www/wp-content/plugins/multi-page-toolkit/TA_multi_toolkit.php on line 309
Très bon article, en effet, vu qu’on entend parler que de la vidéo concernant le html5.
Merci.
Bon, cet article est sympa parce qu’il présente pas mal de choses intéressantes mais il est quand même approximatif et le recul manque.
Par exemple, toute la partie local storage ne fait pas (plus) partie de HTML5 mais fait l’objet d’une spéc séparée.
Pour le manque de recul, il est visible avec des affirmations comme “La plupart de ces nouveaux éléments sont liés à l’accessibilité”, et il y a des choix vraiment critiquables (bonjour microdata) et il suffit de suivre un peu l’évolution d’HTML5 et son processus de standardisation pour voir que tout n’est pas rose.
Petit commentaire personnel pour finir : contenteditable est très sympa vu comme ça mais je ne suis pas vraiment convaincu. D’une part, c’est WYSIWYG (et je ne suis pas certain que ce mode d’édition soit toujours adapté) et d’autre part, les navigateurs font encore de la merde à ne pas laisser la main à un VRAI outil dédié. Bon, c’est comme ça pour le reste aussi, je ne suis pas d’accord avec le paradigme dominant, tant pis pour moi…
Bonne continuation, malgré ce que j’ai pu dire, vos articles ne sont pas forcément mauvais.
@Xavier Merci de ces précisions. Même si j’ai passé plusieurs heures à me documenter, ce n’est pas toujours évident sur un standard encore à l’état de brouillon.
Sinon pour le WYSIWYG du ContentEditable, si tu ne veux pas que ça le soit il faudra utiliser un textarea mais ça me semble normal que ça le soit puisqu’on peut rendre éditable n’importe quelle partie d’une page qui peut déjà avoir sa mise en page. Maintenant c’est sûr que si les navigateurs ne font que de la merde avec ça, on va devoir y mettre des surcouches JavaScript.
Merci pour ces explications ! Très intéressant… j’ai lâché HTML et CSS juste avant la vague HTML 5 donc je suis à la ramasse maintenant, cet article vient combler un peu mes déficits !
Concernant l’élément ruby, vu que tu as l’air de ne pas trop comprendre de quoi il s’agit :
http://en.wikipedia.org/wiki/Ruby_character
Rien à voir avec le langage de programmation, il s’agit en fait d’un élément qui permet d’afficher, au-dessus d’un caractère asiatique (chinois, japonais) sa prononciation.
Il me semble que cet élément figure déjà dans les versions précédents de HTML mais est mal interprété par les navigateurs malheureusement… j’espère que ça sera mieux avec HTML 5 !
Oui je savaiss de quoi il s’agit mais je ne saisis pas du tout l’utilité de trois tags HTML rien que pour ça. En même temps je ne parle aucun dialecte asiatique 😉
oui c’est utile sur tous les deux balises vidéo et audio