Le voilà enfin,  le nouveau langage web  révolutionnaire, la fin des problèmes de compatibilité entre les navigateurs, la solution à tous nos soucis de développeur web. Bon, ce que je viens d’écrire est peut-être un peu trop optimiste… Certes, HTML 5 a pour objectif de standardiser les technologies du web mais il ne faut pas rêver,  ce ne sera pas, ou plutôt,  cela ne semble pas être la solution miracle.

<Intro>

Si vous ne le savez pas encore, HTML 5, comme le présuppose son nom, est la nouvelle version de HTML après HTML 4.1. Cette évolution de l’HyperText Markup Language se veut être à la fois un regroupement de bonnes pratiques observées depuis plusieurs années sur la toile et dans les entreprises mais aussi un regroupement de nouvelles fonctionnalités qui faisaient défaut. Initiées au départ, par les trois géants du web que sont Apple, Google et Mozilla au sein du Web Hypertext Application Technology Working Group (WHATWG), ces spécifications ont été ensuite reprises par le W3C pour être normalisées.

HTML 5 a aussi pour ambition de simplifier son utilisation qui s’est complexifiée avec le temps. Prenons pour exemple, la déclaration de certaines balises qui a été réduite au strict minimum. La déclaration du doctype devient très simple. La déclaration des scripts JS inline devient implicite.

L’implémentation de nombreux types de validations client comme la validation d’une chaine de caractères (email, code postal, numéro de téléphone…) est facilitée par l’utilisation d’attributs natifs.

La réalisation d’effets graphiques simples tels que, les coins arrondis, les ombres (de texte ou de boite) ou les dégradés de couleur deviennent natifs en CSS 3 (avec malheureusement encore quelques variations entre les différents navigateurs…).

<ASP.NET MVC>

The right way for HTML 5 !

HTML 5 arrive avec son lot de bonnes nouvelles et nous devons, en tant que modestes développeurs ASP.NET, être prêts à l’accueillir. Pour celles et ceux qui n’auraient pas encore mis leur nez dans l’implémentation du pattern MVC en ASP.NET, c’est le moment.

A mon sens, pour faire du HTML 5, il faut oublier les contrôles ASP.NET standards, produisant du code HTML plus que perfectible. Il faut désormais se tourner vers ASP.NET MVC qui permet d’avoir la maitrise totale du code HTML final. Fini les gros Datagrid très pratiques générant un code HTML lourd. Le développeur revient aux fondamentaux du développement web et doit recoder son beau tableau à la main mais avec beaucoup plus d’API qu’avant, simplifiant ainsi son implémentation. Le résultat est un code HTML plus propre, plus léger pour transiter sur les réseaux et facilement maintenable pour les éventuels intégrateurs. Le passage à HTML 5 se fait alors naturellement.

Des frameworks déjà disponibles, fournissent des méthodes évitant aux développeurs de réinventer la roue. Ils permettent notamment de simplifier l’accès aux éléments des pages, la gestion des évènements, la communication avec le serveur…

<Limitations>

HTML 5 en ASP.NET est donc bien possible mais jusqu’où ? Il est aisé de dire « Mon application est en HTML 5 » en ajoutant simplement le doctype qui correspond, mais l’est-elle vraiment ?

Les principaux acteurs du web se sont incontestablement associés pour définir les standards de cette nouvelle mouture mais, malheureusement, ils ne s’accordent toujours pas sur l’ensemble des aspects de la spécification. L’exemple frappant reste celui de la prise en compte des formats vidéo. Chacun voudrait que son standard vidéo soit celui retenu dans la spécification et cela donne un grand n’importe quoi. Pour le moment, pas de réel changement par rapport à la version précédente d’HTML, le format vidéo supporté dépend du navigateur. Pour être cross navigateur, il faudra prévoir une version de la vidéo pour chaque format existant. Quel dommage pour une spécification qui se veut être une standardisation ?!

Certaines implémentations de HTML 5 ne sont pas encore disponibles pour toutes les plateformes. En effet, parmi les évolutions apportées par cette nouvelle version du langage, l’implémentation des flux duplex via les web sockets n’est pas entièrement prise en charge par la plateforme .NET. Si la partie cliente dépend uniquement du navigateur, la partie serveur a aussi un rôle à jouer.  Or, le serveur IIS ne supporte pas encore le protocole web sockets. Pour le moment, seuls quelques serveurs d’application les supportent, tels que Jetty et Node JS (le serveur en Javascript). Il n’est donc pas possible d’utiliser cette évolution avec une plateforme full .NET. Il faudra attendre la plateforme Windows 8 avec IIS 8 et ASP.NET 4.5.

<Applications>

Pour résumer, HTML 5 est déjà là. Plus ou moins terminé, plus ou moins standard entre les navigateurs et les plateformes. Mais attention, si certaines fonctionnalités sont déjà présentes, la spécification n’étant pas finalisée, celles-ci peuvent être modifiées !

Donc, pour savoir dans quels cas il faut se lancer dans l’aventure HTML 5 et dans quels cas il vaut mieux l’éviter, il faut se poser les bonnes questions. Il faut commencer par identifier le type de l’application concernée et les utilisateurs finaux de cette application.

