Le constat

Cela fait une bonne année que les browser majeurs implémentent systématiquement de belles features HTML5, alors même que la spec n’est pas finalisée. D’un côté c’est tant mieux car

ces implémentations font progresser les spécifications elle même. Le HTML working group ou le W3C peuvent voir en action sous Opéra ou FF ce qu'ils essayent de spécifier, et ils ont de vrais retours des implémenteurs, voire des développeurs web
nous les développeurs web pouvont tester et se préparer à ce que sera le futur des applications web. Ceux qui prévoient la rétro-compatibilité peuvent même mettre des choses en production

Cependant, pour nous développeurs web :

l'état non finalisé de la spec fait que les browsers implémentent la même fonctionalité avec des interfaces différentes, voire rajoutent des features certes intéressantes mais dont on ne sait pas si elles seront implémentées partout
l'état du marché des browsers fait qu'on gère et gèrera encore pour longtemps des browsers qui n'implémentent pas du tout ces features :
- IE6 et IE7 sont encore là et resteront quelques annéees, le temps que Seven soit massivement adopté
- IE8 a fait un remarquable effort (DOM Storage, offline detector, JSON natif, CSS selector natif, onHashChange ...) mais on commence à se douter qu'aucune mise à jour n'implémentera de nouvelle feature majeure (geolocalisation, Web Worker, <video>, Canvas ...)
- les roadmaps de FF, Chrome, Safari et Opéra ne sont évidemment pas synchrones, donc la diffusion des features n'est jamais garantie même sur ces browsers modernes
- les habitudes de navigation changent et il faut prendre en compte la navigation sur les browsers riches mobiles. Un même user peut utiliser IE6 au bureau, continuer sur son Webkit/Opera mobile dans les transports et terminer sur son Firefox à la maison.

Avant même de commencer à utiliser ces features, il faut d’abord passer du temps à comprendre et implémenter plusieurs API différentes, en plus d’une version de l’applicatif qui “doit faire sans”.

Exemple concret : Storage

Mettons que je veuille développer une application de type Maps, qui affiche par exemple des photos sur une carte. Sans compter les images qui sont gérées par le cache du browser, au bout de quelques minutes de navigation, on va se retrouver avec des Mo’s de données importées progressivement via XHR ne serait ce que pour lister le nom, l’endroit et l’url des images à placer sur la carte. Si l’utilisateur rafraichit la page, il perd tout.

La solution ici serait d’implémenter HTML5 WEB Storage pour que l’utilsateur garde les données des photos sur son disque et lui garantir un affichage éclair des photos dans les zones déjà visitées

La spec est encore à l’état de DRAFT mais on trouve 4 browsers (50% des visiteurs) qui en ont implémenté une variation :

