Chez Jérémie - Mot-clé - HTML

Lier CSS à Javascript : une mauvaise idée

Jeremie — Mon, 13 Feb 2012 09:30:00 +0100

J’ai récemment lancé un twitt qui a généré un nombre important et plutôt surprenant de réactions. Vous n’êtes pas sans savoir qu’actuellement, l’utilisation des préfixes vendeur en CSS est une source de grande tension. Parmi toutes les solutions qui existent pour essayer de limiter l’impact de l’usage de ces préfixes, le script -prefix-free de Lea Verou est une solution actuellement très en vogue… mais dont je déconseille très fortement l’usage.

Soyons clair, je n’ai pas l’intention d’alimenter le débat sur l’opportunité ou non d’utiliser les préfixes vendeur. Si vous les utilisez, utilisez les bien, utilisez toutes les variantes de tous les vendeurs. C’est tout.

Non, mon sujet ici, ce sont tous ces scripts Javascript qui vont conditionner l’usage de CSS lorsqu’ils sont utilisés dans un navigateur Web. -prefix-free bien sûr, mais également less.js, respond.js, cssFX, mediatizr, WebFont loader, etc. Je n’ai pas ici la prétention de vous convaincre de ne pas les utiliser. D’une part parce que vous faites bien ce que vous voulez (c’est aussi ça le Web) et d’autre part parce qu’il m’arrive même à moi de m’en servir et ce serait quand même assez gonflé de ma part de vous dire « faites ce que je dit, pas ce que je fait »

L’idée, c’est plutôt de vous détailler les risques auxquels vous vous exposez pour que vous puissiez ensuite faire votre choix en votre âme et conscience.

Performance

L’usage de ces scripts induit un certain nombre de biais dans les performances de vos sites. Souvent, les scripts comme -prefix-free sont appréciés car « ils permettent de réduire le poids des CSS ». Ce qui est vrai mais au prix du poids du script lui-même (le jeu en vaut-il la chandelle) et de requêtes HTTP supplémentaires (vous êtes sûr de n’avoir aucun problème de latence ?).

Au delà de ces points largement discutables il y a tout de même quelques autres éléments à considérer :

Le rendu complet de votre site est suspendu au chargement de vos scripts. Le temps de rendu peut donc être altéré si vous êtes sur des connexions de mauvaise qualité comme du EDGE en réseau mobile. Cela peut se constater de manière bénigne avec la présence d’un léger FOUC ou bien plus gravement en cas de problème de chargement du script ce qui peut complètement casser votre design.
Le rendu devient également dépendant des performances globales d’exécution de vos scripts. Avec un seul petit script qui va agir sur une petite feuille de style, vous ne verrez jamais de problème. Mais que va-t-il se passer avec plusieurs centaines de Ko de scripts et de feuilles de style ? Par exemple, un script comme -prefix-free est un script linéaire : plus la feuille de style sera grosse, plus il prendra de temps pour s’exécuter car il l’examine entièrement. Que se passera-t-il alors si ce script est ralenti ou gêné ou traité après tous les autres scripts de la page (ce qui inclut vos scripts, mais également ceux que vous ne connaissez pas et qui sont utilisés par les extensions ou les bookmarklets de l’utilisateur) ?

Bref, utiliser ce genre de script vous fait consommer des ressources que vous pourriez utiliser pour des choses plus importantes que du style avec tout les effets de bords potentiels que je viens de vous énumérer.

Maintenabilité

Un des principaux avantages mis en avant pour ces scripts, c’est la simplification de la maintenance. Raphael Goetter l’a d’ailleurs bien expliqué sur son blogue. Là, je crois qu’il faut s’y arrêter quelques minutes.

Chaque script apporte son lot d’avantages, mais il apporte également son lot de problèmes. Aucun script n’étant parfait du premier coup, vous allez également devoir assurer sa maintenance. Il vous faudra le mettre à jour en fonction de ses propres évolutions ou prendre le risque de vous retrouver coincé avec un outil qui ne vous rendra plus les services que vous attendiez.

Il faut prendre en considération que ces scripts sont intimement liés à vos feuilles de style car plus vous les voudrez génériques plus ils seront volumineux et potentiellement bugués. Concrètement, cela veut dire qu’à chaque fois que vous allez mettre vos feuilles de style à jour, vous allez devoir vous assurer que le script fait bien son travail. Cela signifie plus de tests et en cas d’erreur, plus de temps pour débuguer car vous aurez alors deux sources d’erreurs potentielles.

C’est particulièrement vrai avec un script du type de -prefix-free. Pour vous épargner de saisir quelques lignes de CSS en plus, vous vous rajoutez un risque projet non-négligeable. Tant que ça marchera, oui, vous gagnerez du temps. Par contre, à la seconde ou vous allez rencontrer un problème, vous allez perdre beaucoup de temps. Sera-ce plus ou moins que le temps gagné ? Difficile à dire car cela dépendra énormément de votre connaissance des technologies en jeu ainsi que des outils que vous utilisez. Mais encore une fois, pourquoi prendre un risque là ou vous n’en aviez pas avant ?

Et l’utilisateur dans tout ça ?

Alors malgré tout ça, faut-il vraiment renoncer à utiliser tous ces scripts pourtant bien pratiques ? Il n’y a pas de réponse simple à ça. Pour être franc, il n’y a jamais de réponse simple en matière d’utilisation des technologies Web. Les contextes projets sont tous différents et certains justifient pleinement l’usage de ces scripts.

Néanmoins, avant de les utiliser, je vous invite à vous poser les questions suivantes :

Le script que je vais utiliser me permet-il de compenser un manque de compétences (techniques ou organisationnelles) de l’équipe projet ?
Dans l’affirmative, cela reviens à essayer de mettre un pansement sur une plaie ouverte. Si la plaie est petite, cela permettra de patienter le temps que l’équipe se forme aux techniques requises. Si la plaie est profonde, ça ne fera que retarder le moment où il faudra prendre des mesures drastiques (et donc coûteuses) pour éviter l’infection.
Préférez un bon plan de formation à moyen terme et à court terme, prévoyez l’intervention d’un développeur sénior capable d’épauler l’équipe. Si vous travaillez seul, faites l’effort de vous former ou changez de métier.
Le script que je vais utiliser est-il là uniquement pour mon propre confort ?
Si c’est le cas, sachez que j’ai alors assez peu de considération pour vous (je sais, ça vous fait un belle jambe, mais au moins c’est dit). Ce genre d’attitude égoïste est exactement ce qui fait que le Web ouvert, standard et interopérable s’étiole. Si vous pouvez faire la même chose sans utiliser de script, faites le. Vous rendrez service à tout le monde en commençant par vous-même
Le script que je vais utiliser me permet-il d’améliorer l’expérience utilisateur ?
Là, effectivement on peut sans doute se permettre de l’utiliser. L’utilisateur devrait toujours être votre point de référence. Quand vous réalisez un site Web, il y aura toujours au final un utilisateur qui va s’en servir. C’est compliqué de se dire qu’on travaille pour un utilisateur. En effet, trop souvent, les promoteurs et acteurs d’un projet se concentrent sur leur propres préoccupations. Les developpeurs et la pureté technique, les responsables métier et leur ROI, les chefs de projet et leur suivi budgétaire, Les designers et leur égo démesuré… autant d’écueils qu’on a tous un jour rencontrés. L’utilisateur, c’est un peu la petite lumière dans la nuit… ne le perdez jamais de vue, c’est votre bouée de sauvetage.

