TechDays 2012 – IE10, HTML5 et CSS3 au programme

Sujet lourdement attendu aux TechDays 2012, la vision d’HTML5 et de CSS3 par Microsoft a fait salle comble. Nul doute que le nouveau navigateur Internet Explorer 10 va faire des vagues !

« Le bon, la brute, et beaucoup de truands ! »
Comme souvent à l’arrivée d’une nouveauté, beaucoup de
bruits parasites viennent confondre le commun des mortels. IE10 n’échappe pas à cette règle et depuis quelque temps maintenant, le navigateur de Microsoft rejoint HTML5 et CSS3 au cœur des sujets de discussion des professionnels de l’informatique.
A travers cet article, je vais tenter de vous éclairer sur ce qui se cache derrière l’arrivée d’Internet Explorer 10 et sur sa manière d’implémenter les nouvelles spécifications de CSS3 et d’HTML5.
 

Design et ergonomie, les règles de base
Comme j’ai déjà pu le décrire dans ma chronique consacrée au premier jour des TechDays 2012, Microsoft fait son mea culpa quant à son manque de considération du graphisme et de l’ergonomie dans sa stratégie des années passées. Aujourd’hui, Microsoft veut se rattraper en misant énormément sur l’amélioration de l’expérience utilisateur, à commencer par le visuel.

Pour rappel, voici les quelques règles de base que Microsoft va tenter de suivre:

  • Alignement des éléments graphiques sur une grille pour avoir un visuel efficace
  • Disparition du chrome et de toute la tuyauterie du navigateur pour que l’utilisateur se concentre sur le contenu
  • Palettes de couleurs harmonieuses pour éviter les fautes de goût
  • Taille de polices standardisées pour éviter de dérouter l’utilisateur
  • Respect du principe “Fast & Fluid“ indispensable pour les applications mobiles

Avec son implémentation de la norme CSS3, Microsoft met à disposition tout ce qu’il faut pour respecter ces bonnes pratiques. Mais attention, on ne s’improvise pas graphiste ou ergonome du jour au lendemain ! Une fois encore, ce n’est pas tout d’avoir des bons outils si l’on n’a pas un minimum de talent. Microsoft ne se cache d’ailleurs pas d’avoir fait développer son prototype Snapyx de démonstration (bientôt en ligne on l’espère !) par une entreprise extérieure spécialisée en graphisme. Maintenant que les bonnes résolutions sont énoncées, voyons comment Microsoft va s'y prendre...

Internet Explorer 10
Pour commencer, Microsoft nous propose un nouveau navigateur IE10 afin d'exploiter au mieux toutes les dernières technologies en passe de devenir les standards des applications web de demain. De plus, Microsoft précise qu’il n’oublie pas ses versions précédentes et que les fonctionnalités d’HTML5 seront pour la plupart implémentées pour IE9. Pour le reste, l’utilisateur sera juste privé d’un « nice to have » mais ne sera en rien gêné dans sa navigation.
Ces navigateurs vont fonctionner sous Windows 7 et +, sachant que sous Windows 8 avec le moteur METRO intégré, deux modes seront disponibles :

  • Le mode Desktop pour lequel les plugins seront supportés
  • Le mode METRO sans plugins

Enfin pour les derniers râleurs en manque de sensationnel, notez la grande arrivée d’un correcteur orthographique dans IE10 ! Fini donc les messages envoyés par webmail bourrés de fautes !
Je vous propose maintenant de découvrir les carburants qui permettront d'exploiter au mieux ce navigateur, je veux parler bien sûr de CSS3 et d'HTML5.
 

Principales fonctionnalités prises en charge sous CSS3
Comme dans les versions précédentes de la norme, le Cascading Style Sheet va s’intéresser à la présentation des éléments par opposition au script que l’on range désormais derrière HTML5 qui se concentrera sur la gestion des interactions utilisateur. Le DHTML est définitivement enterré !

Au programme de CSS3, transformations 2D et 3D, transitions et animations ! Même si le format SVG (Scalable Vector Graphics) a été mentionné à quelques reprises, aucune emphase particulière n’a été faite à son sujet. En revanche, le fait que le nouveau navigateur web utilise au maximum le processeur graphique (le fameux GPU) a été au cœur du débat. Le CPU quant à lui va enfin pouvoir reprendre son souffle !
Pour les différents web controls, nous allons maintenant pouvoir jouer avec les propriétés à animer, le délai avant déplacement, la durée de déplacement et quelques fonctions « d’easing ».

Vous ne me croyez pas ? Ces nouveaux attributs CSS devraient vous convaincre :

