Bon, pour la deuxième fois de la journée, je me suis fait bouler de la session que je voulais suivre. C’est assez pénible… Si on veut vraiment être sûr de voir une session, le seul moyen est de courir vers la salle dès la fin de la précédente. Sauf que passer toute l’après-midi sans boire un café ou un verre d’eau, c’est un peu dur. Et encore, contrairement à la précédente loupée, j’ai pu ce coup-ci voir mon second choix, parce que c’était dans un grand amphi, et là il y a de la place. On a rapidement vu le sujet lors de la plénière du premier jour, mais ce sera l’occasion d’approfondir.
David Catuhe et David Rousset présentent cette session très bien faite, technique mais bien expliquée.
Les limites de la balise video sont le problème des codecs. Visiblement, l’orientation est que, dans l’attente d’un consensus, les différents formats d’encodage proposés sont pris l’un après l’autre en fonction de ce que le navigateur supporte. Par contre, il y a un bug sur les iPad, et du coup, il vaut mieux commencer par mp4 et ensuite webm, de façon que le fallback fonctionne à peu près correctement. Le deuxième niveau de fallback est de rebalancer sur une balise object.
Microsoft propose à validation du W3C la notion de GridLayout. Au lieu de faire des tas de div imbriqués, on va plutôt utiliser un style css3 qui va contenir les col / row / colspan / rowspan d’une façon très proche de ce qu’on fait en XAML. Ainsi, la séparation entre le contenu et le contenant est encore mieux implémentée.
La flexbox est une option proposée par Microsoft également, et qui permet de gérer les tailles différentes d’écran en tassant les images ou en changeant le positionnement avec les syles, plutôt que d’être dépendant du comportement standard de passage sur la ligne en dessous.
La démo expose ensuite le résultat sur le resize d’un navigateur. On peut changer complètement le layout en fonction de la taille disponible. La feuille de style utilise une media query comme @media screen and (orientation: portrait) and (min-width:320 px) pour donner le style associé à cette condition.
SVG étant un format vectoriel, il permet de conserver la qualité comme on le fait en XAML même avec un niveau de zoom. A l’inverse, le Canvas est un point d’entrée de contrôle de tous les pixels d’un bitmap. Autre différence, le SVG est un modèle retenu (qui existe sous forme de domaine en mémoire, qu’on peut manipuler, styler, etc.) alors que le Canvas est un mode Fire & Forget : une fois qu’on a écrit, c’est affiché et impossible à modifier.
RaphaelJS est une librairie JavaScript pour manipuler SVG sous forme d’objets de haut niveau.
La démo montre ensuite les rôles d’accessibilité ARIA, qui s’applique du coup à SVG car il y a un DOM derrière. Donc, l’accessiblité peut tout de même être bonne, à l’inverse du Canvas.
InfoVis est une librairie de haut niveau, mais ce coup-ci du côté Canvas. Au final, il y a autant de puissance, même si le modèle est plus élégant. Par contre, comme on gère les pixels, on peut tout à fait avec un gros frame per second y compris avec des très gros volumes de données. Pour ce qui est de l’accessibilité en mode Canvas, l’idée est surtout d’avoir un fallback avec le mode donnée dans un simple tableau.
Il est intéressant de voir que, au delà du combat entre les deux David pour savoir lequel des deux modes est le meilleur, ils peuvent tout à fait cohabiter.
La présentation passe ensuite sur les animations, qui sont des enchaînements de transitions. Au final, une très bonne session, très fouillée et qui explique bien non seulement le fonctionnement des technos, mais surtout pourquoi elles ont été créées et pour quel besoin précis il faut les utiliser, avec leur limite, etc. C’est suffisamment rare pour être souligné !