Alors voilà, malgré toute ma bonne volonté et même si je trouve que -prefix-free ou cssFX sont de très beaux projets, les utiliser revient, pour moi, à répondre « oui » à ma deuxième question. Vous comprendrez donc qu’en ce qui me concerne, je ne peux pas cautionner son usage sur un site en production. Je peux comprendre qu’on n’ait pas envie de passer des heures à maintenir des listes sans fin de propriétés préfixées. Mais dans ce cas, faites plutôt le choix des préprocesseurs CSS (LESS, SASS, etc.) qui vous permettront de manipuler des feuilles de style plus simples tout en vous assurant qu’elles comporteront bien tous les préfixes qui vont bien au moment de leur publication.

PS : Merci à Julien et Richard pour la relecture de mon orthographe déficiente

Faire peau neuve

Jeremie — Wed, 15 Sep 2010 20:31:00 +0200

Depuis maintenant 2 ans que je tiens ce blog, il était grand temps de faire peau neuve. Je profite donc du CSS Summer refresh organisé par Alsacreations pour dire au revoir au gabarit par défaut de Dotclear et mettre en place un vraie gabarit utilisant HTML5 et CSS3.

Partis pris graphiques

L'idée maitresse de ce design consiste à mettre l'accent sur la lisibilité. Ce site étant un blog, tout tourne autour des articles qui y sont écris, tout le reste n'est qu'accessoire. L'entête et le pied de page sont donc réduit au minimum, la zone de lecture principal prend l'essentielle de la surface visible, et la colonne de gauche ne sert quasiment que d'aide à la navigation sauf sur la page d'accueil ou je m'étale un peu.

L'idée secondaire de ce design consiste à simplifier au maximum la navigation. Pour cela, étant donné la place que prend le contenu principal, j'ai choisi de rendre l'en-tête et le pied de page fixe. La colonne de gauche est partiellement fixe. En fait, cela dépend de son contenu, si elle est trop grande, elle se déplacera avec le contenu de la page, si elle est assez petite, elle restera fixe.

Couleurs

Les dominantes de couleur sont le noir est blanc, là encore pour rendre la lecture plus confortable. Néanmoins, je nuance le site à l'aide de rouge et de vert, des couleurs très naturelles, alliance de chaleur et de fraicheur. Le rouge est utilisé pour toutes les zones d'action (essentiellement les liens). Il est assombris ou affadis selon les cas afin de ne pas trop interférer avec le contenu et donc la lisibilité. Le vert est utilisé pour les zones de repos (Affichage de code source), et les actions à retardement (bouton de validation des formulaires)

Typographie

Afin de gagner en expressivité, j'utilise deux polices typographiques : Georgia pour la titraille des articles et Molengo pour tout le reste. Molengo est une police de caractère sans empattement, ronde et équilibré. Même si elle souffre de quelques défaut de hinting (regardez la largeur des futs des i et f par rapport à celle des m et n), elle supporte remarquablement bien la réduction et est très adaptée aux usages web. Elle permet de donner de la douceur au texte et de rendre la lecture plus fluide. C'est important dans la mesure ou j'ai tendance à écrire des articles long. Ce choix typographique me permet de limiter la fatigue visuel et de mieux "faire passer la pilule". Dans le même ordre d'idée, au rayon des subtilités, vous n'aurez peut être pas remarqué, mais les bandeaux noir en en-tête et pied de page sont en fait gris très foncé. Cela permet de rééquilibrer le contraste avec le gris typographique naturel et d'éviter qu'ils n'écrasent (trop) le texte.

Partis pris techniques

L'idée sous-jacente de ce re-design, c'est bien sur d'exploiter au mieux les capacités des navigateurs en terme de support de CSS2/3 et de HTML5. Pour HTML5, cela se résume à l'utilisation de certaines nouvelles balises (section, article, aside, header, footer). Pour ce qui est de CSS, J'essaye au maximum d'utiliser les capacité de CSS2 (max-width, position : fixed, sélecteur d'attribut) et un peu de CSS3 pour rajouter quelques effets, ce qui me permet d'obtenir un design fluide qui s'adapte assez bien à tous les types de navigateurs et d'écrans.

media queries

L'utilisation du module "Media Queries" de CSS3 me permet de contrôler la façon dont mon design va se dégrader selon les capacités du terminal qui affiche ma page. Ainsi, les écrans haute résolution afficherons les polices typographiques dans un corps de texte plus important afin que le texte reste toujours aussi confortable à lire. D'un autre coté, pour les écrans de très petite dimension (smartphone et écran à faible résolution), le design est simplifié et linéarisé... encore et toujours pour améliorer la lisibilité.

Couleurs transparente

Une des nouveauté de CSS3 les plus facile à utiliser, ce sont les couleurs transparentes. Elles permettent de créer des effets assez subtile de superposition sans avoir à multiplier les images. Ainsi, mes images d'arrière plan sont toujours visibles mais affadies lorsque du texte est affiché par dessus. Pour cela, il suffit d'avoir un blanc ou un gris légèrement transparent en arrière plan des textes qui viendront se superposer aux images.

transitions

Les transitions me permettent ici de rajouter un peu de douceur au design en créant des transitions de couleur un peu moins abrupte que ce que permet CSS seul d'ordinaire.

Arrière-plans multiples

La possibilité de définir des valeurs multiples pour les propriétés CSS est sans doute une des plus remarquable avancée de CSS3. Je l'utilise ici pour définir des images multiples d'arrière-plan. Cela permet dans le cadre d'un design fluide de pouvoir placer mes deux fleurs à chaque extrémité de l'écran, sans avoir à me soucier de la taille de l'écran et sans avoir à recourir à un sur-balisage HTML inutile.

Enrichissement progressif et dégradation harmonieuse

Globalement, ce design se dégrade très bien dans un navigateur qui supporte correctement CSS2 (et donc, il se dégrade très bien dans IE8, qui ne bénéficie tout simplement pas des amélioration de CSS3)

Les seuls vrais problèmes interviennent avec le cauchemar du web designer : IE6 et 7. Pour ces deux navigateurs, j'ai rajouté quelques styles spécifiques pour s'assurer que la dégradation n'est pas trop déconnante.

Pour vous faire une idée, le navigateur de référence lorsque j'ai créer ce design fut Firefox 3.6. Tous les navigateurs plus récent bénéficieront de tout ou partie des avancés des CSS3 pour avoir un design un peu plus léché et/ou subtile. A l'inverse, la dégradation se fait très bien dans IE8 (le design est un peu plus grossier mais conforme à la logique global) et IE6 et 7 sont clairement moins jolis mais toujours aussi utilisable et les prérequis du design (lisibilité et navigation simplifié) sont respectés.

SVG et HTML5 font bon ménage avec Firefox

Jeremie — Mon, 26 Jul 2010 15:00:00 +0200

Pour faire suite à mon précédent article sur SVG, je vous propose de partir explorer la révolution technique que représente la possibilité d'inclure du SVG directement dans un document HTML. Cette possibilité fait partie du futur standard HTML 5. C'est une fonctionnalité qui sera disponible dans Firefox 4 et Internet Explorer 9 dès leur sortie. Alors comment ça marche et qu'est-ce qu'on peut en faire ?

Les premiers seront les derniers

Une fois n'est pas coutume, on va commencer par la fin. Dans cette article je vais vous détailler comment j'ai réalisé la démo suivante qui permet de transformer n'importe quelle image ou vidéo disponible en ligne en un Puzzle jouable :

http://jeremie.patonnier.net/experiences/svg/inline/puzzle.html

Pour pouvoir voir et utiliser cette démonstration, vous avez besoin d'un navigateur qui supporte les fonctionnalités suivantes :

Le support de SVG directement au sein des documents HTML5
Le support de la balise canvas
Le support des filtres SVG
Le support des balises clipPath et foreignObject de la norme SVG
Le support de l'API localStorage et de JSON (ça, c'est un peu la cerise sur le gâteau)