Si l’application est un site grand public, on veillera à bien étudier les nouvelles fonctionnalités que l’on souhaite utiliser sur le site. Cette fonction est-elle implémentée sur tous les navigateurs ? Y a-t-il un risque que l’implémentation change avant la fin de l’élaboration des spécifications ? (Et bien sûr, cette fonctionnalité est-elle bien adaptée à tous les visiteurs ?)

Si l’application est une application intranet, le scope des utilisateurs finaux est plus réduit et le nombre de navigateurs utilisés est souvent limité. On peut donc choisir d’utiliser telles ou telles nouvelles fonctionnalités du langage en ciblant les navigateurs. En entreprise, il est aussi possible de les imposer ce qui réduit encore l’éventail des navigateurs clients.

<Conclusion>

Au final, HTML 5 apporte un réel plus dans l’implémentation des applications web mais il faut prendre garde car les spécifications ne sont pas encore terminées. La version finale est prévue pour cette année mais rien ne dit que cette version sera conforme à ce qui est déjà écrit.  En attendant, tous les grands acteurs du web s’y préparent et Microsoft sera évidemment au rendez-vous.

Une application web fonctionnant sans connexion réseau et capable de sauvegarder les données de l’utilisateur, quelle drôle d’idée ? Grâce à HTML 5 se sera pourtant bientôt possible !

Mercredi 8 février 2012, je me suis rendu aux MS TechDays 2012 dans le but d’assister à une présentation répondant au nom de « Création d’une application HTML5 gérant l’offline et le stockage client » afin d’en savoir un peu plus sur le sujet.

L’objectif de cette présentation était de découvrir quatre briques importantes d’HTML 5 : « le mode offline », « le DOM storage », « l’Indexed DB » et « le drag & drop ».

Les deux intervenants Microsoft que sont David Rousset, responsable de la relation avec les développeurs Web,  et David Catuhe, spécialiste interface utilisateur, ont commencé la session par une démonstration de SnapX, une application de gestion de diaporamas sur laquelle a été basée toute la présentation. SnapX est entièrement développée en HTML 5.

David Rousset a alors présenté le mode Offline permettant l’utilisation d’une application web sans connectivité réseau permanente. Le principe est le suivant : L’application est téléchargée par le navigateur comme une simple application web à la différence que celle-ci indique au navigateur la liste exhaustive des fichiers nécessaires à son fonctionnement en mode hors ligne. Tout ceci grâce à la définition d’un fichier « manifest » dans lequel on précise, les ressources hors ligne, les ressources en ligne et les ressources à utiliser en cas d’erreurs.

L’application SnapX, est utilisable en mode hors ligne grâce à cette technique mais elle permet aussi l’import de fichiers images ainsi que leurs manipulations et leurs sauvegardes, normal me direz-vous pour un diaporama… David Catuhe nous a alors décrit les méthodes utilisées pour permettre ces fonctionnalités en passant par la manipulation des fichiers grâce à la « File API » et la brique « DOM storage » qui permet de sauvegarder jusqu’à 10 Mo de données sur le poste client. Cette nouvelle brique qui permet d’outrepasser les limites des cookies, embarque deux objets que sont le localStorage (données partagées pour une application) et le sessionStorage (données de session uniquement).

Pour aller un peu plus loin dans la sauvegarde des données utilisateurs en local, la présentation s’est ensuite orientée sur la brique IndexedDB fournie par HTML5. Véritable base de données NoSQL, elle permet de stocker des objets Javascript (typiquement des objets JSON) et est totalement sécurisée (les bases de données d’une application sont liées au domaine). Il n’y a pour le moment pas de limitation sur la quantité de données et celle-ci varie selon les navigateurs. Nos intervenants lors de cette session nous ont laissé penser qu’une forme de limitation sera mise en place avec validation par l’utilisateur lorsque la spécification sera finalisée. Petit plus de la présentation, ils nous ont indiqué une ressource très intéressante permettant d’afficher le contenu de l’IndexedDB (aller sur http://blogs.msdn.com/b/ie/archive/2012/01/25/debugging-indexeddb-applications.aspx)… pratique pour débuguer !

Cette session s’est enfin terminée par une présentation de la brique « Drag & Drop », une fonctionnalité déjà possible avec les frameworks Javascript (jQuery…) existant mais devenue native avec HTML5. Rentrée dans les mœurs des utilisateurs, cette fonctionnalité offre la possibilité d’améliorer l’ergonomie des applications en simplifiant les interactions entre le bureau et le navigateur web.

Ces présentations sont aussi l’occasion de récupérer des bonnes pratiques ou des astuces que l’on ne trouve pas partout. J’en ai retenues deux :

- La spécification n’étant pas encore terminée, les implémentations des API instables sont systématiquement préfixées en fonction de l’organisme qui les a implémentées. Ainsi, l’implémentation de IndexedDB sur IE sera windows.MsIndexedDB, sur FireFox windows.MozIndexedDB, etc.

- Pour savoir si un navigateur implémente une fonctionnalité, il faut tester l’existence ce cette fonctionnalité et non la version du navigateur.

Pour aller plus loin :

http://www.caniuse.com (liste les fonctionnalités HTML5 disponibles en fonction des navigateurs)

http://www.catuhe.com

http://blogs.msdn.com/b/ie/ (IE team Blog)