IE8 a DOM Storage (d'ailleurs je ne sais même plus quel est le nom officiel de la feature ...)
FF2 puis FF3 ont DOM Storage, ainsi que LocalStorage depuis FF3.5
Safari 4 appelle ça Key-Value Storage, et je ne sais pas si ça marche sous l'iPhone qui limite de toute façon fortement l'espace cache donné aux pages (EDIT: pobo me signale qu'avec certaines restrictions, l'iPhone aussi le supporte)
Chrome inclue GEARS qui permet l'accès à une Database. Mais ils ont annoncé récemment qu'ils abandonneraient GEARS au profit de HTML5

La fonctionalité globale est la même mais le moyen d’y accéder, le retour des fonctions et les limitations diffèrent. On est dans un cas bien plus complexe que le support de telle ou telle propriété CSS2, et autant dire qu’en tant que développeur on n’a même pas envie de commencer une implémentation, d’autant qu’il faut inclure dans le coup du développement le cas majoritaire : l’absence totale de Storage.

C’est assez représentatif de toutes les features HTML5 de manière générale, la seule solution viable est donc l’utilisation d’une libraire Javascript qui permet d’avoir une API uniforme.

L'unique solution : les librairies JS

Dans l’écosystème du développement web, c’est le rôle des librairies JS que d’aplanir les différences entre browsers, et dans l’exemple de WEB Storage, seul YUI a produit de quoi pouvoir utiliser cette feature sereinement :

une manière uniforme d'accéder à 5 implémentations différentes (en incluant flash)
YUI fait partie des grandes librairies dont le support à long terme est quasi assuré
un résumé des limitations auxquelles s'attendre, qui permet de savoir avant même d'implémenter si la solution sera vraiment utile
une documentation et des exemples qui sont autrement plus lisibles qu'une spec W3c
bonus : via Flash on a même une solution de fallback quasi universelle, ce qui ne serait pas possible avec toutes les features HTML5 (geoloc par exemple)

Il semble y avoir des plugins pour Jquery ou Dojo (impossible de retrouver une doc pour Dojo) mais ils m’ont semblé non supporté ou à moitié abandonné.

Si seul YUI a pu sortir quelque chose (signalons que Yahoo peut se payer une équipe à plein temps), c’est parce qu’on est arrivé je pense dans une autre ère du développement JS : on ne se contente plus en quelques lignes d’implémenter un .getElementByClassName() ou un accès aux events DOM uniforme, on a maintenant affaire a des features beaucoup plus compliquées, nouvelles, qui touchent aux ressources machine, avec lesquelles on communique surtout par event/callback et pour lesquelles les specs ne sont pas bien établies. Alors que le terrain de bataille actuel des librairies se fait surtout sur les widgets, les librairies n’ont plus le temps de revenir à leur raison d’être originale qui était d’uniformiser l’accès cross-browser.

Wish list

Il y a de la place pour tout le monde, voici des features HTML5 dont le développeur d’application Web d’aujourd’hui a besoin (dans le désordre) :

Web Storage : fait par YUI, avec fallback flash, au poil
OnHashChange event : pour la navigation en mode AJAX. Le fallback pourrait être une boucle qui monitore l'url ...
<video> : pour la vitesse d'affichage d'une vidéo. Ca serait pas mal si on pouvait insérer un tag <video> à remplacer par un player flash s'il n'est pas supporté. Mais à ce jeu là je vois (malheureusement pour le monde du libre) h.264 sortir gagnant face à OGG
le multi upload, avec barre de progression et preview : comme dans le récent FF3.6 le support du multiple="true" dans les <input type="file">, de l'event onProgress pour indiquer où en est l'upload et l'affichage de la miniature de la photo qui est sur le disque. Et en fallback une des 2 millions d'implémentation flash déjà existante.
le drag & drop depuis le bureau : implémenté aussi dans FF3.6, la seule alternative est activeX ou java ... Il vaut peut être mieux se passer d'alternative pour cette fois.
Canvas : IE a VML, les features sont comparables au point qu'il existe déjà une librairie qui fait le pont entre les 2
mode offline : le fallback ne doit pas être très pratique (pinger le serveur de manière régulière jusqu'à tomber en timeout ...) mais c'est peut être jouable. Gérer le cache et retenir les infos à envoyer au serveur jusqu'à ce que l'on revienne online ne peut se faire qu'avec Storage (donc flash en fallback)
Web Workers : pour faire de grosses opérations JS sans freezer le browser. Peut être simulable avec une iframe ?
Geolocation : demander au browser où il se trouve physiquement. Pas de fallback possible si ce n'est la détection de l'IP. De toute façon les applications qui utilisent ces infos prévoient toujours en premier lieu un moyen d'indiquer manuellement sa position
Input type calendar, mail etc... : pour par exemple afficher un calendrier lorsqu'on clique sur un input de type date (seul opéra le fait aujourd'hui). Toutes les libraires proposent des widgets calendar que l'on pourrait mettre en fallback

Les librairies ont le pouvoir

Tout cela nécessite une grosse force de développement et il est même possible que devant la rareté ce soient d’abord des librairies payantes qui fassent leur trou … Mais les développeurs de framework peuvent trouver des alliés

dans les équipes des navigateurs qui pourraient partager leur expérience au nom d'un meilleur web
pourquoi pas chez Adobe vu le nombre de fois où flash est utilisé comme fallback ...
et même avoir des représentants au W3C et au HTML working group, étant donné que le 1er contact des développeurs avec les nouvelles features passera d'abord par les librairies ...

Qui se lance ? :)