Au moment où j'écris ces lignes, le seul navigateur qui réunisse ces conditions nativement est Firefox 4 beta 2. C'est avec lui que j'ai fait tous mes tests.

Vous pouvez aussi tester cette démo avec Firefox 3.6. Néanmoins, pour cela, vous devez activer le support du parser HTML5. C'est possible en vous rendant à l'adresse about:config, en y cherchant le paramètre html5.enable et en lui donnant la valeur true. Attention, il s'agit d'une version expérimentale du parser HTML5 qui n'est pas nécessairement très stable. Pensez à le désactiver une fois que vous aurez finit de jouer (Ceci dit, personnellement, je n'ai jamais eu de problème avec)

A terme, IE9 supportera toutes ces fonctionnalités. Malheureusement, la Plateform Preview 3 ne supporte pas correctement les filtres et comme je n'ai pas de machine tournant sous Windows 7, je n'ai pas pu tester pour voir ce que ça donnait en l'état.

Concernant Safari, Chrome et Opera, je n'ai pas entendu parler d'un support à court terme de SVG directement au sein des documents HTML5.

Mais pourquoi, John ? Pourquoi ?

Avant de détailler comment j'ai utilisé chacune des technologies mise en œuvre, voyons d'abord les raisons des choix techniques fait ici.