transition-property  Propriétés CSS à transformer 
transition-delay                Retard (ou avance) du départ de la transition
transition-duration             Durée de la transition
transition-timing-function      Fonction de transition à utiliser, modèle d'interpolation (accélération, décélération...)

Et maintenant, les animations me direz-vous ? Et bien les animations ne sont rien d’autre que des transitions pour lesquelles on a inséré des points de parcours (des Key Frames et non des Check Points dans le jargon Microsoft) afin de mieux maîtriser les transitions. 

Pour compléter le tableau, Microsoft implémente à travers son nouveau navigateur le rendu de la propriété Textshadow avec quelques styles préprogrammés comme un effet "burning" de lettres enflammées.
Ah, j’allais oublier… Microsoft propose ses propres attributs css qui ne sont pas encore totalement adoptés par le W3C avec entres autres les -ms-grid et -ms-flexbox afin de faciliter l’implémentation de son nouveau concept METRO. Il va donc falloir se méfier des attributs préfixés…
 

Attention, peinture fraîche !
À
ce propos, les différents acteurs (fournisseurs de navigateurs web) proposent chacun leur implémentation des standards W3C.
On se retrouve alors avec pléthores d’attributs spécifiques :
Microsoft préfixe les siens par –ms-, WebKit (Chrome et Safari) par –webkit-, -o- pour Opéra, -moz- chez Gecko (Mozilla).
Une des bonnes pratiques que l'on retrouve fréquemment est de séparer l’implémentation des attributs spécifiques des attributs standards dans des fichiers css distincts.
Il faudra bien évidemment maintenir ces différents fichiers, surtout si l’on souhaite avoir un site compatible avec les différents navigateurs du marché, et tenter de réduire les spécificités pour ne tendre que vers le standard !

Un deuxième point de vigilance concerne les frameworks d'aide au développement HTML5 et CSS3. Ils sont généralement « teintés » et à l’instar de Sencha génèrent uniquement des propriétés préfixées par –webkit-.
 

Et HTML5 dans tout cela ?
Croyez-le, HTML5 n’est pas en reste ! Nous allons enfin pouvoir manipuler des containers flottants qui interagissent ensemble plutôt que d’empiler des layers. Nous pourrons également définir des colonnes dans une <div> pour faciliter la lecture de texte ou encore ranger des <div> dans des régions afin de simuler du paging client bien plus fluide. Côté web controls, les textboxs auront de nouveaux types comme les dates (avec expression régulière de validation intégrée) ou les numériques (avec des bornes min et max).

Mais les grandes fonctionnalités ne s’arrêtent pas à ces quelques considérations graphiques. L’évolution du JavaScript va maintenant nous permettre de gérer finement le cache navigateur, d’implémenter du multi threading, d’ouvrir des connexions par socket au serveur, d’utiliser une base de données NoSQL locale, de gérer les « gestures » et même d’interagir avec le FileSystem client ! Bon, je vous alerte tout de suite avant que les esprits ne s’échauffent, il va clairement falloir blinder tout cela, mais prenons le temps de détailler chacun de ces points.
 

L’AppCache
Ce cache client va nous permettre de garder une application web partiellement fonctionnelle en mode déconnecté. Coté serveur, un fichier manifest va décrire les ressources qui doivent être persistantes en local et celle qui ne le sont pas. Ce fichier est évidemment téléchargé en local.

Cache-Manifest
08/02/2011 – 12:00:00
Cache : logo.jpg;
Network : img1.jpg, img2.jpg;
Fallback : no_image.jpg;

Il est clair que nous en sommes uniquement à une première implémentation, et que le mode de mise à jour de cette définition repose uniquement sur la modification du manifest (la date à l’intérieur par exemple), mais l’utilisation combinée avec la base de données locale va vraiment permettre d’imaginer de nouvelles applications déconnectées. 

Les WebWorkers
Ah, c’est toujours agréable d’avoir des petits copains qui bossent pour nous…Ces petits workers ne sont rien d’autre que des threads JavaScript qui sont malheureusement un peu limités. Pour l’instant, il est uniquement question de les faire discuter via messages interposés, ils n’ont pas accès au modèle DOM non plus car ce dernier n’est pas ThreadSafe.
Cependant, ne ternissons pas trop la note puisque le débug JavaScript de ces workers sera possible ! Et côté implémentation, notez la simplicité d’instanciation :

Var monWorker = new worker("fichier.js"); 