SVG directement utilisé dans un document HTML5
D'un coté, SVG va permettre de dessiner assez facilement les formes tarabiscotées des pièces du puzzle. D'un autre coté, HTML est plus facile à manipuler dès qu'il s'agit de mettre en œuvre une interface utilisateur. Le plus simple est donc d'inclure l'un dans l'autre. Techniquement parlant, il est plus facile d'intégrer du SVG dans HTML que l'inverse car on n'a (presque) pas à se soucier de la gestion des espaces de nom XML de SVG et de XHTML, le parser HTML5 s'en occupe tout seul.
Le support de la balise canvas
Prendre une source graphique pour en faire un puzzle requière de la manipuler, à minima pour la découper en morceau représentant les pièces. Dès lors qu'on parle de réaliser des opérations de cette nature, c'est canvas qui est le plus indiqué. En outre, cela permet également de traiter n'importe quelle source graphique supportée par le navigateur en entrée et d'en obtenir une sortie unifiée et manipulable de la même façon, peut importe qu'il s'agisse d'une image ou d'une vidéo (ou même d'une page web quelconque... mais je ne suis pas allé aussi loin ici).
Les filtres SVG
Les filtres SVG permettent d'appliquer très simplement des effets spéciaux sur n'importe quel élément SVG, et, dans le cas de Firefox, sur n'importe quel élément HTML. En outre, les filtres étant déclaratifs (matérialisé sous forme de balises SVG) il est très facile de les modifier et de les ajuster sans avoir à recourir à de complexes artifices de programmation.
Les balises SVG clipPath et foreignObject
La balise clipPath permet de créer des formes de découpes applicables à un objet. Par exemple, si vous voulez "percer un trou" dans une image, c'est exactement ce qu'il vous faut. Si vous vouliez faire la même chose avec canvas, ce serait possible, mais au prix d'un intense effort de programmation sans la souplesse de pouvoir changer simplement la forme de votre découpe. La balise foreignObject permet quand à elle d'embarquer n'importe quoi dans du SVG. En effet, si au sein d'un document HTML5 il est possible de mettre des îlots de SVG, ça ne veux pas dire que vous pouvez mettre du HTML n'importe comment au milieu des balises SVG.
L'API localStorage et JSON
Pas indispensable, mais c'est un moyen simple de pouvoir sauvegarder automatiquement la progression de votre Puzzle.

Bouger ou ne pas bouger, tel est la question

La première chose que j'ai faite c'est de prendre la source graphique qui servira de puzzle et de la redessiner dans un élément canvas. J'utilise cela comme une couche d'abstraction. En effet, une fois la source graphique convertis en un élément canvas, je n'ai plus à m'en soucier et quelques soit les opérations que je ferais par la suite, je me contenterai de manipuler un canvas. Accessoirement, l'opération est d'une trivialité absolue :

monCanvas.getContext('2d').drawImage(maSourceGraphique, 0, 0, maSourceGraphique.width, maSourceGraphique.height);

Néanmoins, ce n'est pas tout à fait suffisant pour gérer les vidéos. En effet, pour que l'élément canvas donne l'impression d'être animé comme la vidéo, il faut redessiner le canvas à intervalle régulière au fur est à mesure de la lecture de la vidéo. Pour cela, il suffit d'utiliser la fonction setInterval pour que la méthode drawImage soit appelée régulièrement.

Une fois que ce premier élément canvas est réalisé, chaque pièce du puzzle comprendra son propre élément canvas dans lequel on dessinera la portion du premier canvas qui lui correspond. Cette double utilisation de l'élément canvas est nécessaire pour 2 raisons :

Question de performance : Sean Christmann a montré dans un article sur l'utilisation des balises video et canvas que l'usage de deux canvas successifs pour réaliser des effets spéciaux sur les vidéos apporte un gain non négligeable vis à vis des performances.
Les limites de l'implémentation de SVG : En théorie, il serait possible de définir un élément canvas réutilisable au sein de SVG. Malheureusement les tests que j'ai pu réaliser mon montrés que ce n'était pas possible. Il faut donc créer un élément canvas distinct pour chacune des pièces.

One piece to rule them all

Chaque pièce du puzzle sera un élément svg à part entière créé sur le même modèle. Cela a plusieurs avantages :

Lors du déplacement des pièces, celles-ci pourront êtres déplacées sur l'intégralité de la surface du document HTML. Si elles avaient été une sous-partie d'un seul élément svg, le déplacement aurait été contraint à la zone visible du document SVG correspondant.
Toutes les pièces reposant sur la même arborescence DOM, il est possible de créer une arborescence générique qui sera clonée autant de fois que nécessaire pour créer toutes les pièces.

L'arborescence DOM d'une pièce de puzzle ressemble à ça :

<svg class="piece" width="155" height="155" x="0" y="0">
    <defs>
        <path id="p1_1" d="M10 10 h100 v26 a23,23 0 1,0 0,48 v26 h-25 a25,25 0 1,1 -50,0 h-25 Z"/>
    </defs>
    
    <clippath id="c1_1">
        <use xlink:href="http://jeremie.patonnier.net/post/2010/07/26/SVG-et-HTML5-font-bon-menage-avec-Firefox#p1_1"/>
    </clippath>
    
    <g>
        <g clip-path="url(#c1_1)">
            <foreignobject x="10" y="10" width="125" height="125">
                <canvas width="125" height="125"></canvas>
            </foreignobject>

            <use xlink:href="http://jeremie.patonnier.net/post/2010/07/26/SVG-et-HTML5-font-bon-menage-avec-Firefox#p1_1"/>
        </g>
    </g>
</svg>

Quelques explications sur cette arborescence :

La balise path est encapsulée dans une balise defs. Grâce à cela la forme de la pièce est masquée et pourra être réutilisée à plusieurs endroit via la balise use. Elle est utilisée une première fois dans la balise clipPath pour définir la forme de découpe de la pièce qui sera appliquée à l'élément canvas. Elle est utilisée une deuxième fois après la balise foreignObject pour pouvoir dessiner un contour autour de la pièce tant que la pièce n'est pas à sa place définitive (pour donner un petit effet de lueur interne sans recourir à un filtre).
La balise foreignObject est entourée de deux balises g. La première (le parent direct de la balise foreignObject) permet d'appliquer la forme de découpe en même temps à l'élément canvas et à l'élément use. La deuxième balise g permet d'appliquer un éventuel filtre d'ombre porté. Si vous appliquez le filtre et la découpe sur le même élément g, le filtre sera appliqué avant la découpe. Si comme ici, vous voulez que le filtre s'applique à la forme résultante de la découpe, vous êtes contraint de sur-baliser votre code SVG pour forcer l'ordre d'application des effets.
Notez l'espace de nom "xlink" sur l'attribut href de la balise use. L'inclusion direct de SVG dans un document HTML5 simplifie drastiquement l'usage des espaces de nom XML mais ne nous en dispense pas totalement. En effet, même dans ce cas d'utilisation, SVG reste du XML et SVG utilisant le langage XLINK pour définir cet attribut href, il est obligatoire de bien spécifier cet espace de nom. Pour éviter d'avoir à faire des manipulations complexes à ce niveau, HTML5 fournis par défaut le raccourcis "xlink" pour gérer cet espace de nom.
Vous noterez que la taille de l'élément svg est plus grande que celle de l'élément canvas. C'est nécessaire car la zone visible de l'élément svg correspond à la portion de la source graphique représentée par l'élément canvas ET les éventuels filtres qui s'y appliqueront pour générer les ombres portées.
La valeur de l'attribut d de la balise path peut faire peur. Je ne vais pas vous détailler ici le pourquoi du comment (ça mériterai un article à part entière) mais sachez juste que c'est cette simple ligne qui fait qu'on a un tracé de pièce de puzzle (ici le coin haut-gauche). Si vous regardez la source du puzzle, vous verrez que j'ai regroupé toute l'intelligence de la construction de ce chemin dans une fonction dédiée. N'hésitez pas à vous amuser à la décortiquer.

T'as d'beaux yeux tu sais !

Pour rendre l'expérience de jeux un peu plus fun, on va rajouter quelques effet spéciaux et fonctionnalités qui vont permettre de lui donner un aspect un peu plus "fini".

Pimp my mouse

L'idée quand on créer des pièces de puzzle qu'on peut manipuler à la souris, c'est de pouvoir gérer la sélection de la pièce selon la forme de celle-ci. Le problème, c'est que si on ne fait rien, la souris régis à une zone rectangulaire, même sur les zones transparentes. Heureusement, de ce point de vue, SVG est bien fichue et sait gérer ça sans avoir à recourir à des dizaines de lignes de code. En fait, ça se résume à un peu de CSS :

svg{
    pointer-events : none;
}

svg canvas{
    pointer-events : auto;
}

La propriété pointer-events permet de définir comment la souris va réagir lors de ses interactions avec un élément. Ici on dit que la souris ne doit pas déclencher d'évènement lorsqu'elle interagit avec un élément svg mais par contre elle doit réagir normalement avec les éléments canvas présent dans nos éléments svg. Comme les éléments canvas sont découpés par un clipPath, seul les parties visibles de l'élément canvas réagiront à la souris (ce comportement est sans doute la principale différence entre les balises clipPath et mask de SVG). Notez que d'un point de vu Javascript, même si la souris ne renvoie pas d'évènement lorsqu'elle interagit avec les éléments svg, les évènements renvoyés par la souris sur l'élément canvas remontent normalement vers l'élément svg est peuvent être interceptés à ce niveau là. La propriété pointer-event ne fait que bloquer l'émission des évènements, elle ne bloque pas leur diffusion ni leur exploitation dans le DOM.

Ombrage, ô désespoirs !

Pour donner un peu de relief au puzzle, je me suis amusé à rajouter des ombres portés sur les pièces : une petite ombre porté quand une pièce est posée n'importe où, une grande ombre porté quand la pièce est "soulevée" et transportée et enfin, pas d'ombre du tout une fois que la pièce est à sa place définitive. Chacune des ombres (la petite est la grande) est définie à l'aide d'un filtre SVG distinct pour chacune. Par exemple, la petite ombre est définie comme cela :

<filter id="smallShadow" filterUnits="userSpaceOnUse">
    <feColorMatrix type="matrix" in="SourceAlpha" result="greySource"
                   values="0 0 0 0 0  0 0 0 0 0  0 0 0 0 0  .6 .6 .6 .6 0"/>

    <feGaussianBlur in="greySource" stdDeviation="2" result="flou"/>
    <feOffset in="flou" dx="1" dy="1" result="Ombre"/>
                
    <feMerge>
        <feMergeNode in="Ombre"/>
        <feMergeNode in="SourceGraphic"/>
    </feMerge>
</filter>

Pour faire simple, ce filtre prend la source alpha (la transparence) de l'élément auquel va s'appliquer le filtre, lui applique une matrice de couleur (feColorMatrix) pour quelle soit noir et légèrement transparente, va la flouter (feGaussianBlur), la décaler (feOffset) vers le bas et la droite et va recombiner le tout (feMerge, feMergeNode) avec la source graphique de l'élément. Je ne vous détail pas plus précisément que ça l'usage des primitives de filtres car cela mériterai un article à lui seul, mais c'est tout ça qui fait qu'on a une ombre de forme arbitraire (contrairement à la propriété CSS box-shadow qui ne produit que des ombres rectangulaires... éventuellement avec des coins arrondis, mais c'est tout).

L'application des filtres se fait très facilement directement via CSS

.shadow > g{
    filter:url(#smallShadow);
}

#drag.shadow > g{
    filter:url(#bigShadow);
}

.lock.shadow > g{
    filter:none;
}

Vous n'avez alors plus qu'à jouer sur les classes est les ID de vos éléments avec Javascript pour appliquer ou non un filtre. Notez que Firefox permet également d'appliquer un filtre SVG à n'importe quel élément HTML. C'est ce que j'utilise pour griser l'aide du puzzle qui n'est qu'un simple élément canvas affiché sur l'aire de jeu auquel j'applique un filtre de matrice de couleur.

Allo ! Caroline ! C'est Roger.

Dernière fonctionnalité, la sauvegarde automatique du puzzle en arrière plan. A chaque fois que vous déplacez une pièce, il y a un appel à l'API localStorage de HTML5 pour enregistrer la position de la pièce. De cette manière, si pour une raison ou une autre vous devez interrompre votre partie, vous pouvez la reprendre plus tard exactement là ou vous vous étiez arrêté.

Pour simplifier les traitements, je stocke toutes les données représentant l'état du puzzle dans un objet spécifique. L'API localStorage stocke les données sous la forme clé/valeur. La norme est assez flou sur le type de donnée qui peuvent être stockées mais Firefox n'accepte que les chaines de caractère comme valeur à stocker donc, pour enregistrer mon objet, je le transforme en chaine en utilisant le support natif de JSON tel que définie dans la norme ECMAScript 5 :

var data = JSON.stringify(this.savedData);

window.localStorage.setItem('currentPuzzle', data);

La récupération des données est tout aussi simple :

var data = window.localStorage.getItem('currentPuzzle');

data = JSON.parse(data);

Parfois, c'est le vil coyote qui gagne

Lorsqu'on manipule des technologies nouvellement implémentées dans des navigateurs qui en sont encore au stade des versions Alpha/Beta, il n'est pas rare que l'on soit confronté à des problèmes. Dans ce cas précis, j'ai travaillé avec Minefield qui est la version non-stable de Firefox (et qui représente au moment ou j'écris ces lignes la version de développement du future Firefox 4) et j'ai été confronté à trois types de problèmes différents.

Is there a Road Runner over here?

Les développeurs de Firefox 4 travaillent actuellement comme des malades sur les performances du navigateur et si l'on peut déjà percevoir une amélioration globale des performances, le travail n'est pas terminé et de nombreuses améliorations sont encore attendues dans les semaines à venir. Malheureusement, tout n'est pas parfait...

Dans le cas qui nous occupe ici, le principal problème de performance provient de l'usage des filtres SVG. Les filtres sont actuellement ultra consommateur de ressources pour pouvoir être calculés. Ils sont tellement gourmands que j'ai très vite mis la possibilité de désactiver les ombres portées sur les pièces. En effet, si vous activez les ombres portées et que vous construisez un puzzle basé sur une vidéo, la lecture de celle-ci sera saccadée et le déplacement des pièces ne sera pas fluide. Le problème sera d'autant plus perceptible si vous créez un puzzle avec de nombreuses pièces (plus de 50) car au problème des filtres vient s'ajouter l'augmentation du nombre de nœuds DOM à gérer ce qui peut très vite plomber l'utilisation du jeu (en particulier lorsque vous déplacez les pièces).

Autre point qui peut vite affecter les performances, l'utilisation de l'API localStorage. L'accès en lecture et en écriture via cette API est prohibitif au niveau performance (un peu moins de 100 milliseconde pour une simple opération d'écriture de chaine de caractère sur ma machine... iiirk !). Ainsi si j'avais voulut enregistrer séparément la position de chaque pièces, il aurait fallut près de 10 secondes pour enregistrer l'état d'un puzzle de 100 pièces ! Soyez donc très prudent si vous utilisez cette API car sinon cela peut vite se voir. Si vous prévoyez de faire beaucoup d'opération via celle-ci, je ne saurait trop vous conseiller soit de les traiter en tache de fond asynchrone via l'utilisation de l'API Web Workers, soit de travailler avec un objet contenant vos données que vous transformerez en chaine JSON avant de l'enregistrer intégralement en une seule fois (c'est cette dernière stratégie que j'ai choisie). Si vous n'y faite pas attention, vous pouvez vous retrouver avec un gel complet de votre page !

Robert ! Il y a un cafard dans la machine.

L'intérêt de réaliser ce genre de démo avec une version de développement d'un navigateur, c'est que ça permet de découvrir des bugs qu'il est possible de faire corriger avant la sortie de la version final du navigateur. Les bugs les plus faciles à corriger sont liés à l'implémentation de la balise SVG foreignObject :

Bug 576986 : la balise foreignObject ne respectait pas les règles d'application des évènements de la souris lorsqu'on lui appliquait une forme de découpe. La correction a été apportée dans les heures qui ont suivit. Waow !
Bug 578309 : La balise foreignObject redéfinissait son propre espace de coordonnées, comme si on y avait appliquée une transformation. La encore, il n'aura fallut que quelques jours pour que ce soit corrigé. J'en profite ici pour adresser un grand merci à Robert Longson qui a travaillé sur ces bugs en particulier et qui fait un énorme travail en ce qui concerne le support de SVG dans Firefox.

Mais il y a aussi quelques bugs plus durs qui vont sans doute être assez délicat à résoudre :

Bug 577824 : Quand on attache un élément HTML à l'arbre DOM du document via Javascript et qu'un filtre s'applique sur cet élément, l'élément n'est pas affiché.
Bug 577464 : Celui là, c'est le plus bizarre de tous, et sans doute le plus difficile à résoudre. Dans certain cas de figure, le rendu des éléments auquel est appliquée une forme de découpe n'est pas correctement réalisé. Il est tellement difficile de produire un cas d'utilisation unitaire que son simple diagnostique risque de prendre du temps. Une des pistes actuellement exploré serait un bug lié à la bibliothèque graphique Cairo qui est utilisée par Firefox pour rendre les éléments visuels.

Allo ! Tonton ? Pourquoi tu tousses ?

Après, au delà des éventuels problèmes d'implémentation, il y a aussi les problèmes liés aux spécifications elles-mêmes. Les spécifications qui tournent autour de HTML5 ne sont pas encore finalisées ou pas forcément adapté à certains cas d'utilisation et l'on tombe parfois sur des perles qui peuvent plonger un web designer dans des affres d'incompréhension. J'en ai découvert deux dans ce gout là. Une dans la spécification de l'API Canvas 2D et une dans la spécification de SVG 1.1.

Canvas pas aller ça monsieur.

En l'état de la spécification, avec la méthode drawImage de canvas, il est possible de dessiner soit une image, soit une vidéo. Quand vous dessinez une image, pas de problème, vous dessinez l'image elle-même. Quand vous dessinez une vidéo, ce qui est dessiné, c'est l'image qui est lut par le lecteur vidéo au moment ou on appel la fonction de dessin. Maintenant, que ce passe-t-il si vous voulez dessiner une image animé (aGIF, APNG, MNG, SVG, etc.) ? Moi, assez naïvement, je me suis dit que ça allait dessiner l'image courante de l'animation au moment ou on appel la fonction de dessin... bref que ça allait ce comporter comme avec une vidéo et c'est d'ailleurs comme cela que se comporte Firefox 3.6. Mais que nenni jeune Padawan ! La spécification dit que dans le cas d'une image animé, ce qui est dessiné, c'est la première image de l'animation et puis c'est tout !

http://www.w3.org/TR/2dcontext/#images

When the drawImage() method is passed an animated image as its image argument, the user agent must use the poster frame of the animation, or, if there is no poster frame, the first frame of the animation.

Et chez Mozilla, ils se sont dit que ce serai une bonne idée de suivre la spécification dans Firefox 4. Résultat des courses, j'ai ouvert un bug en pensant à une régression, mais non, c'est juste qu'ils on fait en sorte d'être respectueux de la spécification.

Alors, là, j'ai envie de dire : "Bravo, c'est bien". Mais d'un autre coté, maintenant, on fait comment pour accéder aux autres images qui composent une image animée ? On est typiquement dans un cas ou la spécification est difficile à comprendre et elle reflète sans doute les capacités des fabriquant de navigateur à gérer ce cas d'utilisation. Mozilla sait comment gérer les images animées dans ce cas de figure, mais se bride du fait de la faiblesse de la spécification sur ce point. C'est dommage.

La spécification n'est pas encore définitive et si vous pensez que ce cas d'utilisation est important, faite le savoir. Pour cela, vous pouvez soit faire du lobbying auprès du HTML Worging Group (bon courage !) soit auprès des fabricants de navigateur qui sont directement parti prenante. La discussion est ouverte chez Mozilla et si, par exemple, vous prenez simplement le temps de voter pour le bug que j'ai ouvert, peut-être que Mozilla considèrera qu'il y a matière à pousser le sujet.

SVG, ou l'art de Se Vautrer la Gueule ?

A la base, j'ai fait une mauvaise interprétation de la spécification SVG alors que je voulais réutiliser un élément foreigObject avec la balise use. J'ai naïvement crus que n'importe quelle enfant légitime de la balise g pouvait être réutilisé via la balise use. Malheureusement, ce n'est pas le cas. La balise use ne peut être utilisée que pour dupliquer des éléments explicitement graphique (ce qui n'est pas le cas de foreignObject) ou certains conteneurs (g, symbol et svg). Néanmoins, comme g est un élément valide pour use, il suffit d'envelopper un élément foreignObject avec un élément g est le tour et joué.

Et là de se poser la question : "Mais pourquoi la norme ne permet pas d'utiliser directement tous les enfants légitimes de g ? Pourquoi faut-il rajouter une balise supplémentaire qui a le gout et l'odeur de l'inutile ?". Bien évidement, il s'agit de questions de web designer, pas d'implémenteur. En effet, il y a fort à parier que lorsque la norme a commencé à être écrite (il y a plus de 10 ans, rappelons-le), les développeurs en charge de sa mise en œuvre ont du rencontrer un problème à ce niveau et faire un arbitrage dans ce sens. Ou bien il y a eu un débat philosophique quelconque a propos de ce qu'est la balise use et personne n'a réussie à challenger cette vision. Franchement, je n'en sais rien mais avec le recul que l'on a désormais, la question aurait le mérite d'être à nouveau posée.

De manière général, ce genre de collision malheureuse entre SVG et HTML5 risque de se représenter ailleurs (essayez de contrôler à l'aide de Javascript une balise HTML video que vous avez cloné via la balise SVG use... vous ne pouvez pas !). En effet, on a d'un coté une norme vieillissante (SVG) et de l'autre une norme toute neuve en construction (HTML5). A bien des égards, SVG a été conçus pour vivre dans un univers statique. A l'inverse, HTML5 redéfinis énormément d'éléments dynamiques au travers de nouvelles API Javascript. De ce point de vue, je ne serais pas surpris que HTML5 redonne un coup de fouet à SVG et il n'est pas exclus que dans les années a venir on voit arriver une norme SVG 2 pour résoudre tous ces nouveaux cas d'utilisation... mais bon, ne soyez pas trop pressé. C'est aussi ça qui fait que Flash à encore de beau jours devant lui.

Le mot de la fin (des haricots)

Voila, je viens de vous arroser avec un article copieusement long et en même temps extrêmement raccourcis. Si vous voulez comprendre plus précisément comme marche quoi, je vous encourage à regarder le code source que j'ai essayé de commenter le plus possible. Ce qu'il faut retenir, c'est que le support de SVG dans HTML est encore quelque chose de très expérimental mais cela donne déjà une bonne idée de ce que peut faire chaque technologie respective et ce que l'on gagne à les mixer.

Si vous voulez aller plus loin, n'hésitez pas à lire les spécifications. Elles peuvent parfois s'avérer très utile. La spécification SVG par exemple comporte de nombreux exemples de code très utile à la compréhension. D'autres ressources très utile également sont les documentations techniques des fabricants de navigateurs. En particulier dans le cas de cette démo, le Mozilla Developper Center, mais aussi MSDN, Opera Dev et le wiki de Webkit.

Quoi qu'il en soit, expérimentez vous même et faite vous votre propre idée. Ces technologies sont toutes assez nouvelles, les implémentations évoluent constamment et le processus de standardisation n'est pas linéaire...mais amusez vous, c'est comme ça que vous apprendrez de nouvelles choses

La spécification SVG : http://www.w3.org/TR/SVG/
La spécification HTML 5 : http://www.w3.org/TR/html5/
- L'API Canvas 2D : http://www.w3.org/TR/2dcontext/
- L'API Storage : http://www.w3.org/TR/webstorage/
- L'API Web Workers : http://www.w3.org/TR/workers/
ECMAScript 5 (PDF) : http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf

CSS 3 : Le module "Template Layout"

Jeremie — Thu, 16 Jul 2009 20:10:00 +0200

Le future norme CSS3 est composée de modules qui sont normalisés plus ou moins indépendamment. Parmi eux, il y en un, discret, mais qui représente quasiment le sain Graal de la mise en page en CSS : le module "Template Layout". Eric Mayer s'est récement fait la voix des Web Designer afin d'insister sur le besoins que représente un système de mise en page totalement indépendant du flux de la source HTML. Ok, ce module n'est encore implémenté par aucun navigateur, quoi que... mais voyons ce que cela pourrait apporter.

Avoir un système de mise en page qui permettrai de s'affranchir du flux de la source HTML... le rêve de tout les Web Designer. Aujourd'hui ce rêve est à porter de main, grâce au module "Template Layout" de CSS 3. Pas de fausse joie, à ce jour ce module est jeune (seulement 2 itérations en "Working Draft" dont la première date de 2005) et aucun constructeur de navigateur n'envisage de l'implémenter pour le moment, même à titre expérimental.

Comment ça marche ?

Dans sa forme la plus basique, le système de gabarit proposé par ce module repose sur l'utilisation de deux propriétés CSS existantes : display et position.

display va permettre de définir la grille de positionnement. La technique mise en œuvre ressemble à de l'ASCII Art puisqu'on utilise des lettres réparties sur plusieurs lignes pour définir le gabarit. Chaque lettre du gabarit définie une zone ("Slot" en anglais) dans lequel on pourra placer n'importe quel élément HTML.

Par exemple, un gabarit classique (1 en-tête, 2 colones et 1 pied de page) peut être représenté de la manière suivante¹ :

body{
    display : "aa"
              "bc"
              "dd";
}

C'est la propriété position qui nous permettra d'assigner un élément HTML à un des emplacements. Pour cela, il suffit d'utiliser la lettre représentant la zone désirée comme valeur de la propriété position.

Concrètement, cela se matérialisera de la manière suivante :

#header { position : a ; }
#footer { position : d ; }
#content{ position : b ; }
#sidebar{ position : c ; }

Mouais, mais en quoi c'est vraiment détaché de ma structure HTML ?

Imaginons que vous ayez un élément h2 dans votre partie #content, mais que vous vouliez que celui ci soit visuellement placé dans la zone d'en-tête. Avec les techniques actuelles (floating, positionnement absolu, etc), c'est un vrai casse-tête qui n'a pas de solution élégante. Avec cette nouvelle technique il suffit de rajouter la règle suivante :

#content > h2 { position : a ; }

De cette manière votre élément h2 va se placer dans la zone d'en-tête ou il se comportera exactement comme s'il était un élément enfant de cette zone. Les différents éléments placés dans cette zone s'y empileront dans l'ordre natif du flux HTML.

Mais cette zone, elle est virtuelle, comment je fait pour la styliser ?

Et oui, dans notre exemple, les élément #header et h2 font tout les deux partie de la zone d'en-tête, mais ne sont pas relier au niveau du flux HTML, ou si peu (il ne sont pas enfant d'un même élément qui représente cet en-tête). Bref, structurellement parlant, ils n'ont rien en commun. Cependant, il est tout de même possible de faire "comme si". En effet, pour styliser cette zone d'en-tête virtuel, on peut utiliser le pseudo-élément ::slot()

Ainsi, si je veux que ma zone d'en-tête ait un arrière plan rose, il suffit de faire :

body::slot(a){
    background : #FCC;
}

Malheureusement, à partir de là, je trouve que la spécification est mal fichue. En effet, les styles applicables au pseudo élément ::slot() sont très restreints. On ne peux modifier que les propriétés d'arrière plan, la propriété vertical-align et la propriété overflow. En l'état, il est impossible de modifier les bordures (iiirk !) ou d'appliquer les règles de colonages (mmmh ?) ni même de fixer... la hauteur et la largeur (huuu ?).

Quoi ! On ne peut pas spécifier la taille des zones du gabarit ?

En fait, si, on peut spécifier la hauteur et la largeur des zones du gabarit mais pas via le pseudo élément ::slot(). De mon point de vue, je trouve ça contre intuitif et en désaccord avec les habitudes déjà connu qu'on peut avoir des CSS. En effet, les largeurs et hauteurs des zones ne sont pas spécifiées à l'aide des propriétés width et height, mais directement via la propriété display. Oui, oui, vous avez bien lu : "via la propriété display" !

Ainsi dans notre exemple, si l'on veut avoir un en-tête d'une hauteur de 100px, un corps d'une hauteur qui s'ajuste en fonction du flux et un pied de page d'une hauteur de 2em, il suffit de spécifier les hauteurs voulu après la déclaration de chaque ligne du gabarit. Ce qui donnera (notez la présence du symbole /) :

body{
    display : "aa" /100px
              "bc"
              "dd" /2em;
}

Et si on veut spécifier une largeur automatique pour la colonne de contenu principal et en même temps une largeur fixe de 150px pour la colonne de droite me diriez vous ? Et bien pour cela, il suffit de spécifier vos largeurs à la fin de votre déclaration display dans l'ordre des colonnes de votre gabarit de la manière suivante² :

body{
    display : "a   a"  /100px
              "b   c"
              "d   d"  /2em
               * 150px;
}

Notez l'utilisation du caractère * pour spécifier une largeur qui doit être calculée automatiquement en fonction de l'espace disponible pour cette colonne. Il est également possible de spécifier des largeurs minimum et maximum pour les gabarit fluide, mais je ne vous assomme pas avec ça car je suis près à parier que cela va évoluer (par exemple, il n'est pas possible de spécifier des hauteurs minimum et maximum pour le moment !!!)

Et au fait, pour les bordure on fait comment ?

Comme je vous le disais précédement, il est impossible de spécifier une bordure pour une zone (ni même un padding ou un margin), et de mon point de vu, c'est un très gros manque pour ce module. Ceci dit, il est éventuellement possible de tricher en créant des zones vides ou des espaces entre ces zones. Pour cela vous pouvez utiliser le symbole .

Par exemple, on peut simplement centrer un gabarit de cette manière :

body{
    display : ".  a    a   ."  /100px
              ".  b    c   ."
              ".  d    d   ."  /2em
               * 50% 150px *;
}

Tout cela reste malheureusement un peu insatisfaisant et je soupçonne des raisons liées à la difficulté de maitre en œuvre ce module. Ceci dit, cela évoluera sans doute très vite dès que les première implémentation verront le jour.

Ok, c'est cool, mais on ne peut pas s'en servir ! Non ?

Effectivement, aucun navigateur n'implémente nativement cette fonctionnalité à ce jour. Néanmoins, il existe une implémentation en Javascript sous la forme d'un plugin jQuery (développé par Alexis Deveria) qui ouvre cette fonctionnalité à tout les navigateurs (allez jeter un coup d'œil aux demos, c'est bluffant). Alors oui, vous pouvez commencer à jouer avec les possibilité de ce module.

Néanmoins, temps que ce module ne sera pas plus stable, je vous invite à ne pas en faire usage dans un environnement de production industriel, ou alors avec parcimonie. C'est encore hautement expérimentale.

Mais franchement... ça déchire grave !

la présentation sur plusieurs ligne est là pour simplifier la lecture du gabarit, mais il est tout à fait possible de tout mettre sur une seul ligne
les espaces surnuméraires n'ont aucune influence sur le gabarit, il sont là pour simplifier la lecture

2 ou 3 petites choses qui m'agacent avec HTML 5

Jeremie — Wed, 08 Jul 2009 20:00:00 +0200

Avec la sortie de Firefox 3.5, Safari 4 et prochainement de Opera 10, mais aussi avec les prises de position de Google, actuellement HTML 5 a le vent en poupe. C'est plutôt une bonne chose car les apports de cette norme sont conséquents et véritablement nécessaires. Ceci dit, au-delà du buzz, je lit et j'entends certaines choses qui m'agacent et qui prouvent soit une méconnaissance de la norme en cour d'élaboration, soit un manque de discernement certain. Petite revue de détails... par ce que là, "j'en ai gros" !

HTML 5 n'est pas encore une norme

Ça parait idiot à dire, mais c'est vraie : à ce jour, HTML 5 n'est pas un standard. C'est tellement vraie et l'engouement autour de ce futur standard est tel que, suite aux annonces de Google du mois de mai dernier, le W3C lui même a crue bon de se fendre d'un communiqué pour le rappeler. Au delà de l'aspect formel que cela peut revêtir vis à vis du cycle de normalisation du W3C, HTML 5 n'est même pas un standard de fait. En effet, les navigateurs les plus actifs sur le sujets n'implémentent qu'une petite partie de la future norme et surtout, Microsoft ne prévoie rien de sérieux pour le moment en termes de support de ces fonctionnalités à brève échéance. Quelque soit l'avis que l'on puisse avoir sur les qualités ou défauts de Internet Explorer, il n'en reste pas moins le navigateur le plus utilisé au monde. En particulier sa version 6 qui reste calamiteusement significative et refuse de disparaitre tel un bernique accroché à son rocher !

Ainsi, même si je trouve que HTML 5 est une fabuleuse avancé, il n'en reste pas moins que pour l'instant, celui-ci est inexploitable dans un cadre de production industrielle. On peut expérimenter, se former, appréhender de nouveau concept ou explorer la simplification de concepts connus, mais en aucun cas, un site ne peut prétendre faire une utilisation industriel de ce format sans se fermer à une part significative de son audience... ce qui justifie en soit la position de YouTube par rapport à l'utilisation de la balise <video>... subtile transition vers mon point suivant.

La balise `<video>` n'est pas morte

Une annonce de Ian Hickson concernant l'abandon d'une tentative de normalisation des codecs vidéo utiles à HTML 5 fait actuellement couler beaucoup d'ancre. L'interprétation complétement fantaisiste de cette information ayant parfois pour conséquence d'affirmer que la balise <video> a été purement et simplement retiré de la future norme (à cet égard, le Monde Informatique a fait preuve d'un scandaleux laissé aller journalistique) ! Les moins agressifs sur le sujet, se contente juste d'affirmer que cette balise est morte née et sera inexploitable.

En soit, la balise <video> fait toujours partie de la future norme HTML 5. Ce qui est abandonné, c'est la partie liée aux codecs. Qu'est ce que ça veut dire exactement ? Tout simplement qu'il n'y aura pas de format de vidéo standard sur le Web, exactement de la même façon qu'il n'y a pas de formats standards (comprendre : normalisés par le W3C dans HTML) pour les images. D'aucun de dire que cela signe le glas de la vidéo ouverte sur Internet.

Certes cela peut avoir des conséquences sur la vitesse d'adoption de cette partie de la norme par les constructeurs de navigateurs, mais surtout par les éditeurs de vidéo en ligne. Néanmoins, aujourd'hui, ce qui freine vraiment l'adoption de la balise <video> pour la diffusion de vidéo sur Internet, ce n'est pas un problème de codec, mais bien le fait que Microsoft refuse actuellement de l'implémenter dans Internet Explorer. En effet, aujourd'hui, il y a deux codecs en lice (Theora et H.264), mais les mécanismes de la balise <video> sont suffisamment bien pensés pour qu'il soit possible, grâce à la balise <source> de proposer plusieurs versions d'une même vidéo, les navigateurs n'ayant qu'à faire leur marché dans la liste proposée. Cela représente un petit travail supplémentaire pour les éditeurs de vidéo, mais qui est facilement automatisable dans la chaine de production à cout maitrisable. Mais ce ne sera acceptable par les éditeurs que si la balise <video> est largement supportée afin que le bénéfice de l'utilisation de cette balise soit supérieur au cout induit par du multi-encodage. Ainsi, de mon point de vu, la question des codec n'est pas la plus importante. Ce qui est vraiment bloquant, c'est l'attitude de Microsoft vis à vis de HTML 5.

Qu'est-ce que c'est que cette histoire de "microdata" ?

Alors oui, je trouve que le travail fait autour de HTML 5 est formidable. Oui, cette norme va apporter un lot non négligeable de nouveautés qui vont simplifier la vie des webdesigners. Mais de temps en temps, dans le processus de normalisation, on voit passer des OVNI et on se demande ce qui a traversé l'esprit du groupe de travail. C'est typiquement le cas de ce truc que sont les "microdata". En soit l'initiative est louable : permettre de rajouter des informations supplémentaires à l'usage des machines. Mais est-ce vraiment nécessaire d'avoir un nième langage de sémantisation du Web ? Après tout, le W3C a déjà normaliser RDF et sa déclinaison pour XHTML : RDFa. En outre, les microformats offrent déjà une solution pratique à des problèmes quotidiens de sémantisation particuliers. Alors POURQUOI devrait-il être nécessaire d'en remettre une couche avec une troisième façon de faire ? Est-ce qu'on pensent parfois aux éditeurs de sites Web ? ENCORE une nouvelle technique à apprendre et en plus qui est redondante avec quelque chose déjà existant. En l'état, je sens que ce truc risque de faire long feu pour rien. C'est dommage. Néanmoins, si quelqu'un peu m'éclairer sur les raisons profondes de ce choix, ce sera avec plaisir.

Conclusion

Voila, pour mon petit coup de gueule du jour... il y a encore beaucoup à faire et il y a beaucoup d'attente autour de HTML 5. Si seulement, tout le monde pouvait garder un peu la tête froide, ça avancerai sans doute beaucoup plus rapidement. La norme se développe et à besoin de murir. Inutile de crier au loup pour un oui ou pour un non. De toute façon, aujourd'hui, c'est malheureusement Microsoft qui joue les arbitres dans l'adoption de HTML 5. Malgré un net recule de la part de marché de Internet Explorer, Microsoft reste dans une position ou il peut faire obstruction à l'émergence d'une norme commune. Ceci dit il ne peut pas la bloquer totalement, ni imposer un standard de fait (on voit bien les difficulté que rencontre SilverLight à émerger sur le marché). Microsoft est seulement dans une position où il peut fortement ralentir l'évolution du web ouvert et standard (J'en voie qui ricane au fond là !). C'est en cela que l'adoption à grande échelle de HTML 5 sera longue et douloureuse.