Les WebSockets
Non vous ne rêvez pas, il est bien question ici de réhabiliter le bon vieux mode connecté avec des ouvertures de sockets. Cette technologie mêlant protocole (normalisé par l’IETF) et API (normalisée par le W3C) arrive globalement à maturité. Le principe comme vous vous en doutez, revient à établir une connexion à états entre le client et le serveur suite à une demande du client. Une fois le tuyau ouvert, le serveur aura toute la latitude pour faire du push sur le client, uniquement lorsque cela sera nécessaire. Nous allons enfin pouvoir nous passer des surcharges réseau dues aux requêtes multiples ordonnancées toutes les minutes qui vérifient si une nouvelle information serveur n’est pas disponible.
Le refresh twitter, ça vous parle ? L’actualisation des informations Boursières ? La synchronisation d’une présentation web sur différents postes clients ?
Bon, je vois déjà les anciens grincer des dents et je ne pourrais pas les blâmer. Comment va-t-on gérer l’ouverture et surtout la conservation des connexions WebSockets multiples coté serveur alors que c’était justement là le problème d'antan ?
Même si les nouvelles architectures 64bits vont nous autoriser une plus grande tolérance à la charge, je vous annonce qu’il faudra passer par un design affûté afin de ne pas écrouler les serveurs.
 

L’IndexedDB
Cette base de données locale utilise le concept du NoSQL, à savoir un dictionnaire de paires clé-valeur. Accessible en JavaScript, les applications web vont pouvoir stocker des informations sur le poste client de manière un peu mieux organisée.
Bien sûr, n’imaginez même pas une seule seconde qu’un quelconque mécanisme de synchronisation entre une IndexedDB de type dictionnaire et une base relationnelle serveur soit fourni, il vous faudra encore vous creuser les méninges pour l’implémenter et pouvoir imaginer implémenter dans ce mode une véritable application nomade ! 

Le Touch
Microsoft se devait d’intégrer une gestion du mode « tactile » dans son navigateur. Les Drag&Drop sont maintenant gérés nativement par Internet Explorer  via du JavaScript. De plus, on ne fait plus de différences sur le device de pointage (souris, doigts…) et l’on se focalise sur les évènements de type MSPointer . Les TouchEvents se trouvent alors unifiés via les évènements suivant :

  • MSPointerDown
  • MSPointerMove
  • MSPointerUp

Il en va de même pour la gestion des mouvements :

  • MSGestureStart
  • MSGestureChange
  • MSGestureEnd

En revanche, là encore ne vous enflammez pas trop, Microsoft ne livre pas de moteur de reconnaissance de mouvement, ces fameuses « gestures ». Il vous faudra donc implémenter vous-même l’analyse des listes de points récupérés renvoyés… 

La FileAPI
Cette nouvelle API JavaScript offre des possibilités jusqu’alors interdites : accéder à un fichier du FileSystem client depuis le navigateur. Evidemment, ces opérations d’I/O ne seront tolérées qu’après autorisation accordée par l’utilisateur. Cette API va alors nous permettre de manipuler des objets standards tels que des Blobs, des Files et autre FileReaders…
En ce qui me concerne, j'attends d'en savoir un peu plus sur l'isolation de cette API, car l'erreur de click risque de couter chers à certains ! Je n'ai personnellement aucune envie de voir mon disque
mirroré sur un serveur russe par simple inadvertance d'autorisation accordée à la va-vite.  

En conclusion...
Microsoft nous annonçait une simplification dans le modèle de développement. J'ai bien peur que ce soit l'inverse avec le renouveau de JavaScript et des nouvelles conceptions d'IHM. Là où la complexité résidait coté serveur (parallélisme, gestion de cache mémoire...) elle débarque aujourd'hui côté client, mais sans la rigueur de conception. De plus, le développeur commence tout juste à se sentir à l'aise en mode déconnecté avec un peu d'asynchrone que l'on vient le perturber avec un peu de connexion par socket. JavaScript a toujours eu l'image du langage de script brouillon. Tout ce que l'on va avoir aujourd'hui pour mettre un peu de propre dans ce code se résume à des templates ou des patterns d'implémentation et à des séparations dans des fichiers js distincts. Cela me rappelle vaguement la structuration du code C des années 80-90...
Une fois de plus, il sera primordial de ne pas mettre tous ses œufs dans le même panier et d'utiliser chacune de ces technologies avec pertinence ! 

Nous voyons que nous avons entre les mains de jolies fonctionnalités qui vont nous permettre de réaliser de interfaces d'application web encore plus intuitives, dynamiques et réactives, le tout en se passant d’un client lourd embarqué dans notre navigateur. Est-ce pour autant la mort de Silverlight me demanderez-vous ? Non pas encore, Microsoft annonce son support pendant encore 10 ans.
Alors, qu'est-ce qu'il manque à HTMLS5, CSS3 et les différents navigateurs ? Un peu de maturité sans aucun doute…  

Si vous voulez tester tous ces goodies graphiques, rendez-vous à cette adresse : http://ie.microsoft.com/testdrive

Autour du même sujet