Chez Jérémie

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/#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/#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

Introduction à SVG

Jeremie — Tue, 29 Jun 2010 14:00:00 +0200

Dans les années à venir, le format d'image SVG (Scalable Vector Graphics) va devenir une technologie extrêmement commune sur le Web. Le décollage de cette technologie va se faire grâce à deux évènements d'importance dans le monde du Web. D'une part, avec l'arrivée du support de SVG par Internet Explorer 9, cette technologie sera désormais disponible nativement dans tous les navigateurs majeurs du marché. D'autre part, la norme HTML 5 va normaliser et simplifier la façon d'embarquer du SVG directement au sein des documents HTML. C'est le moment ou jamais de s'intéresser à cette technologie

C'est quoi SVG ?

SVG est un format d'image vectoriel reposant sur une syntaxe XML. Dit comme ça, c'est sûr, ça n'est pas très sexy ! En fait, ce format d'image est un peu le meilleur de deux mondes :

D'un coté, c'est un format d'image vectoriel. C'est à dire que, contrairement à une image bitmap (on dit aussi "matricielle" ou parfois "rastérisée"), les images créées avec ce langage peuvent être agrandies et manipulées sans perte de qualité.
D'un autre coté, elle sont définies à l'aide d'une syntaxe XML.

Ce dernier point a trois avantages :

Le code source des images reste théoriquement humainement lisible (mais ne rêvons pas trop tout de même, hein).
Une image SVG peut être transformée en arbre DOM, ce qui permet de la manipuler facilement avec des langages tel que Javascript.
Il est possible de rendre le contenu de ces images accessible sans recourir à des artifices de substitution ou de contenus alternatifs (par exemple, le texte reste compréhensible comme tel et peut donc être sérialisé pour un lecteur d'écran).

En tant que format d'image, SVG est très riche. En effet, il ne se contente pas de fournir un outillage complet de dessin mais offre également toutes une série de fonctionnalités permettant d'animer et transformer une image sans avoir besoin de recourir à des technologies tiers. Ceux d'entre vous qui ont connu Flash à l'époque où il s'agissait encore d'un simple système d'animation vont retrouver des concepts connus

Comment l'utiliser

Structure de base d'un document SVG

SVG étant un document XML, il suit cette syntaxe :

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
 "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">

<svg width="100" height="100" version="1.1"
 xmlns="http://www.w3.org/2000/svg">

    <circle cx="50" cy="50" r="40" style="fill:#000"/>

</svg>

> L'exemple du document SVG dans votre navigateur

Dans cet exemple on retrouve donc le prologue XML, une déclaration de DTD, l'ouverture d'un balise racine (la balise svg) qui contiendra l'ensemble des balises qui définiront votre image. Pour ceux d'entre vous qui ont l'habitude de HTML mais pas spécialement de XML, notez la présence de l'attribut standalone avec la valeur no dans le prologue XML. Pour faire simple, il permet de dire aux parseurs XML qui vont traiter le document qu'il peut y avoir autre chose que du SVG dans votre document. En effet, les documents SVG utilisent d'autres espace de nom (Xlink pour les liens vers des ressources externes) et peuvent facilement embarquer d'autres langages XML (MathML, XHTML, etc.) via la balise foreignObject.

Si vous avez l'habitude du HTML mais n'avez encore jamais manipulé de document XML, vous devez garder à l'esprit que la syntaxe d'un document XML est beaucoup plus rigoureuse : le respect de la casse est obligatoire, les balises doivent être impérativement fermées, etc. Ceci étant, si vous faites une erreur, vous le saurez vite. En effet, les parseurs XML ne sont pas connus pour leur permissivité, au contraire !

Embarquer un document SVG dans une page HTML

Certes, vous pouvez afficher un document SVG dans votre navigateur préféré (pour IE, il faudra attendre la version 9) mais là ou ça devient intéressant c'est quand on peut le mettre directement dans une page HTML (et le manipuler avec Javascript et le créer à la volée et vous voyez quoi...).

L'utilisation directe de balises SVG dans le code HTML

Cette méthode, c'est le graal en ce qui concerne l'utilisation de SVG. L'idée, c'est de pouvoir mettre n'importe où dans un document HTML une balise svg qui contiendra d'autres balises du langage SVG. Autant dire que ça va simplifier grandement les choses.

Vous ne rêvez pas car c'est ce que propose la norme HTML 5. Par contre, pas de bol, ce n'est implémenté dans aucun des navigateurs du marché pour l'instant... enfin presque. En effet, actuellement Firefox permet l'inclusion directe de SVG au sein d'un document XHTML. La nuance est importante car cela signifie que vos pages XHTML doivent êtres servies avec le bon type mime par le serveur et que le document sera analysé à l'aide d'un parseur XML et non pas HTML (en gros permissivité 0, au moindre truc de travers, la page ne sera pas affichée ou alors avec un gros message qui fait peur... vraiment !).

Dans Firefox, ça donne ça :

<?xml version="1.0"?>
<!DOCTYPE html PUBLIC
"-//W3C//DTD XHTML 1.1 plus MathML 2.0 plus SVG 1.1//EN"
"http://www.w3.org/2002/04/xhtml-math-svg/xhtml-math-svg-flat.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <title>Exemple de tags SVG dans un document en XHTML</title>
</head>
<body>

<svg:svg xmlns:svg="http://www.w3.org/2000/svg" width="100" height="100" version="1.1">

    <svg:circle cx="50" cy="50" r="50" style="fill:#000"/>

</svg:svg>

</body>

> Voir l'exemple XHTML

Dans le future Firefox 4 (prévus pour fin 2010, début 2011) ainsi que dans IE 9, il sera possible d'embarquer du SVG dans un document HTML 5 sans avoir à se préoccuper de la gestion des espaces de nom. Vous pouvez d'ailleurs déjà tester cette fonctionnalité dans les "nightly build" de Firefox 3.7/4 ou avec la version de test du moteur de IE9. Cela permettra de réaliser ce type de document :

<!DOCTYPE html>

<html>
<head>
   <title>Exemple de tags SVG dans un document en HTML 5</title>
</head>
<body>

<svg width="100" height="100">

    <circle cx="50" cy="50" r="50" style="fill:#000"/>

</svg>

</body>

> Voir l'exemple HTML

SVG c'est un format d'image, alors pourquoi pas la balise `img` ?

Dans la mesure où SVG est un format d'image, on peut légitimement penser pouvoir utiliser la balise img pour inclure ce type de document :

<img src="http://jeremie.patonnier.net/post/2010/06/29/cercle.svg" alt="" />

> Voir l'inclusion via img

Néanmoins, utiliser SVG de cette manière n'est pas trivial. Par exemple, il est possible d'embarquer des langages de scripts dans un document SVG. Or, qui dit langage de script, dit problème de sécurité et la balise img n'a pas été conçue à la base pour traiter ce genre de question. De même, déterminer la taille par défaut en pixel d'une image vectorielle peut parfois être un peu délicat. Ceci dit, les constructeurs de navigateurs y travaillent dur :

Webkit supporte cette fonctionnalité depuis 2008 (Safari 3.1)
Opera supporte cette fonctionnalité au moins depuis la version 9.64
Pour Firefox, le sujet est en discussion depuis des années mais ça devrait être réglé dans Firefox 4.
IE9 embarque cette fonctionnalité dans sa roadmap.

Et avec CSS aussi pourquoi pas !

Le support de SVG comme une source d'image dans CSS ouvre des perspectives inimaginables jusqu'à présent. En particulier, comme SVG est un format vectoriel qui supporte parfaitement l'agrandissement et la réduction, cela permettra de créer des arrières plans extensibles sans perte de qualité. Ainsi, écrire quelque chose comme ça, ne posera plus aucun problème :

div{
    width : 50%;

    background-image : url(cercle.svg);
    background-size : cover; /* Propriété CSS 3 qui permet de redimensionner l'image d'arrière plan à la taille de son conteneur */
}

> Voir l'inclusion via CSS

On peut même aller jusqu'à imaginer des arrières plans animés (attention à l'accessibilité quand même) en mixant SVG et la balise HTML 5 video. Bref, en utilisant conjointement ces 3 technologies, on peut vraiment faire beaucoup de choses.

La problématique d'implémentation est la même qu'avec la balise img, et le support navigateurs est le même.

L'utilisation de la balise `object`

La balise object est faite pour embarquer à peu près n'importe quoi dans une page Web. Historiquement, cette méthode est utilisée pour SVG car il est possible de faire appel à un plugin tiers pour afficher un document SVG. Cette nécessité disparaît avec les navigateurs qui supportent nativement ce format d'image. Vous pouvez néanmoins toujours utiliser cette façon d'embarquer du SVG. Le gros avantage de cette méthode, c'est que vous pouvez gérer très facilement l'alternative HTML à fournir en cas d'absence du support de SVG

<object type="image/svg+xml" data="http://jeremie.patonnier.net/post/2010/06/29/cercle.svg">
    <img src="http://jeremie.patonnier.net/post/2010/06/29/cercle.png" alt="Votre navigateur ne supporte pas le format SVG !" />
</object>

> Voir l'inclusion via object

Quand tout le reste a échoué, il reste les `iframe` !

Si vous utilisez un navigateur qui comprend SVG mais qui ne comprend aucune des autres méthodes vues ci-avant (!!), vous avez toujours la possibilité d'utiliser une iframe... avec tous les problèmes inhérents à une gestion de frame. Franchement, si je vous parle de cette méthode ici, c'est par honnêteté intellectuelle, mais je vous encourage à considérer cette méthode comme la technique de "la dernière chance".

> Voir l'inclusion via iframe

Qu'est-ce qu'on peut faire avec ce langage ?

Maintenant que je vous ai montré comment utiliser SVG dans vos documents HTML, on peut se concentrer sur son utilité réelle

Dessin

SVG étant avant tout un format d'image vectoriel, vous pouvez donc dessiner des formes : Des formes simples comme des lignes (lignes droites avec line ou lignes brisées avec polyline), des polyèdres (des rectangles ou carrés avec rect ou des polygones avec polygon), des ellipses (des cercles avec circle ou des ellipses arbitraires avec ellipse) ou des formes totalement arbitraires avec la balises path.

Il est possible d'appliquer des styles CSS à ces formes (via la balise style). SVG enrichie les propriétés issues de la norme CSS 2 avec des propriétés qui lui sont propre, en particulier pour gérer le style des lignes (propriétés stroke-*) et du remplissage des formes (propriétés fill-*)

On peut également embarquer des images bitmap dans un document SVG (via la balise image)

Enfin, tous ces éléments peuvent être groupés entre eux pour constituer des ensembles de formes cohérents (et donc plus facile à manipuler de manière globale) en utilisant la balise g et vous pouvez les dupliquer et les réutiliser à l'infini avec la balise use.

Filtres et transformation

Transformations

Un des grands intérêts des formes vectorielles, c'est qu'il est possible d'y appliquer des transformations sans perte de qualité. En effet, un tracé vectoriel est défini par un certain nombre de points clés dans un espace de coordonnées (contrairement aux images bitmap qui définissent tous les points du tracé de manière exhaustive et absolue). Il est donc très facile de déplacer ces points dans cet espace de coordonnées via de "simples" transformations mathématiques.

En SVG les transformations s'appliquent via l'attribut transform utilisable par toutes les balises. On peut appliquer autant de propriétés de transformations que l'on veut à un tracé, il suffit de séparer chacune d'elles par une virgule ou un espace. Vous avez à disposition, soit des transformations simples : déplacements (propriété tranlate), rotations (propriété rotate), déformations (changement d'échelle avec scale et inclinaison avec skewX et skewY) ; soit des transformation matricielles arbitraires (via la propriété matrix).

Par exemple, si vous voulez créer un losange, dessinez un carré et appliquez lui une rotation de 45° et une déformation verticalle :

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" 
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">

<svg width="100" height="100" version="1.1"
 xmlns="http://www.w3.org/2000/svg">

    <rect x="25" y="25" width="50" height="50"
          transform="translate(50 12.5) scale(1 0.5) rotate(45)" />

</svg>

> Les transformations en action

Dans l'exemple précédent, notez que les transformation s'appliquent de la droite vers la gauche (d'abord la rotation, puis le changement d'échelle puis le déplacement). La transformation translate supplémentaire permet de replacer le losange au centre de la zone de dessin. Je ne vous détaillerai pas ici la gestion du système de coordonnées dans SVG, c'est assez compliqué et nécessiterait un article à part entière. Souvenez vous juste que c'est un point auquel vous devrez porter beaucoup d'attention dès que vous allez vouloir jouer avec les transformations.

Filtres

Les filtres sont un mécanisme qui permet d'appliquer des effets spéciaux à tout ou partie d'un document SVG. En effet, dans le cadre d'un dessin vectoriel, les courbes et les formes ne font pas tout. Les filtres permettent de créer des effets de flou (feGaussianBlur), de lumière (feSpecularLighting, feDiffuseLighting, etc.), de mélange d'image (feBlend, feComposite, etc.), d'application de texture (feTurbulence), etc.

Ces effets de bases peuvent êtres combinés au sein de la balise filter et chaînés entre eux pour créer des filtres complexes. Une fois un filtre défini, il est appliqué à un élément grâce à l'attribut filter. Oui, vous avez bien lu, il y a une balise ET un attribut filter. Plutôt qu'une explication fastidieuse, voici un exemple ou un simple cercle noir est mis en relief :

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
 "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" 
     xmlns="http://www.w3.org/2000/svg" 
     xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
     width="100" height="100">

    <defs>
        <filter id="MonFiltre" filterUnits="userSpaceOnUse" x="0" y="0" width="200" height="120">
            <!-- On floute l'objet source -->
            <feGaussianBlur in="SourceAlpha" stdDeviation="5" result="flou"/>
            <!-- On décale le résultat du flou qu'on appellera "Ombre" -->
            <feOffset in="flou" dx="3" dy="3" result="Ombre"/>
            
            <!-- On crée une source de lumière spéculaire avec un point d'éclairage en haut à gauche -->
            <feSpecularLighting in="flou" surfaceScale="10" specularConstant=".75" 
                                specularExponent="1" lighting-color="#EFEFEF"  
                                result="speculaireSortie">
                <fePointLight x="-5000" y="-10000" z="2000"/>
            </feSpecularLighting>
            
            <!-- on applique la source de lumière à l'objet source -->
            <feComposite in="speculaireSortie" in2="SourceAlpha" operator="in" result="speculaireSortie"/>
            <!-- On mélange le résultat de la lumière sur l'objet source avec l'objet source lui même -->
            <feComposite in="SourceGraphic" in2="speculaireSortie" operator="arithmetic" 
                         k1="0" k2="1" k3="1" k4="0" result="SourceEclairee"/>

            <!-- On empile l'objet éclairé avec son ombre pour obtenir le résultat final -->
            <feMerge>
                <!-- d'abord l'ombre... -->
                <feMergeNode in="Ombre"/>
                <!-- ...puis l'objet éclairé par dessus -->
                <feMergeNode in="SourceEclairee"/>
            </feMerge>
        </filter>
    </defs>

    <!-- le filtre est appliqué au cercle qui gagne une ombre et prend du volume -->
    <circle style="fill:#000" filter="url(#MonFiltre)" cx="50" cy="50" r="40"/>
</svg>

> Les filtres en action

Animation, Scripting et gestion évènementielle

Dessiner, c'est bien. Rendre interactif, c'est mieux, surtout quand on parle de Web

SVG étant un format XML, il est possible de le manipuler via le DOM. L'accès au DOM se fait via un langage de scripting. Dans la plus part des cas, c'est le Javascript qui est utilisé (sa version normalisé ECMAScript pour être exact qui est le langage utilisé par défaut dans la norme SVG), mais rien n'empêche d'imaginer utiliser d'autres langages comme Pyton ou VBScript par exemple. En fait cela dépend du logiciel que vous utiliserez pour visionner votre document SVG or dans un navigateur, assez naturellement, on se tournera vers Javascript. L'ajout de script se fait comme en HTML via la balise script.

SVG se conforme à la norme DOM pour la gestion des évènements, mais comme pour les styles CSS, il l'enrichie de certains évènements qui lui son propre. Par exemple, SVGZoom qui permet de savoir quand un changement de taille d'image à lieu ou SVGScroll qui permet de savoir quand est-ce qu'une vue d'un document est déplacée au sein même de la zone d'affichage du document SVG.

Enfin, dernier point important, il est possible d'animer des objets SVG de manière déclarative (sans utiliser de langage de script). Pour cela, SVG se repose sur un autre langage, le SMIL. Là encore, un bon exemple valant mieux qu'un long discours, voila un exemple où une flèche tourne en rond en suivant un tracé (oui, j'aurai pu faire un truc plus sexy, mais au moins ça reste compréhensible) :

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20010904//EN" 
 "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">
<svg width="200" height="200"
     xmlns="http://www.w3.org/2000/svg"
     xmlns:xlink="http://www.w3.org/1999/xlink">
    
    <defs>
        <!-- On définie le tracé du mouvement : un cercle mais sans utiliser la balise circle -->
        <path id="trace" d="M100,50 a50,50 0 1,0 1,0 z" />
    </defs>

    <!-- On dessine le contour du tracé de mouvement en réutilisant le tracé. -->
    <use xlink:href="http://jeremie.patonnier.net/post/2010/06/29/#trace" fill="none" stroke="grey" stroke-width="1px" />

    <!-- Voici un triangle qui se déplacera sur le tracé de mouvement. -->
    <path d="m0,0 l0,6 l20,-6 l-20,-6 z"
          fill="yellow" stroke="red" stroke-width="2px"  >

        <!-- Définition de l'animation sur le tracé de mouvement -->
        <animateMotion dur="6s" rotate="auto" repeatCount="indefinite">
            <mpath xlink:href="http://jeremie.patonnier.net/post/2010/06/29/#trace" />
        </animateMotion>
    </path>
</svg>

> Voir l'animation en action

Des logiciels pour se simplifier la vie

Même s'il n'est pas très compliqué d'éditer un document SVG à la main, il vous faudra passer par des logiciels d'édition SVG si vous voulez faire des choses vraiment sexy au niveau design. Les principaux logiciels de dessin vectoriel du marché permettent à minima de produire des dessins statiques au format SVG. Par contre il est assez difficile de trouver des logiciels permettant d'exploiter les fonctions avancées de SVG comme l'animation ou l'interactivité via des scripts (à mon avis, c'est sans doute le principal frein à un déploiement massif de SVG). D'ailleurs sur ce point, si on compare à Flash... il n'existe pas d'équivalent au Adobe Flash IDE pour travailler avec SVG.

Inkscape
Il s'agit d'un éditeur de dessin vectoriel libre et gratuit. Le SVG produit est de bonne qualité, même s'il faut un peu se méfier des options d'enregistrement si on veut éviter une soupe de tag un peu indigeste. Les filtres sont relativement bien supportés (l'éditeur de filtres est assez intuitif). Par contre, il ne gère pas (encore) les animations ni le scripting. Il a l'ambition de supporter l'intégralité de la norme SVG 1.1 pour la sortie de sa version 1 (mais on n'y est pas encore).
Adobe Illustrator
Un des logiciels historique de Adobe. Sa qualité en temps qu'éditeur vectoriel n'est plus à faire. L'exportation en SVG est d'excellente qualité. Les filtres sont parfaitement supportés mais leur édition est franchement mauvaise (édition en mode texte). Cela tiens au fait que Illustrator n'utilise pas SVG comme format natif et qu'il ne fait que de l'import/export à ce format. Ainsi, si vous utilisez certaines fonctionnalités ou filtres spécifiques à Illustrator, vous risquez d'avoir quelques surprises. Prenez le temps d'expérimenter. Il ne gère ni le scripting ni les animations.
Aviary.com (Raven)
La suite d'outils en ligne du site aviary.com propose un éditeur vectoriel appelé Raven. Cette éditeur exclusivement en ligne est assez frustre et ne permet que de faire du dessin. Il ne supporte ni les filtres, ni le scripting, ni les animations.
Amaya
Il s'agit de l'éditeur/navigateur développé par le W3C et l'INRIA. Il supporte la plupart des langages normalisés par le W3C, dont le SVG. Bien que son ergonomie soit douteuse à mon sens, c'est un des très rare (si ce n'est le seul) éditeur SVG qui gère les animations déclaratives.

Il existe également un certains nombre de bibliothèques Javascript qui offrent un haut degré d'abstraction, comme par exemple RaphaelJS ou SVGWeb, pour créer et manipuler un documents SVG plus facilement qu'en utilisant directement les fonctions DOM. Elles permettent souvent de contourner les limites des différents navigateurs (en simulant le support de SVG dans IE ou en rajoutant le support des animations dans Firefox 3.6 par exemple).

Conclusion

Voila pour un petit tour d'horizon rapide de cette technologie. Le couple SVG / HTML5 offre des opportunités graphiques sans précédent dans le web standard. Comme toutes les technologies web, SVG n'est pas très compliqué au premier abord mais regorge de subtilités dès qu'on se met à creuser. Prenez le temps de vous familiariser avec, vous ne devriez pas le regretter

En savoir plus

Pour vous rendre vraiment compte de ce qu'il est possible de faire avec ce langage, allez faire un tour sur SVG Wow!
Mozilla et Opera ont des articles et des démos assez bien détaillés :
- http://hacks.mozilla.org/category/svg
- http://dev.opera.com/articles/svg
Doug Shepers du W3C SVG WG a réalisé un site d'introduction à SVG qui permet de bien démarrer avec ce langage (même si ça date un peu maintenant) : http://svg-whiz.com
Pour savoir exactement quelle fonctionnalité est supportée par quel navigateur, Jeff Schiller maintient une grille exhaustive : http://www.codedread.com/svg-support.php
Enfin, rien ne vaut un plongeon dans la norme pour s'auto-former (elle comporte de nombreux exemple très compréhensibles) :
- En anglais : http://www.w3.org/TR/SVG/
- En français : http://www.yoyodesign.org/doc/w3c/svg1/ (pas tout à fait à jour, mais ça aide)

Améliorez vos liens avec la génération de contenu CSS

Jeremie — Wed, 23 Jun 2010 14:19:00 +0200

Les liens hypertextes sont la colonne vertébrale du Web. La plus part du temps, ils se résument à un texte graphiquement mis en évidence (historiquement, bleu et souligné). Néanmoins, techniquement et sémantiquement parlant, les liens peuvent bénéficier de méta-données qui offrent un certain nombre d'informations qui pourraient être utile à l'utilisateur mais ne sont pas mises en évidence par les navigateurs. Par exemple, l'attribut target permet de définir dans quel fenêtre ou cadre va s'ouvrir le lien, ou l'attribut hreflang qui permet de connaitre la langue de la page où mène le lien et je ne vous parle même pas de l'attribut rel. Dans cet article je vais vous montrer comment utiliser la génération de contenu CSS pour afficher certaines de ces informations à l'utilisateur.

Le résultat attendu

L'idée est d'afficher au survol d'un lien le contenu de son attribut hreflang et target dans un badge en surimpression. Une image valant mieux qu'un long discourt, voila le résultat attendu :

L'arrière plan des liens

Afin de facilité la lecture du badge et surtout son association visuelle avec le lien, on va attribuer aux liens un arrière plan coloré qui va légèrement déborder de la zone de lecture "normal".

On commence par leurs donner une couleur d'arrière plan au survol :

a:hover{
    background : #CCD;
}

L'effet de débord est réalisé en jouant sur les propriétés padding et margin. L'utilisation de padding va permettre d'élargir la zone visuelle. Malheureusement, cela agrandi aussi réellement la zone occupée par le lien qui va repousser ce qui l'entoure. Pour éviter cet effet, on va attribuer une valeur négative de margin équivalente à chacune des valeurs de padding. Cet artifice permet de donner assez facilement l'illusion d'un élément qui "déborde" tout en étant à sa place naturel dans le flux HTML.

a{
    display : inline-block;

    padding :  0.1em  0.6em;
    margin  : -0.1em -0.6em;
}

Notez que la balise a est une balise de type inline. Cela veux dire que certains navigateurs ne vont pas appliquer (ou seulement partiellement) le padding et le margin à l'élément. Pour corriger cela, vous devez ajouter la propriété display: inline-block. Si vos intitulés de liens sont longs, il faut se poser la question de savoir si on veut réellement réaliser un tel effet graphique. En effet, en cas de retour à la ligne avec une balise inline-block, c'est l'intégralité du contenu de la balise qui passe à la ligne (ce qui peut casser la continuité et la lisibilité de votre texte) et si le contenu continue d'être trop grand pour tenir sur une seule ligne, le retour à la ligne se fera à l'intérieur de la balise inline-block. C'est donc à vous de voir ce que vous voulez faire selon le contexte sachant que l'utilisation de la valeur inline-block est obligatoire avec Internet Explorer 8 lorsque vous voulez créer un contenu généré, positionné de manière absolue (ce qu'on va faire ci-après). Si vous n'utilisez pas cette valeur, le badge s'affichera sous le lien !

Avec le truc du débord que je viens de vous montrer, vous allez constater un effet assez déplaisant. Au survol de votre lien le texte qui précède le lien sera masqué par l'arrière plan alors que le texte qui suit restera visible par dessus l'arrière plan. Vous pouvez régler l'empilement des éléments en jouant avec la propriété z-index. Vous pouvez soit lui donner la valeur -1, mais dans ce cas, les liens vont se retrouver sous les paragraphes et ils ne seront jamais survolés par la souris (vous les voyez, mais en fait ils sont "masqués" par l'élément contenant le texte), soit vous lui donnez la valeur 1 et dans ce cas le lien passera entièrement au dessus du texte qui l'entoure. C'est assez intéressant graphiquement, mais pas forcément très satisfaisant en terme de lisibilité je vous montrerai un peu plus loin comment s'en sortir avec CSS 3.

a{
    position : relative; /* nécessaire pour la bonne application de z-index */
    z-index  : 1;
}

La génération de contenu

Le badge qui contiendra les informations supplémentaires va être créer à la volé au survol d'un lien directement en utilisant CSS. Pour cela, nous allons utiliser le pseudo-élément :after en conjonction avec la propriété content.

Le pseudo élément :after va simuler la présence d'un éléments après le contenu du lien. On appel cela un pseudo élément car ce sélecteur va créer une zone qui va avoir le même comportement qu'un élément HTML traditionnel, exactement comme si vous agissiez sur une balise span. La seul différence, c'est que ce pseudo-élément n'apparait pas dans l'arbre DOM du document. Je vous reparlerai un peu plus loin de ce sujet quand on abordera les questions d'accessibilité. Ce qu'il faut retenir ici c'est que vous allez pouvoir ajouter des styles à un élément sans que vous ayez besoin de rajouter quoi que ce soit dans le balisage HTML de vos liens.

La propriété content, elle, va permettre de rajouter du texte et des images au sein de votre pseudo-éléments. Là encore, rien n'apparait dans l'arbre DOM de votre document HTML.

Nous allons gérer ici quatre cas de figure pour notre badge :

Si l'attribut hreflang est présent, on affichera sont contenu dans notre badge : l'objectif est de dire visuellement à l'internaute quelle est la langue du lien qu'il va ouvrir.
Si l'attribut target est présent et à la valeur _blank, on affichera une icône qui montre l'ouverture d'une nouvelle fenêtre dans notre badge.
Si les deux attributs sont présents, on affichera et la langue et l'icône.
Si aucun des deux attributs n'est présents, on n'affichera pas le badge du tout.

La gestion de ces quatre cas va passer par une utilisation judicieuse du sélecteur d'attribut et de la cascade

a:after{
 /* On masque le badge, mais on utilisera le sélecteur générique pour définir le style global du badge */

    display : none;
}

a[hreflang]:hover:after{
 /* On affiche le contenu de l'attribut hreflang */

    content : attr(hreflang);
    display : block;
}

a[target="_blank"]:hover:after{
 /* Si l'attribut hreflang est définie, on affichera son contenu. S'il n'existe pas, il ne s'affichera pas. Dans tous les cas, on affichera une icône qui matérialise le changement de fenêtre */

    content : attr(hreflang) " " url("external.png");
    display : block;
}

Assez simplement, la fonction attr permet d'extraire le contenu de l'attribut et la fonction url permet d'inclure une image. Notez que dans la déclaration ci-avant, dans le cas ou les deux attributs hreflang et target sont tous les deux définis, c'est la dernière règle CSS qui sera appliquée car elle a, selon les règles de la cascade, le même poids que la règle précédente, mais elle la surcharge du fait de son positionnement dans le code source.

Le positionnement et le design du badge

Maintenant que le contenu du badge est générer il faut lui donner un peu de style (oui, je sais, elle un peu facile celle là :-p )

On va commencer par le sortir du flux en le positionnant de manière absolu et on le fera légèrement déborder en haut et à droite. En suite, on va détailler le minimum syndical graphique : Couleur d'arrière plan, bordures, styles typographiques, marges pour aérer un peu tout ça.

a{
 /* nécessaire pour que le positionnement du badge soit relatif à son lien*/

    position : relative;
}

a:after{
    position : absolute;
    top   : -1.3em;
    right : -1.3em;

 /* L'arrière plan est rouge foncé et le texte blanc */
    background : #009;
    color : #FFF;

 /* On ajoute une bordure blanche de 2 pixels de larges */
    border : 2px solid #FFF;

 /* Le texte est graissé et 1/3 plus petit que le texte du lien. Il est également mis systématiquement en majuscule */
    font : bold 0.6em Verdana, Helvetica, Arial, sans-serif;

    text-transform : uppercase;

 /* L'ajout de marge permet de laisser le texte respirer */
    padding : 0.4em 0.5em;
}

CSS 3 is sexy !

Voila ! Avec ce que vous venez de voir, vous avez fait tous ce qu'il est possible de faire simplement avec CSS 2. Cependant, on n'est pas encore au résultat attendu. On va donc rajouter une petite touche de CSS 3 pour rendre ça plus fin, plus youpi-tralala, plus waow !

Couleur transparentes

Actuellement, l'arrière plan de nos liens est opaque au survol, ce qui fait qu'on masque une partie du texte à cause de l'effet de "débord" de l'arrière plan. En utilisant une couleur semi-transparente on peut atténuer ce problème. pour cela, il suffit d'utiliser la notation rgba définie dans le module "Border & Background" de CSS 3.

a:hover{
    background : #CCD;
    background : rgba(128, 128, 160, .4);
}

Notez dans l'exemple ci-avant que la propriété background est déclarée deux fois. C'est normal. En effet, de cette manière si un navigateur ne comprend pas la notation rgba (IE8 par exemple), il ignorera la déclaration inconnu et se rabattra sur la déclaration précédente qui respecte la norme CSS 2. Le mécanisme qui consiste à ignorer une déclaration de style inconnue ou mal formée est un comportement standard. C'est une façon simple de gérer les capacités des navigateurs sans avoir à recourir à des artifices comme Modernizr.

Une autre solution pour régler ce problème de sur-impression consisterai à appliquer un z-index négatif au lien et à utiliser la propriété css pointer-events définie par SVG. Néanmoins, cette solution est plus lourde à mettre en œuvre (il faut appliquer au conteneur de chaque lien la valeur none et réapliquer la valeur auto à tous les liens). A noter que seul Firefox, Chrome et Safari supportent la propriété pointer-events sur les éléments HTML (je n'ai pas eu l'occasion de tester avec IE9, mais IE8 et Opera 10.53 ne la supportent pas).

Bords arrondis

Pour adoucir un peu l'effet on va rajouter des bords arrondis aux liens et aux badges

a:hover{
    -moz-border-radius : 1.3em;
 -webkit-border-radius : 1.3em;
         border-radius : 1.3em;
}

a:after{
    -moz-border-radius : 50%;
 -webkit-border-radius : 1.3em;
         border-radius : 1.3em;
}

Comme souvent avec les propriété issu de CSS3, vous aller devoir faire plusieurs déclarations. En effet, peu de modules ont atteint le statut de Candidate Recommendation au W3C, or, c'est seulement à partir de ce statut que les constructeurs peuvent retirer leur préfixe spécifique aux propriétés qu'ils ont implémenté. le module Border & Background a atteint ce statut et tous les constructeurs sont d'accord pour dire qu'en ce qui concerne la propriété border-radius, il est plus que temps de retirer ce préfixe. Opera 10.53 supporte déjà cette propriété sans préfixe et les futures IE9 et Firefox 4 (en cour de discussion) devraient aussi la supporter sans préfixe.

Notez que pour le badge, avec Firefox, j'ai utilisé la valeur 50%. Cette valeur permet de créer des demi-cercles parfaits aux extrémités gauche et droite. Néanmoins, c'est un comportement spécifique à Firefox et mes tests ont montrés que certaines implémentations de Webkit (Chrome 5 par exemple) ainsi qu'Opera ne supporte par les pourcentages avec cette propriété. En outre, de ce que je comprend de la spécification, cette déclaration devrait produire une boite ovale plutôt que deux demi cercle réparti de part et d'autre de la boite, donc, pour la propriété standard, j'ai préféré mettre également une valeur absolue.

Ombres et lumières

Notre badge commence à être pas mal, on va le finaliser en lui donnant un peu de relief avec des effets d'ombres et de lumières.

a:after{
    background : #900;
    background : -moz-radial-gradient(35% 35% 0deg, ellipse cover, #E00 0%, #800, 90%);
    background :      radial-gradient(35% 35% 0deg, ellipse cover, #E00 0%, #800, 90%);

 -webkit-box-shadow : rgba(0, 0, 0, .8) 0 2px 5px;

    -moz-box-shadow : rgba(0, 0, 0, .8) 0 2px 5px,
                      rgba(255, 247, 0, .9) 0 0 3px inset;

         box-shadow : rgba(0, 0, 0, .8) 0 2px 5px,
                      rgba(255, 247, 0, .9) 0 0 3px inset;

}

On commence par ajouter un dégradé radial en arrière plan pour donner l'illusion d'un éclairage venant du haut et de la gauche (positionnement du centre du dégradé à 35% du haut de la boite et à 35% du bord gauche de la boite). Ce dégradé aura la forme d'une ellipse horizontal (0 degrés de rotation) qui couvrira toute la boite. Le dégradé va d'un rouge vif au centre à un rouge sombre prés des bords). La syntaxe des dégradés sous Webkit est très différentes de celle de Gecko et honnêtement je n'y comprend rien donc, tant pis pour Safari et Chrome (faite vous plaisir dans les commentaires si vous avez la solution qui va bien). La syntaxe de Gecko étant celle qui est en cour de standardisation, je reproduit la déclaration sans le préfixe -moz-, mais c'est un parie sur l'avenir. En effet, les dégradés CSS font partie du module "Image Values" qui en est à son tout premier draft. Autant dire que ça peut (va ?) sérieusement bouger.

Ensuite on ajoute une ombre porté qui va permettre de "détacher" le badge de la surface de la page. Cette ombre est décalé de 2 pixels vers le bas et sont rayon de flou est de 5 pixels. Dans la mesure ou tout les navigateurs majeurs du marché qui supportent la propriété box-shadow supportent également les couleurs rgba, on ne va pas s'amuser à gérer une alternative sans couleur transparente (mais on pourrait :-p ).

Comme box-shadow supporte les déclarations multiples séparées par un virgule, on va en profiter pour rajouter une ombre intérieur (mot clé inset). C'est une ombre de couleur jaune pour créer un effet de lumière spéculaire (on aurait pu le faire via le dégradé radial, mais personnellement je trouve ça plus simple via box-shadow). Vous noterez que je n'ai pas appliqué cette deuxième ombre à Webkit. Cela tiens au fait que l'implémentation des ombres internes couplé à l'utilisation de border-radius est une catastrophe sous Chrome 5 et Safari 4 (je n'ai pas eu l'occasion de tester avec Safari 5). En effet, l'ombre reste carré la où la boite est arrondie... horrible !

Attention à l'accessibilité

Voilà, on a créer un jolie badge qui illumine la vie de notre internaute. Mais le loup se cache au coin du bois !

Au royaume des aveugles les borgnes sont rois.

Comme je vous le disait ci-avant, le problème majeur de la génération de contenu via CSS, c'est que ce contenu n'est pas inclus dans le DOM du document HTML. Ainsi, toute les outils d'aide à l'accessibilité qui repose sur le DOM ne pourront pas exploiter ce contenu généré. C'est par exemple le cas des revus d'écran qui vocalisent les pages Web. A ma connaissance, aucune ne prend en charge les contenus généré via CSS. Pour cette raison, il est vivement déconseillé de générer un contenu signifiant à l'aide de CSS. Dans le cas qui nous occupe ici, cette question n'est pas un problème. En effet, il s'agit uniquement d'enrichir l'expérience utilisateur, donc, tant pis pour les aveugles et les personnes utilisant de vieux navigateur (vous voyez de quoi je parle là, n'est-ce pas), ils pourront toujours utiliser les liens tel qu'ils ont l'habitude de les pratiquer, pour les autres, c'est cadeau, c'est bonheur

Les souris, ce fléau de l'humanité !

Vous aurez noté que l'apparition et la disparition du badge sont conditionnées par l'application de la pseudo-classe :hover. Cette pseudo-classe correspond au survol de la souris sur le lien. Pas de bol, certains excentriques utilisent leur clavier, d'autres utilisent des interfaces tactiles (et même si Safari sous iPhone sait s'accommoder de cette pseudo-classe, ce n'est pas le cas de tous le monde) ... pire, votre souris pourrait tomber en panne ! Vous pourriez avoir la même attitude que précédemment et décréter que "tant pis pour ces êtres étranges qui sont mal équipé" et en rester là. C'est toujours possible mais ce serait dommage car il est assez facile de leur offrir la même expérience en étendant légèrement nos sélecteurs CSS en incluant les pseudo-classes :active et :focus.

a[hreflang]:hover:after,
a[hreflang]:active:after,
a[hreflang]:focus:after{
    ...
}

a[target="_blank"]:hover:after,
a[target="_blank"]:active:after,
a[target="_blank"]:focus:after{
    ...
}

Mon royaume pour un cheval.

Certains navigateurs sont comparables à des piétons et d'autres à des calèches grand luxe tractées par au moins 4 chevaux (ce qui sous entend également que même les navigateurs actuels les plus en pointe ont encore un long chemin à parcourir pour pouvoir être comparé à des coupés sport à injection directe !). Vous pouvez bien sur tester ce badge avec votre propre navigateur, et si vous n'avez pas tout un panel de navigateurs à votre disposition, voila quelques exemples de rendus :

Tableau comparatif de quelques rendus navigateurs
Navigateur	OS	Résultat du rendu
IE 6	Windows XP
IE 7	Windows XP
IE 8	Windows XP
IE 9 (Test Drive)	Windows 7
Firefox 3.5	Mac OS Leopard
Firefox 3.6	Windows XP
Firefox 3.7a5	Ubuntu 10.04
Chrome 5	Windows XP
Safari 4	Windows XP
Safari 5	Mac OSX Leopard
Opera 10.53	Windows XP
Opera 10.60 beta	Ubuntu 10.04

Vous noterez que, au delà des dégradations prévisibles (Dégradés, ombre, coins arrondis), c'est le rendu typographique qui diffère le plus d'un OS à l'autre (d'où l'importance d'utiliser des em pour définir la taille des arrondis plutôt que des pixels). Vous noterez également un bug (?) avec IE8 (non, ne levez pas les yeux au ciel !), où le badge est positionné au dessus de l'arrière plan du lien, mais au dessous du texte (!!). Il semblerai que pour l'instant, l'équipe de IE9 ne se soit pas encore penchée sur la gestion des pseudo éléments qui se comportent exactement comme avec IE8.

Conclusion

Comme vous pouvez le voir, il n'est pas très difficile d'enrichir l'expérience des utilisateurs. On est dans un cas typique d'enrichissement progressif. Avec un navigateur ancien, l'utilisateur ne gagne rien, mais il ne perd rien non plus. Avec un navigateur moderne, il gagne en confort. Personne n'est lésé, tout le monde est gagnant.

Certes, cela est intéressant pour l'utilisateur, mais cela peut également être intéressant pour vous à titre personnel. En effet, rien ne vous empêche d'utiliser cette technique dans la feuille de style utilisateur de votre navigateur préféré pour enrichir votre propre expérience de navigation sur tous les sites sur lesquels vous surfez

Enfin, c'est grâce à ce genre de test qu'on peut remarquer que Webkit n'est pas aussi bon que l'affirme Apple et Google en terme de support de CSS3 (quand il ne font pas un honteux amalgame avec HTML5). Je ne parle pas des dégradés radiaux (là, c'est moi qui fait volontairement l'impasse) mais plutôt du support de box-shadow couplé à border-radius qui est loin de ce que propose les dernières versions de Gecko. Bon soyons claire, il ne sert à rien de se lancer dans un pinaillage du genre "Ah oui mais Webkit supporte mieux tel truc que Gecko". Ce que je veux vous dire, c'est qu'il ne faut pas prendre pour argent comptant ce que racontent les constructeurs de navigateurs. Testez, testez et testez encore ! Il n'y a que ça pour vous permettre de savoir ce qui marche dans les cas qui vous intéressent.

@media London 2010 : Day 4

Jeremie — Fri, 11 Jun 2010 21:28:00 +0200

Quatrième et dernier jour à Londres. Programme toujours aussi intense pour cette dernière journée avec encore six conférences de prévus. Heureusement, cette fois-ci les choix ont été un peu moins dure à faire.

La conférence d'ouverture est assuré par Andy Clark (« Hardboiled web design »). Andy est un vraie show-man et il joue sur un parallèle entre le web design et le roman noir pour expliquer que les web designer sont comme des détectives inflexible : il doivent faire face à des conventions et des idées préconçus pour atteindre leur but : ex. « CSS3 n'est pas encore disponible dans IE » ce à quoi il répond « Oui, et alors ? ». Assez ironiquement, ce n'est pas un problème nouveau dans le web design. En effet, les théories de l'enrichissement progressif et de la dégradation harmonieuse date du début des années 2000 avec l'arrivée de CSS 2... étonnement les discourt étaient les mêmes à l'époque. Pour moi qui travail dans le Web depuis plus de 10 ans, ce n'est pas nouveau, mais c'est quelques choses qui doit être répéter encore et encore, surtout pour tous les jeune qui ne connaisse le Web que depuis quelques années (moins de 5 ans environ). Andy est un fervent partisan (pour ne pas dire un fanatique) de la logique de dégradation harmonieuse. C'est d'autant plus important que chaque navigateur à des capacité différentes et qu'il est impossible de fournir un design ou une expérience utilisateur exactement identique avec tous les navigateurs... il faut savoir lâcher prise pour ce concentrer sur l'important : l'utilisateur et l'accès qu'on lui donne à un service.

Au delà des différences entre navigateurs, le mode de construction de CSS3 est très particulier. En effet, CSS3 est composé de modules et rien ne garantie que les constructeurs de navigateurs acceptent de les implémenter tous, même si tous étaient à l'état de recommandation validé (ce qui en soit n'a rien de sur, après tout, CSS 2.1 n'est pas encore une recommandation du W3C, mais seulement un recommandation « proposée »). Globalement, cette présentation est une version concentré de l'atelier du premier jours.

Pour la deuxième conférence, il y avait le choix entre Matt Biddulph (« Mobile social location ») et Sandi Wassmer (« Inclusive design is for everyone »). Les deux sujets ne m'inspire pas plus que ça... bon, j'irai voir Sandi.

Avant de rentrer dans le vif du sujet, Sandi commence par faire le distinguo entre Design et Art. La différence principale résidant dans l'aspect « utile/utilisable » explicite du Design. Un bon design a des objectif claire et suit un certain nombres de principes dont elle détaillera quelques uns mais sans trop insister. Plus spécifiquement, les designs inclusifs sont des designs qui sont prévus pour tenir compte de tous les utilisateurs, quelque soit les capacités et handicaps de chacun... et ce n'est pas seulement une question d'accessibilité. Globalement, cette conférence insiste sur le fait qu'un bon Design est avant tout orienté utilisateur (c'est un peu le leitmotive de toutes les conférences : pensez à l'utilisateur avant tout, c'est tout bénéfice pour vous), que ce soit au niveau du look & feel ou au niveau de l'architecture de l'information... rien de vraiment neuf sous le soleil. C'est peut être parce que ce sont de notions que je connais déjà, mais ça me donne l'impression d'enfoncer des portes ouverte. J'en ressort vaguement dessus.

Troisième conférence, cette fois avec au choix : Hannah Donovan (« Telling Stories through design ») ou Patrick H. Lauke (« Brave New World of HTML5 ») en remplacement de Bruce Lawson. C'est mon coté geek qui l'emporte, en avant pour HTML 5.

Cette conférence est une revue de détail de ce qu'il est possible d'utiliser aujourd'hui en provenance de la future norme HTML5. Avant toute chose, Patrick commence par débroussailler tous le bruit qu'il y a autour du mot « HTML 5 » qui a tendance à devenir un « buzz word ». Il fait un petit passage historique avec l'initiative WATH-WG, l'abandon de XHTML 2.0 et la réintroduction du projet WebForms au sein du W3C qui donnera le HTML 5.

A bien des égards HTML5 entre en compétition avec Flash et Silverlight, mais essentiellement à un niveau peu perceptible par les utilisateurs et n'a pas vocation à les remplacer mais plutôt à les compléter en donnant aux développeurs la possibilité de choisir la technologie qu'ils veulent selon le contexte d'utilisation. Fondamentalement HTML5 est une simple évolution de HTML4 qui standardise un grand nombre de comportement liée au fonctionnement interne des navigateurs. Cela fait de HTML un langage à la fois plus strict (le comportement de tous les navigateurs sera unifié) et plus permissif (la syntaxe reste très, très souple... trop dirons certains). HTML5 rajoute également un certains nombre de nouvelles balises et un certains nombre de nouvelles API pour Javascript. Une des fonctionnalités les plus attendu est sans doute tout ce qui touche à la gestion des formulaires et en particulier à la validation du contenue de formulaire sans avoir recourt à Javascript. Patrick parle aussi évidement de la gestion de la video et de l'audio (LA fonctionnalité qui fait le buzz autour de HTML5 !), de la balise canvas (une zone de dessin accessible directement via Javascript mais attention au problèmes d'accessibilités, il insistera sur ce dernier point). La encore, je n'ai rien appris de neuf, mais Patrick est un excellent orateur qui sait communiquer son enthousiasme (il n'est pas Tech Evangeliste chez Opera pour rien ).

Pendant la pause déjeuner, une discussion s'improvise entre Andy Clark est une cinquantaine (!?) de personnes sur la difficulté qu'il y a à expliquer aux clients que le rendu d'un site web peut être parfois très, très différent d'un navigateur à l'autre. Gros débat qui ne trouvera pas sa conclusion aujourd'hui, mais va très certainement se continuer en ligne dans les semaines qui arrivent (à suivre sur @malarkey)

L'après midi-débute avec la quatrième conférence. Tant pis pour Relly Annett-Baker (« All the small things »), mais je vais voir Remy Sharp (« Browser with wings: HTML 5 API ») histoire de compléter la conférence du matin.

Comme lors de la conférence de Patrick Lauke, Remy commence par démonter le hype autour de HTML 5, pour ensuite s'attacher au cœur du sujet : les nouvelles API introduites par HTML5 pour Javascript :

D'abords les médias avec la gestion de la video et de l'audio. Les API associés permettent de contrôler le fonctionnement de ces éléments ce qui permet de créer des contrôles personnalisés.
Canvas qui est une zone de dessin vierge qui n'a de sens qu'avec son API de dessin qui permet de dessiner n'importe quoi dans un contexte 2D (le dessin dans un contexte 3D est encore hyper expérimental, en particulier au travers de l'API WebGL, mais devrait voir le jour très prochainement, Chrome et Firefox y travail dure) et d'exporter le résultat.
Les API de stockage qui permettent de stocker des données localement sous forme de paire clé / valeur. Ce stockage peut être permanent ou limité dans le temps (pour la durée de la session utilisateur par exemple). Il est aussi possible d'aller plus loin avec les API SQL qui repose sur l'utilisation d'une base de données SQL dans le navigateur, en l'occurrence IndexDB.
L'API de géolocalisation permet elle d'accéder à la position géographique de l'utilisateur (s'il le souhaite).
Les Web Socket permet de gérer un flux de donnée binaire permanent, montant et descendant entre le navigateur et le serveur (cette API, en dehors de son support dans les navigateurs à aussi besoin de bénéficier de serveurs capables de gérer de tels flux) ce qui permet d'implémenter à peut près n'importe quel protocole de haut niveau (XMPP par exemple) en Javascript.
La gestion de la mise Offline permet de de savoir quand un navigateur est déconnecté et de proposer des actions dont le résultat ne sera réellement exécuté qu'une fois le navigateur reconnecté (par exemple avec un webmail). Il est également possible de gérer assez finement le cache des éléments nécessaires à l'application grâce au manifeste de cache.
Enfin, L'API de fichiers permet d'accéder au système de fichier local du navigateur.

Bien que HTML5 soit encore en cours de normalisation (tous les navigateurs n'ont pas encore implémenté toutes ces API ou pas forcement exactement de la même façon) on peut déjà commencer à utiliser ce qui existe. Certes avec prudence, mais c'est possible, en particulier avec toutes les solution de substitution et de contournement qui existent.

L'avant dernière conférence (déjà !?) offre le choix entre Aral Balkan (« The art of emotional design ») et Steve Souders (« Even faster web sites »). Depuis le temps que j'entend parler de Steve, impossible de manquer ça. Aller hop !

Steve revient sur la question des performances coté client. Il ne s'étend pas trop sur les méthodes et l'outillage, il se contente de nous montrer rapidement les différences et points communs existant entre Yslow et PageSpeed. En effet, l'essentiel de sa présentation tourne autour de tests réalisé par Google (Steve travail pour Google) qui permettent de mettre en évidence les amélioration de performances mises en œuvre par les différents éditeurs de services en lignes. On voit bien à quel point les développeurs ont pris conscience de l'importance des performances au sein du navigateur (tout ce qui touche au chargement et à l'exécution du code par les navigateurs). Il nous parle d'ailleurs de l'émergence d'un nouveau métier : le WPO (Web Performance Optimisation) qui est au développement ce que le SEO est au marketing web.

La conférence de clôture sera assuré par Scott Berkun (« The myths of innovation, remixed and remastered »). Cette conférence assez théorique nous fait rentrer dans les mécanismes qui président à l'innovation et comment celle-ci est possible... on pourrait résumé sa pensé par l'expression « 100 fois sur le métier tu remettras ton ouvrage ».

Ce fut dense et de très haut niveau. Globalement les orateurs sont excellents et même si je n'ai pas appris grand chose sur HTML 5, les rencontres faites sur place ont été particulièrement enrichissante. L'organisation était au top. Si vous hésitez, je vous invite vivement à assister à la prochaine édition et entre temps, Paris-Web vous tend les bras au mois d'octobre

@media London 2010 : Day 3

Jeremie — Fri, 11 Jun 2010 01:03:00 +0200

Troisième jour à Londres. Aujourd'hui, fini les ateliers, c'est le débuts des conférences. Le programmes est dense et le choix de chaque conférence a été difficile. L'évènement à lieu au Hall Queen Elizabeth à proximité de la gare de Waterloo. Le lieu est bien choisi, et malgré la présence d'au moins 300 participants, on ne se sent ni à l'étroit ni perdu au milieu du vide. La qualité de l'accueil est impeccable, mais ce qui compte vraiment ce sont les conférences

Démarrage à l'américaine à 9h avec une courte introduction par john Allsopp qui plaisante un peu sur les australiens pour expliquer que @media est maintenant organisé par Web Direction qui est une entreprise australienne.

On enchaine directement par la première conférence : Brendan Eich (directeur technique de Mozilla Corporation) sur l'évolution de Javascript, langage dont il est à l'origine. Une session ultra technique (au réveil, ça fait mal), mais passionnante sur les prochaines évolutions de Javascript. Javascript est un langage à la fois très simple et très complexe avec beaucoup de subtilité. De gros travaux sont actuellement fait pour le rendre plus structuré et plus fiable, on à droit à une revue de détail, code à l'appuie.

Pour la deuxième conférence on à le choix entre il faut choisir entre Christian Crumlish (« Designing for play ») et Doug Schepers (« SVG today and tomorrow »). Dans la mesure ou j'ai déjà passé une journée avec Christian, je choisie d'aller voir Doug (et puis j'adore SVG, je suis en train de vous préparer un petit article sur le sujet).

La conférence démarre sur les chapeaux de roues, en effet, tous ses slides sont en SVG et on commence directement par une demo tiré du site SVG Wow! Plus prosaïquement, Doug nous présente tous ce qu'il est possible de faire avec SVG (découpes, filtres, animations, etc... je suis en train de préparer un article sur la question). C'est un grand tour d'horizon du sujet, exemple à l'appuis. Franchement je suis certain qu'avec la sortie de IE9, cette technologie va décoller de manière intensive. Pour mémoire, SVG est un format d'image vectoriel. D'ailleurs, Doug fait également le parallèle avec l'élément Canevas en montrant les différences entre ces deux technologie et comment elles se complètent. Il conclus en évoquant rapidement les outils qui permettent de créer des document SVG... et c'est sans doute là que se jouera l'avenir de ce format car pour l'instant, ce n'est pas très reluisant.

La troisième conférence met en compétition Rachel Andrew (« Core CSS3 ») et John "jQuery" Resig (« Testing mobile web apps »). Comme je maitrise déjà bien le sujet CSS3, pas d'hésitation, direction la conférence de John.

Le développement d'application web utilisant Javacript est de plus en plus communs, mais l'univers des mobiles est extrêmement hétérogène. John nous présente la démarche qu'il a suivit pour tester la prochaine version de jQuery sur les plateforme mobile. En effet, en temps que principal développeur de jQuery, il fait en sorte de s'assurer que ce Framework peut fonctionner sur les plateforme mobile les plus importantes. Une des principales difficultés et d'arriver à trouver des statistiques pertinentes pour savoir quoi faire et à qu'elle plateforme s'intéresser (en l'occurance : Symbian, iPhone OS, RIM et Androïd). Basiquement la stratégie de test à avoir est la même que pour les environnements de bureau (via une logique de qualification tel que celle utilisé par Yahoo!), mais la différence tiens au nombre de plateformes et de navigateurs bien plus important. Pour pouvoir faire des tests, les simulateurs (parfois difficiles à se procurer) sont un bon début pour réaliser un certain nombre de test automatique, mais il est toujours nécessaire de faire un test sur un support physique pour valider les partis-pris mis en œuvre. Au final on reste un peu sur sa faim car on ne découvre pas grand choses sur les résultats concret de ce travail. Par contre on ressort avec une vision assez claire de l'état de l'art des environnements mobiles, ce qui n'est pas rien.

Quatrième conférence de la journée, et cette fois ci, il faut choisir entre Tom Hughes-Croucher (« Introduction to server-side Javascript ») et Simon Willison (« Building crowdsourcing applications »). L'utilisation de Javascript coté serveur, même si c'est un sujet passionnant, n'est pas exactement ma tasse de thé. Je préfère donc aller voir Simon pour comprendre ce qu'il entend exactement quand il parle de « crowdsourcing ».

Simon commence donc par essayer de définir le termes « crowsourcing ». C'est essentiellement un buzz word comme a put l'être l'expression « Web 2.0 ». Il s'agit d'ailleurs de notions assez proches. L'expression « Intelligence collective » ne traine pas loin, mais n'est finalement pas utilisé. En fait, plutot que de s'essayer à une définition hasardeuse, il préfère utiliser des exemples pour définir le terme : wikipedia, openStreetMap, Google Image Labeler, Mapumental, XKCD.

Il rentre ensuite dans le détaille de ce qu'il à fait pour le site Internet du Guardian. Ils ont proposés aux visiteurs d'analyser, trier et voter pour les documents liés aux dépenses des parlementaires Anglais pour savoir sur quels sujets il fallait aller investiguer. Cette expérience a été faite deux fois ce qui à permis de l'améliorer à chaque fois en se reposant à la fois sur les mesures d'utilisation et sur les retour d'utilisateurs. Une conclusion intéressante fut de dire que finalement, peut importe qu'une expérience de crowdsourcing fonctionne ou non, il y a toujours quelque chose à en tirer.

On arrive à l'avant dernière conférence, et il faut encore choisir. Soit Mark Boulton (« Designing grid systems ») soit Jonathan Stark (« Building mobile apps »). Je préfère finalement aller voir Mark qui propose une conférence un peu plus généraliste sur un sujet assez chaud dans le milieu du webdesign : l'utilisation des grilles de mise en page.

Ça démarre assez lentement sur des considérations très théoriques, on pare de très loin, avec un passage historique par le gestion des container de fret maritime jusqu'au théorie canon de l'impression papier pour enfin commencer à arriver à parler de web (enfin bon, plus 20 minute pour en arriver là... ce fut très, très long pour pas grand chose). Enfin dans le vif du sujet, on en revient à la question essentielle : le web est un média à part entière avec ses propre règles graphiques. Il faut arriver à se détacher des maquettes Photoshop fixe pour arriver capturer l'essence du Web : la flexibilité. 3 notions sont en jeux : la notion de grille de mise en page flexible (pas de largeur ni de hauteur prédéterminé), la notion de taille d'image flexible et la notion d'espace visible (« viewport » en anglais). Le problème des supports physiques, c'est qu'ils mélangent la gestion du contenu et sa mise en forme. Le web sépare les deux, ce qui demande un gymnastique intellectuelle complètement nouvelle. Mark finira par détaillé explicitement les type de grilles possibles, mais comme cela arrive en fin de conférence, c'est survolé assez rapidement et on est finalement un peu frustré malgré la qualité de la prestation et de la démarche intellectuel, c'est un peu dommage.

La dernière conférence est une table ronde avec Jeremy Keith, Christian Crumlish, Hannah Donovan, John Allsopp et Simon Willison. Cette dernière partie est un peu décevante dans le sens où l'interaction avec la salle fut réduite à la portion congrue, ce qui donnait la sensation d'assister à une discussion d'expert sans vraiment y participer... sans doute le gros fail de la journée.

En conclusion, ce fut un journée dense avec des orateurs de haut niveau. Et même si la fin de journée fut un peut moins enthousiasmante (la fatigue aidant peut-être aussi), cela n'enlève rien au niveau global de cet événement qui permet de côtoyer certain des meilleurs web designer de la planète. Vivement demain pour la suite.

@media London 2010 : Day 2

Jeremie — Wed, 09 Jun 2010 19:41:00 +0200

Deuxième jours à Londres. Cette fois-ci, j'assiste à l'atelier « Designing Social Interface » conduit par Christian Crumlish (et toujours des photos sur Flickr)

Pour s'échauffer, Christian commence par nous faire un peu de théorie sociale et en particulier de ce que l'on met derrière le mot « Social »... il y a beaucoup plus de choses qu'on ne l'imagine mais basiquement cela revient à avoir des gens qui communiquent entre eux (ne rigolez pas, j'ai dit "basiquement"). Ensuite, Christian rentre dans la différence qu'il peut y avoir entre un utilisateur solitaire et un utilisateur qui interagie avec d'autres utilisateurs. Il définie 3 espaces sociaux : L'espace de l'utilisateur (centré sur lui même), l'espace de ses activités (centrés sur un objet externe), l'espace de ses interactions sociales (centré sur un ou plusieurs autres utilisateurs). La suite de la conférence ne fera que détailler concrètement ces 3 espaces.

On entre à présent dans des choses un peu plus concrètes. Les grandes lignes du design sociale suivent un certain nombre de points connus :

Travailler au service de l'utilisateur, par exemple en fournissant systématiquement des messages humainement compréhensible (en particulier les erreurs)... comme si le site avait une conversation humaine avec l'utilisateur (sans sombrer non plus dans une fausse idée de « robot parlant ») et de manière général en écoutant ses utilisateurs (en balisant les chemins de traverse... « paving the cow path » en anglais, j'adore cette expression).
Le deuxième point reprend un axiome connu des développeurs informatiques : « ne pas réinventer la roue ». Dans la logique social, c'est la même choses. Il est inutile de réinventer Facebook ou Twitter, utilisez les. A tout le moins utilisez des interfaces techniques interopérables avec ce type de services.
s'inspirer de la logique des jeux en en reprenant les grands points : la logique de notation, la logique de feedback, la possibilité d'interaction et de personnalisation
Le respect de la dimension éthique du service

Pour terminer ce premier échange, Christian nous propose un petit exercice pratique en nous demandant de choisir un sujet (un objet social) et de construire une proposition de site autour des principes vus pendant la matinée. Bon c'est un peu brouillon mais rigolo

Pour terminer cette première partie Christian approfondie la question de l'espace utilisateur. Cet espace comprend tous ce qui touche à son activité et son interaction avec le site : Inscription, Identification, Page d'accueil personnalisé, personnalisation du site (carte d'identité, avatar, gestion du profil utilisateur complet), gestion de la visibilité des données personnelles, accès au offres personnalisées, etc. Christian détail aussi la logique de réutilisation et la façon dont les usages d'un utilisateur évolues selon son degrés d'adhésion au service.

On enchaine sur nouvel exercice qui fait le lien avec le précédent. Cette fois, il s'agit de proposer et discuter des meilleurs actions à mener pour offrir un espace utilisateur adapté à l'objet social que nous avions sélectionné précédemment.

La deuxième partie de matinée est consacré à la présence en ligne : microblogging, liste d'amis, etc. Il enchaine sur la question de la réputation qui est un corolaire de la présence en ligne. La réputation se construit au travers des actions que l'on mène au sein d'une communauté. Il existe certains leviers de motivation pour agir et construire sa réputation. Leur mise en scène est souvent très inspiré des techniques ludiques (les jeux quoi :-p) : la collecte de bonus, le gains de points, les classements...

A nouveau on enchaine avec un exercice qui nous permet d'approfondir les différentes techniques sur des cas (quasi) réels.

On termine la matinée et on redémarre l'après-midi sur la question de l'espace des activités sociales. En effet, un site à vocation sociale doit proposer des outils qui permettent d'atteindre ses objectifs : Système d'expression (commentaire, feedback, blog, wiki), de notation, de discussion (chat, forum, murs de discussion), de socialisation (statuts, humeur, flux d'action), de partage (Sauvegarde, Favoris, Tags, recommandations)... un utilisateur doit pouvoir être actif. C'est l'occasion de faire un petit détour par le notion d'intelligence collective, mais pour une fois de manière assez réaliste. En effet, Christian détail bien les différents profil d'utilisateurs, certains très passif (les plus nombreux) et d'autres très actifs (les plus impliqués dans une communauté) avec une possibilité de progression d'un profil à l'autre mais sans garantie.

Et comme le matin, on passe à un exercice pratique de mise en situation.

Suite à cela, on passe à la question de l'espace des interactions sociales. Le cœur d'un système sociale passe par la gestion de la communauté qui le compose. Christian détaille les méthodes permettant à un utilisateur de gérer sa communauté de connaissance (non, pas forcément des amis ) :

La capacité de trouver des gens.
La capacité d'ajouter des gens à sa communauté.
La capacité de catégoriser ses relations avec les membres de sa communauté et de définir ce que l'on partage avec chacun.
La capacité de filtrer les contenus de sa communauté.
La capacité de signaler les abus.
La capacité de créer des liens en dehors du média (organiser des rencontres, se geolocaliser, se retrouver via mobile) et réconcilier le tout (importer/exporter ces informations pour un usage déconnecté).

Au final, la communauté interagie et trouve son propre mode de fonctionnement (définition de normes communes). Les outils mis à sa disposition doivent être là pour faciliter et encourager son développement et celle de l'utilisateur.

Et oui, vous l'aurez deviné, on passe à une mise en pratique de ce point.

Pour finir la journée Christian s'attaque au « Anti-Patterns » sociale, ce qu'on pourrait résumé par : ce qu'il ne faut pas faire.

Imiter quelque chose qu'on n'a pas compris ce qui le rend inutile.
Casser le principe de fonctionnement des e-mail (et plus généralement des différents services d'Internet).
Demander les identifiants d'un services à votre utilisateurs.
Ne pas gérer la fin d'une relation au sein du réseau.
Se donner des grands airs en proposant trop de choses inutiles.

Exercices ? Oui, oui : comment lutter contre les anti-patterns.

En conclusion, même si je pense que cet atelier aurait du s'intituler « Designing Social Websites » à la place de « Design Social Interface », ce fut une excellente journée, très enrichissante. L'équilibre entre théorie et pratique était bon et Christian est un excellent orateur. La matière de cette atelier était tiré de son livre « Designing Social Interfaces » dont le contenu est intégralement disponible en ligne sur le site http://www.designingsocialinterfaces.com

Les slides de l'atelier sont disponibles à cette adresse : http://mediajunkie.com/presos/wdx/DSI-wdx-@media.pdf

@media London 2010 : Day 1

Jeremie — Tue, 08 Jun 2010 22:17:00 +0200

Cette année j'ai pu me rendre à @media (c'est comme Paris Web, mais à Londres et en plus chère ). Ce cycle de conférences comprend 2 jours d'ateliers (1 atelier = 1 journée... autant dire qu'on rentre sérieusement dans le détail) et 2 jours de conférences. Choisir entre les différents ateliers fut une vraie torture, mais finalement, pour le premier jours, j'ai opté pour l'atelier de Andy Clark sur le thème « Advanced CSS styling ».

Les ateliers se tiennent au Goodenough College. Le lieu est superbe et « so british »... une quasi collection de clichés sur ce qu'est une école d'enseignement supérieur anglaise (quelques photo sur Flickr). Un écrin parfait pour un atelier de haut niveau.

En guise d'introduction, Andy commence par nous présenter le processus de standardisation et le jeu permanent qu'il existe entre le W3C et les fabricants de navigateurs. Il en profite pour démystifier le sujet en insistant sur un point clé : la normalisation est faite pour les constructeurs par les constructeurs. Le point de vue des designer est très peu représenté (il n'y a que 2 experts invités dans le groupe de travail CSS) et chaque constructeur suie ses propres contraintes liées à son business model. Pour conclure ce premier round d'échauffement, on a eu droit a un excellent mini débat sur le thème « Un site doit-il être exactement semblable d'un navigateur à l'autre ? »... Je parle d'échauffement car la réponse est évidente et les objections toujours les mêmes. Andy en profite ici pour mettre un coup de griffe aux graphistes qui persistent à présenter des maquettes de sites sous forme d'images figées et encourage tout le monde à présenter des maquettes HTML, même si ce ne sont que de simple « point d'étape » tout en démontrant les bénéfices à travailler dans une logique de dégradation harmonieuse. Il estime que les maquettes fixes sont un problème car elles ne permettent pas d'anticiper certaines contraintes propre au média (par exemple, que ce passe-t-il quand un titre prévus sur une ligne est trop long et passe sur deux ligne ?) et le client étant incapable de faire cette gymnastique mental, il ne comprendra pas pourquoi le design peut évoluer d'un navigateur à l'autre.

Suite à cela, on entre dans le vif du sujet avec une présentation en règles des nouveautés qu'apporte CSS3 en termes de Webdesign. Les principaux points abordés sont :

La gestion de la couleur avec en particulier la syntaxe rgba ;
La gestion des arrières plans avec en particulier les images d'arrière plan multiples (et plus généralement l'utilisation de valeurs multiples sur un certains nombre de propriétés) et la possibilité de gérer finement le positionnement et la taille de ces images ;
Les bordures avec une revue de détail des bords arrondis ;
Les ombres sur le texte et sur les boites de contenu (qui permettent de faire bien plus que de simples ombres portées);
La gestion de la mise en page avec un focus sur le colonage ;
Les transformations 2D et 3D ;
Les transitions.

Toutes ces nouveautés ne sont bien sur pas disponibles avec IE (on en reparlera lorsque IE9 sera là) mais Andy à une position très claire sur la question : Il design pour le navigateur le plus avancé en termes de support de CSS3 (Safari ?) et ensuite il s'assure que la dégradation se fait correctement, quitte à prévoir un design alternatif pour certains navigateurs quand la dégradation est trop importante. Ce qui est important, ce n'est pas le design, mais l'expérience utilisateur. C'est cette expérience qui doit être préservée, pas le design. Et pour Andy, qui est un excellent designer, le design n'est clairement pas l'alpha et l'oméga de l'expérience utilisateur. En particulier, il insiste sur le fait qu'un site peut être vue sur différents navigateurs dans des situations très différentes (un macbook, un iPad et un iPhone n'offrent pas les même conditions d'utilisation... oui, c'est un fan d'Apple ).

Après nous avoir bien alléché avec toute ses possibilités, se pose la question de les mettre en œuvre. Comme on a pris un peu de retard sur le programme, il se contentera d'évoquer quelques scripts permettant de contourner quelques limitation clé de certains navigateurs (par exemple ie-css3.js de Keith Clark) et surtout « Modernizr ». A titre personnel, je suis assez réticent à utiliser ce petit bout de Javascript mais Andy le vend très bien. Ceci-dit, il l'intègre dans une logique de travail incluant un savoir-faire de haut niveau qui en fait un vrai plus à utiliser et de fait, je reste persuadé que c'est un outil qu'il ne faut pas mettre dans les mains d'un débutant. En effet, Andy maitrise à la perfection les questions de dégradation harmonieuse et d'enrichissement progressif, en conséquence il sait parfaitement quand utiliser un facilitateur comme « Modernizr » et quand ne pas l'utiliser, ce qui n'est pas nécessairement le cas du webdesigner moyen (en admettant que la notion de webdesigner moyen ait un sens)

En guise de dessert, nous terminons l'après-midi avec la gestion des polices typographiques \o/. La quasi totalité des navigateurs actuels supporte la gestion des polices typographiques. Néanmoins, chacun utilise des formats différents (eot, ttf, woff...). On commence donc par débroussailler ce sujet en ayant droit à une petite visite des utilitaires du site fontsquirrel.com. Néanmoins, actuellement la question des droits d'utilisation des polices sur le web est un problème délicat. Andy nous présente alors typekit.com en détail (Disclaimer : typekit sponsorise Andy Clark pour son intervention, mais ça n'enlève rien à la qualité de l'outil). Ce site propose un système qui permet de résoudre efficacement la question des droits d'utilisation et un ensemble d'outil permettant de se customiser ses polices aux petits oignons. Enfin, on fait un petit coucou aux Google Font API qui présente une alternative gratuite à typekit mais dont le catalogue est encore assez pauvre. Objectivement, il n'y a aujourd'hui aucun frein technique à l'utilisation des polices typographiques embarquées dans les page HTML (sauf pour des questions de performances, mais c'est un autre débat).

Voila pour cette première journée. Ce fut un plaisir de rencontrer Andy. C'est un webdesigner extrêmement talentueux à la fois enthousiaste et réaliste. Son prochain livre sort en Septembre, autant dire que je l'attend impatiemment :D

Devenir beta-testeur de Firefox sous Ubuntu/Linux

Jeremie — Fri, 19 Mar 2010 09:30:00 +0100

Suite à un article de Pascal Chevrez, qui soulignait qu'il n'y avait paradoxalement pas assez de beta-testeur de Firefox pour Linux, j'ai eu envie de me pencher sur la question de l'installation des beta de Firefox sous Linux (enfin sous ma Ubuntu surtout ). En temps que noob de Linux, ça a été assez intéressant de voir ça.

L'idée de cette article est de fournir un "How-to" pour devenir beta-testeur de Firefox sous Ubuntu (mais ça marche aussi pour les utilisateurs de Windows et Mac OSX, hein !) tout en étant volontairement orienté pour un public peu technique (j'assume le fait que vous sachiez tout de même ce qu'est un répertoire et que vous sachiez au moins ouvrir une fenêtre de ligne de commande, même si vous ne savez pas trop quoi en faire).

Petit préambule technique à destination des utilisateurs non techniques : le raccourci ~/ fait référence à votre répertoire de travail personnel. Le chemin d'accès "long" vers ce répertoire sous Ubuntu est /home/nom-d-utilisateur/.

Télécharger Firefox

La première chose à faire, c'est de télécharger la version de Firefox que vous voulez utiliser. Pour cela, vous trouverez tous ce qu'il vous faut sur les sites de Mozilla. Néanmoins, plusieurs choix s'offrent à vous selon ce à quoi vous vous intéressez :

Vous voulez la dernière version stable de Firefox, rendez-vous ici :
http://www.mozilla.com/en-US/firefox/all.html
Vous voulez tester la dernière beta "public", rendez-vous ici :
http://www.mozilla.com/en-US/firefox/all-beta.html (actif uniquement en période de beta-test des versions majeurs, ce qui n'est pas le cas au moment ou j'écris ces lignes)
Vous êtes un aventurier et vous voulez tester une "nightly build", c'est ici que ça ce passe :
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ (notez qu'il s'agit de l'accès direct au "trunk", mais si vous remontez l'arborescence d'un niveau, vous pouvez accéder à d'autres branches de développements... ah ben oui, là, vous êtes vraiment en mode aventure hein)

Attention pour les utilisateur de Linux 64 bits. En effet, Mozilla ne fournis des versions compilées que pour les systèmes 32 bits. Ça ne vous empêchera pas d'utiliser Firefox, mais cela a deux conséquences : D'une part la stabilité de Firefox n'est pas garantis et d'autre part les plugins ne seront pas utilisables (en tout cas, pas facilement).

Vous pouvez également utiliser les dépôts PPA pour faire l'installation (ce qui vous permettra de trouver des compilations 64 bits !)... je ne vais pas trop m'appesantir la dessus vu que je fait une allergie complète à ce système (j'y comprend rien et je n'ai pas envie d'y comprendre quoi que ce soit... je sais, c'est génial et je ne sais pas de quoi je me prive, mais ça me gonfle et je trouve ça beaucoup trop nerd pour moi)

Installer Firefox

L'installation en tant que tel est assez trivial : décompactez l'archive que vous avez téléchargée, et voila, c'est installé. Bon, ok, soyons un peu sérieux. La version de Firefox que vous avez téléchargée est effectivement directement exécutable (sous Ubuntu, vous n'avez aucune question de dépendance à gérer, c'est assez confortable mais je ne sais pas si c'est aussi simple avec d'autres distributions) mais elle est loin d'être intégré au système.

Je ne vais pas vous harasser d'une explication fastidieuse alors que tout est extrêmement bien documenté en français ici : http://doc.ubuntu-fr.org/firefox

Ça y est ? Vous avez installé une autre version de Firefox ? Vous êtes près à double-cliquer sur l'icône de lancement ? Alors là, vous arrêtez tout, vous respirez un grand coup et vous vous posez la question de votre profil utilisateur !

On ne le dira jamais assez, mais avant toute chose, sauvegardez votre profil Firefox habituel ! J'insiste, un accident malheureux est si vite arrivé.

Sous Ubuntu 9.10, tous vos profils utilisateur se trouve dans ~/.mozilla/firefox

C'est particulièrement critique si vous voulez jouer le mode aventure extrême avec les nightly de Firefox. De manière général, je vous invite à vous créer plusieurs profils dédiés à vos tests. Pour créer de nouveau profil ou pour choisir un profil spécifique, il suffit de lacer Firefox avec l'option -p. Vous pouvez rajouter cette options dans les lanceurs d'application d'Ubuntu (clique droit, "propriété") ou bien lancer Firefox depuis la ligne de commande :

firefox -p

Selon les tests que vous voulez réaliser, il peut aussi être utile de créer un profil temporaire pour la seul durée de ces tests. Pascal documente très bien la façon de faire cela sur son site.

De même, vous pouvez avoir besoin de lancer plusieurs instances de Firefox en parallèle (par exemple si vous avez une version stable pour votre navigation quotidienne et que vous voulez réaliser un test sur une version instable). Pour cela, il vous suffit de lancer Firefox avec l'option --no-remote :

firefox --no-remote

La phase de tests

Voila vous êtes près, vous pouvez commencer vos tests. Soyons bien claire, vous êtes libre de tester ce que vous voulez : Le support des standards du Web, les performances du navigateur, la qualité de l'interface utilisateur, la gestion des extensions... c'est vous qui voyez ce qui vous intéresse. Personnellement, lors des phases de beta-test publique, je me contente de surfer "comme d'habitude" et de relever les éventuels problèmes que je rencontre.

Automatisez vos tests

Quoi qu'il en soit, dans une démarche de beta-tests (ou pire, d'alpha-tests), vous risquez d'être amener à reproduire plusieurs fois les mêmes actions. En effet, que ce soit pour vous assurer qu'il n'y a pas de régression d'une version à l'autre ou bien qu'une dysfonction a été corrigée, il va vous falloir refaire plusieurs fois les mêmes actions. En soit, c'est déjà quelque chose de fastidieux, mais en plus, il peut se passer plusieurs mois entre la réalisation de vos différents tests (ça peut prendre du temps de corriger un bug) et se souvenir de ce qu'on a fait il y a plusieurs jours/semaines/mois est loin d'être évident. Il est donc vivement conseillé d'automatiser vos tests pour éviter d'avoir à vous prendre la tête avec ça. Cette phase d'automatisation peut également vous faciliter la vie lorsque vous aurez des bugs à signaler (j'y reviens plus loin).

Pour réaliser cette automatisation, vous avez le choix des armes. cela dépendra de vos connaissances techniques et de vos besoins de test. Ça peut aller de la réalisation d'une page HTML qui recouvre un certain nombre de cas de test à la réalisation d'un script bash complet. Il existe néanmoins une extensions de Firefox qui peut vous être utile : iMacros pour Firefox. Cette extension permet d'enregistrer et rejouer toutes les taches que vous pouvez faire avec Firefox (pas seulement ce que vous faite dans un page web mais vraiment tout, y compris les interactions avec l'interface utilisateur).

L'équipe Assurance Qualité de Mozilla

Si vous êtes vraiment motivé, vous pouvez également aider (pour ne pas dire rejoindre ) l'équipe d'assurance qualité de Mozilla. Elle fédère l'effort de test des produits Mozilla. Elle propose un certains nombre d'outils, organise des évènements spécifiques et met en œuvre un catalogue de cas de tests. Vous trouverez plus d'informations sur le site de Mozilla dédié à l'Assurance Qualité (en anglais).

Cette équipe propose même une extension spécifique pour vous accompagner dans vos démarches de test : le Mozilla QA Companion.

Signaler un bug

Ça y est, là vous êtes chaud. Vous utilisez votre Firefox tout nouveau tout beau, et là... Paf ! C'est le drame ! Vous êtes confronté à un bug. Comme vous êtes quelqu'un de bien, vous allez le signaler à Mozilla. Je ne vais pas vous le cacher, en général, c'est là que ça se corse. Ça se corse parce que le reporting de bug se fait exclusivement en anglais. Là, il n'y a pas vraiment le choix, l'anglais étant la langue partagée par quasiment tous les développeurs de la planète, c'est ce qui est le plus facile pour tout le monde... mais pas forcément pour vous. Détendez vous quand même, il n'y a pas besoin d'être bac+5 d'anglais. Au pire du pire, si vraiment c'est un obstacle insurmontable pour vous, vous pouvez gentiment aller en discuter avec les différentes communautés Mozilla françaises. Que ce soit les traducteurs de FrenchMozilla (D'ailleurs, si votre bug est un bug de traduction, c'est eux qu'il faut aller voir) ou les administrateurs de GeckoZone, si vous leur demandez poliment de l'aide, vous ne devriez pas être bombardé de cailloux, au contraire

Pour signaler un bug, ça se passe sur le site Bugzilla de Mozilla. Mais ne nous précipitons pas, faisons cela dans les règles de l'art (il sera bien temps de faire ça n'importe comment le moment venu ).

Vérifier si ce bug n'a pas déjà été signalé

Alors avant de s'énerver, la première chose à faire est de vérifier si le bug que vous avez repéré n'a pas déjà été signalé par quelqu'un d'autre. En effet, ce n'est pas la peine de signaler un bug qui a déjà été pris en charge par les développeurs et qui sera donc corrigé dans la prochaine version stable/beta/nightly. De même, il est plus constructif de compléter un bug existant que de faire un doublon.

Bon, ne nous le cachons pas, l'interface de bugzilla est cauchemardesque d'un point de vue ergonomique. C'est un outils fait pour les développeurs de Mozilla. Si vous êtes un contributeur occasionnel, abandonnez ici tout espoirs ! Faire une recherche de bug si vous n'avez pas l'habitude des arcanes de l'organisation des développements chez mozilla, c'est l'horreur. Alors si malgré vos effort vous ouvrez un bug qui en doublonne un autre, ne vous inquiétez pas, Mozilla dispose d'une équipe de triage des bugs qui assure grave ! Ne soyez donc pas surpris si vous voyez que votre bug est marqué comme étant un doublon, ça vous arrivera régulièrement, surtout au début

Qualifier votre bug

Maintenant que vous savez (ou croyez savoir, ou n'avez pas envie de savoir) que personne n'a déjà signalé votre bug, vous pouvez vous lancer dans votre rapport de bug. Oui, mais pas de précipitation. Avant de vous jeter sur Bugzilla, prenez le temps de préparer un rapport complet. En effet, il n'y a rien de plus inutile qu'un rapport de bug sous la forme de "Y'a tel machin qui marche pas". En effet, les personnes qui vont traiter le bug ne sont pas à votre place, il faut donc leur donner un minimum de contexte pour qu'ils puissent travailler efficacement.

Un rapport de bug exploitable contiens un certain nombre d'informations clés :

Commencez par dire quel est la version de Firefox que vous utilisez et votre système d'exploitation. Le plus simple est de coller purement et simplement la "User Agent String" de votre navigateur dans votre rapport de bug. Vous la trouverez en vous rendant dans le menu : Aide > A propos de Mozilla Firefox
Décrivez toutes les étapes qui permettent de reproduire le bug (idéalement sous forme d'une liste ordonnée). Si vous avez pensé à automatiser vos tests, vous pouvez en plus joindre le script d'automatisation, les développeurs pourront alors reproduire assez simplement le problème (et donc potentiellement traiter votre bug plus vite ). Si ce bug ne peut pas être reproduit systématiquement, précisez le bien et essayez de qualifier sa fréquence d'apparition.
Précisez le résultat normalement attendu par votre test et le résultat réel constaté de votre test. Encore une fois plus vous serez précis sur ces deux points, plus le bug sera facile à identifier et à corriger.

Ouvrir un bug

Bon, ben nous y voila, c'est le grand moment. Si ce n'est déjà fait, commencez par vous ouvrir un compte sur Bugzilla et faites l'effort de survoler le guide de bonne conduite de Bugzilla (c'est court et pas prise de tête, mais on y retrouve quelque points important pour une bonne vie en communauté). Une fois identifié, vous n'avez plus qu'à remplir votre rapport de bug et voila... vous faites désormais partis de la grande famille des contributeurs au projet Mozilla. Bravo

Conclusion

Comme vous pouvez le voir, il n'y a rien de vraiment compliqué. Il n'est même pas nécessaire que vous ayez des connaissances techniques particulières. C'est tout l'intérêt du mode de développement ouvert de Mozilla : tout le monde peu participer dans la mesure de ses moyens, connaissances, disponibilités. En fait, le seul problème que j'ai avec Mozilla, c'est la difficulté à trouver comment participer. En effet, Mozilla communique assez mal sur comment il est possible de participer. Mozilla dispose de tout un tas d'outils et il est parfois difficile de savoir ou commencer dans la profusion des possibilité qui sont offerte. En dehors du développement, il existe des tas d'autres choses à faire avec Mozilla : du marketing, de la R&D, de l'ergonomie, et bien plus. C'est parce qu'il est difficile de savoir ou commencer que j'ai écris cet article. J'essayerai de vous parler de toutes ces autre opportunités pour les non-développeur au seins du projet Mozilla car ce n'est pas toujours claire pour s'y retrouver. N'hésitez pas à vous renseigner sur les forums de discutions francophone, les gens sont sympas et n'hésiteront pas à vous aider à démarrer. Bienvenu !

Le marketing du choix des navigateurs

Jeremie — Tue, 23 Feb 2010 16:01:00 +0100

Je viens de lire l'article de Tristan Nitot sur le futur écran de choix des navigateurs qui sera prochainement accessible aux utilisateurs de Windows. Ce qui a particulièrement attiré mon attention, c'est la capture d'écran qui est affichée et qui présente les différentes accroches marketing que chaque constructeur va utiliser pour mettre en avant son navigateur. Elles sont particulièrement représentatives et je vous propose d'en faire une petite analyse rapide.

Les accroches qui seront présentées sur cet écran sont particulièrement importantes. En effet, ce sont elles qui vont principalement influer sur le choix de l'utilisateur. D'une part, elles doivent être raccord avec l'ensemble des communications du constructeur sur son produit afin que l'utilisateur qui a déjà eu connaissance d'un ou plusieurs navigateurs retrouve ses marques. D'autre part, elles doivent mettre en avant le ou les avantages concurrentiels clés de chaque navigateur pour les utilisateurs qui n'en ont jamais entendu parlé. L'objectif affiché étant de convaincre l'utilisateur de faire le choix de son navigateur en l'espace de quelques secondes !

Mozilla Firefox

Avec Firefox, surfez sur Internet en toute sécurité. Firefox est gratuit, profitez librement et pleinement du Web avec lui !

Les qualités mises en avant sont la sécurité, la gratuité et la liberté. La sécurité a toujours été un argument de vente majeur de Firefox auprès du grand public et c'est un argument qui porte. Néanmoins, c'est un argument à double tranchant qui peut se retourner contre Mozilla en cas de faille "zero day" ou d'un exploit visant particulièrement Firefox. La gratuité est elle aussi un argument fort, mais qui pose question. En effet, tous les navigateurs présentés sont gratuits (même si on peut discuter du sujet en ce qui concerne IE, du point de vue de l'utilisateur lambda, il est lui aussi gratuit), il ne s'agit donc pas d'un argument différenciant mais uniquement d'un argument opportuniste. Enfin, Mozilla met en avant les notions de liberté. C'est un argument éthique important, mais difficilement lisible hors contexte. En effet, dans quelle mesure les utilisateurs qui n'ont pas déjà fait le choix de Firefox se sentent-ils bridés ou restreints dans leur utilisation d'Internet en général et du Web en particulier ?

Sur la forme, l'accroche est rédigée en deux phrases qui reprennent deux fois le nom du produit. Cela peut s'interpréter comme une volonté de mettre en avant le produit, mais peut avoir un petit côté rabâchage et inutilement insistant. La première phrase est affirmative, soulignant particulièrement la sureté du produit et en faisant l'argument clé. La deuxième phrase est exclamative, ce qui lui donne un petit côté "cadeau bonus" et affadit légèrement les arguments mis en avant. Si cela se comprend pour la gratuité qui est un faux argument, c'est dommage pour la liberté qui est au centre de l'éthique de Mozilla. Sur ce dernier point, l'utilisation du qualificatif "pleinement" tente de redresser la barre pour redonner du poids à l'argument libertaire mais en prenant le risque de rendre le message plus compliqué à comprendre.

Ma conclusion : Même si les promesses client sont fortes, le message reste globalement flou et difficile à comprendre si l'on ne dispose pas du discours marketing complet à propos de Firefox. Malgré une volonté de toucher le grand public, cette accroche reste encore trop ciblée sur la périphérie de la communauté des utilisateurs de Firefox (certes importante) et ne portera véritablement que pour des personnes qui ont déjà entendu parlé du produit. Si la fondation Mozilla prévoit une grosse campagne de communication lors de l'arrivée de cet écran de choix, ça marchera. Sinon, l'efficacité du dispositif sera toute relative et ne devrait pas faire changer radicalement la part de marché de Firefox.

Google Chrome

Google Chrome. Un navigateur rapide, conçu pour tous.

Les qualités mises en avant sont la rapidité et l'universalité. La rapidité est effectivement l'argument majeur de vente de Chrome depuis son lancement. Au vu de la course aux performances que se livre les différents constructeurs, on peut légitimement se poser la question de savoir jusqu'à quand cet argument restera véritablement différenciant. Concernant l'universalité, il s'agit globalement d'un argument passe-partout sans réelle valeur ajoutée vis-à-vis du produit lui même mais qui s'adresse directement à l'utilisateur novice : "si c'est fait pour tous, alors moi aussi je devrais être capable de m'en servir". Néanmoins, au vu de la disruptivité de son interface, cet argument peut être discutable. Cela pourrait créer une certaine insatisfaction chez des utilisateurs habitués à IE et qui risquent d'avoir du mal à retrouver leurs habitudes.

Sur la forme le nom du produit est une phrase à lui seul (c'est une phrase nominale ), ce qui lui donne une force particulière. Il est là comme une évidence, il se suffit à lui même. Cette phrase sans verbe exclut toute notion de choix. Rapporté à la notion d'universalité qui conclut la deuxième phrase, le dispositif rédactionnel est un redoutable piège sémantique : Une évidence universelle induit le choix par sa seule force.

Ma conclusion : Les responsables marketing de Google ont su mettre en place une accroche extrêmement efficace qui annihile quasiment toute possibilité de choix. Néanmoins, l'évidence que représente Chrome se heurte à une certaine vacuité des arguments différenciant. Seul la rapidité est mise en avant. Ainsi, pour les personnes qui cherchent un navigateur rapide, l'efficacité de cette accroche sera à son paroxysme. Pour les autres utilisateurs, il faudra que les campagnes de promotions de Chrome aient réussi à porter pour que l'efficacité marketing du dispositif perdure au moment du choix. Attention également à la sur-agressivité lapidaire du positionnement marketing qui peut être contre productive au moment ou Google est chahuté sur sa supposé hégémonie sur Internet.

Apple Safari

Safari pour Windows d'Apple, le navigateur le plus novateur au monde.

La qualité mise en avant est l'innovation. On retrouve là un des arguments de vente traditionnel d'Apple qui cherche à se positionner sur de l'avant-gardisme haut de gamme. Étonnamment, c'est la seule qualité qui est vanté alors qu'Apple dispose d'autres arguments dans son discours marketing traditionnel comme la simplicité ou la convivialité.

Sur la forme, Apple tente d'être incisif en résumant en une phrase son accroche. Néanmoins, cette accroche se divise en deux parties. Une première partie qui est là pour affirmer la logique de la présence d'un produit Apple dans un environnement Windows et une deuxième partie qui, elle, s'axe clairement sur le produit et sa valeur ajoutée.

Ma conclusion : Apple se livre ici à un exercice de style difficile dans lequel il s'empêtre. D'une part, Apple est tellement lié au monde Mac qu'il se sent contraint de devoir justifier sa présence sur Windows en insistant assez lourdement et maladroitement sur le fait qu'il s'agit de Safari pour Windows réalisé par Apple. D'autre part, en perdant du temps avec cette explication, il est alors contraint à ne mettre en avant qu'un seul élément différenciant pour le produit faute de place. A bien des égards, un certain élitisme ("le plus [...] au monde") typique d'Apple transpire ici pour essayer de raccrocher son produit à la communauté des fans d'Apple... ce qui est toujours étonnant lorsqu'on s'adresse à des utilisateurs de Windows.

Microsoft Internet Explorer

Internet Explorer, conçu spécialement pour vous par Microsoft, est le navigateur le plus utilisé au monde.

Aucune qualité particulière n'est mise en avant ! En effet, Microsoft a décidé de miser sur deux cartes qui ne sont pas spécifiquement liées au produit lui-même : D'un coté la proximité avec l'utilisateur ("spécialement pour vous") et d'un autre coté l'adoption constatée du Navigateur ("le plus utilisé au monde")

Cette approche est une vaste fumisterie mais qui marche. En effet, il s'agit d'un adroit mélange de proximité avec l'utilisateur, de poids de la marque et d'éléments factuels lourds de sous-entendu : Si IE est le plus utilisé au monde c'est sans doute que c'est un excellent navigateur... après tout, il a été conçu spécialement pour vous. Alors franchement, pourquoi en changer ?

Microsoft réussit ici un tour de force digne des plus grands experts en marketing : vous vendre un produit en mettant cote à cote deux concepts radicalement opposés (l'individualisation du "pour vous" et l'adoption de masse du "le plus utilisé") qui entrent en résonance. Rien n'est dit sur une quelconque qualité du navigateur qu'il propose et pourtant, ça marche. Du strict point de vue des mécanismes de communication mis en jeu, il s'agit indubitablement de la meilleure accroche parmi les cinq qui sont vues ici.

Grosso modo, Apple et Microsoft se sont appuyés sur les mêmes mécanismes, mais ça ne pouvait marcher qu'avec Microsoft car ce type d'approche ne fonctionnera que parce que l'utilisateur adhère déjà aux produits de Microsoft (après tout, il utilise déjà Windows). A la différence des autres constructeurs, Microsoft est dans une logique de défense, cherchant à convaincre des utilisateurs déjà rompus à l'usage d'Internet Explorer de rester dans son giron.

Opera Browser

Le navigateur Web puissant et convivial. Essayez le seul navigateur doté de la technologie Turbo et boostez votre connexion Internet.

Les qualités mises en avant sont la puissance, la convivialité et la vitesse.

Sur la forme, Opera décompose son accroche en deux phrases. La première est générique et présente un argument différenciant fort : l'alliance de la puissance et de la convivialité. Le deuxième phrase, plus "commerciale", présente un sous-produit spécifique à Opera : la technologie Turbo. De manière assez troublante, Opera est le seul constructeur à ne pas mentionner le nom de son produit dans son accroche.

Ma conclusion : Cette accroche est sans doute la plus complexe à décrypter. En effet, d'un côté, elle se veut fortement différenciante avec des qualités fortes clairement mises en avant. D'un autre côté, la promotion d'une technologie spécifique ayant une influence sur la "connexion Internet" est difficile à comprendre. En effet, ce dernier point repositionne Opera vers les utilisateurs de connexion plus ou moins lentes. Quand on voit le taux de pénétration de l'ADSL en France, on peut se poser la question d'un tel positionnement sur les environnements de bureau. Ce positionnement prenant la part la plus importante du message, le bénéfice des deux premières qualités est fortement affadit et n'est plus convaincant. En outre, il est surprenant de voir le discours de prudence d'Opera ici qui encourage à essayer au lieu de convaincre à une adoption inconditionnelle. Cela aussi tend à faire baisser la force de l'accroche. Enfin, le fait de ne pas mentionner le nom de son navigateur est risqué. Certes, cela peut se comprendre dans la mesure où Opera n'a pas une marque forte ou un nom de produit emblématique à mettre en avant, mais dans ce contexte cela peut être gênant, l'utilisateur pouvant être amené à se demander de quoi on lui parle. Or, dans un contexte de prise de décision rapide (quelques secondes tout au plus) la moindre question superflue peut amener l'utilisateur à se rabattre sur un autre produit.

Et finalement, cela nous donne... ?

Chacune de ces accroches reflète assez bien les positions connues des différents constructeurs :

Microsoft défend ses positions ;
Google est extrêmement agressif et cherche à se positionner sur un marché de masse ;
Mozilla se positionne sur un mélange de préoccupations quotidiennes allié à des questions éthiques ;
Apple et Opera se positionnent sur leurs marchés de niche traditionnels sans vraiment chercher à élargir ceux-ci.

A bien des égards, on sent le professionnalisme des équipes marketing de Microsoft et Google qui savent parfaitement user des ficelles de la communication pour se positionner efficacement. Mozilla joue les challengers mais on sent encore le manque de maturité de la fondation sur les questions de marketing traditionnel. Enfin, Apple et Opera ne sont ici que pour "occuper le terrain" et ne semblent pas chercher une vraie confrontation sur le terrain des navigateurs de bureau, tous les deux se concentrant sur le marché du mobile.

En dernière analyse, mon pronostic est que c'est Chrome qui devrait le mieux s'en sortir ici.

Et vous, qu'est-ce que vous en pensez ?

La propriété CSS display: inline-block

Jeremie — Thu, 28 Jan 2010 14:00:00 +0100

La propriété CSS display reste sous-employée par les intégrateurs web. Ce n'est pas entièrement leur faute, les implémentations dans les navigateurs n'étant pas entièrement à la hauteur de la norme. Je reviens ici sur la valeur inline-block de cette propriété qui est désormais implémenté dans tous les navigateurs du marché et qui peut facilement nous aider à sortir de la sur-utilisation de la propriété float.

La propriété display permet d'indiquer explicitement le mode de rendu d'un élément HTML. Les valeurs les plus connues sont none, block et inline. Pourtant il y en a beaucoup d'autres et en particulier la valeur inline-block

`Block` et `inline`, les basiques

Chacune de ces valeurs va avoir une incidence sur la façon de rendre les éléments HTML ciblés. Malheureusement, les normes HTML 4.01 et CSS 2.1 sont assez floues sur ce que sont des éléments de type block ou inline et les futures normes HTML 5 et CSS 3 sont à peines plus loquaces sur le sujet. Pour mieux comprendre ce que sont ces types de rendu, je vous propose une caractérisation de ceux-ci selon mon expérience (c'est totalement empirique, et si vous pensez que j'ai omis des choses, n'hésitez pas à le signaler).

Les caractéristiques d'un élément de type `block` :

Les éléments de type block peuvent contenir à la fois d'autres éléments de type block, des éléments de type inline ou du texte¹.
Il est possible de fixer une largeur et une hauteur à ces éléments
Par défaut, la largeur d'un élément de type block est aussi grande que celle de son conteneur
Ils s'empilent naturellement les uns au-dessus des autres, dans l'ordre du flux HTML (Dans un flux de texte, ils passent à la ligne et forcent le retour à la ligne des éléments qui les suivent, les caractères invisibles présents avant et après sont ignorés)

Les caractéristiques d'un élément de type `inline` :

Les éléments de type inline ne peuvent contenir que d'autres éléments de type inline ou du texte
Il n'est pas possible de définir une largeur et une hauteur explicite pour ces éléments
Par défaut, leur largeur et leur hauteur dépendent du contenue de l'élément
Ils s'écoulent selon le flux du texte HTML

inline-block, un mélange des deux !

Avec cette valeur de la propriété display, vous allez avoir des éléments qui vont se comporter à la fois comme s'ils étaient de type block et de type inline. Concrètement, ça va donner les caractéristiques suivantes :

Les éléments de type inline-block peuvent contenir à la fois d'autres éléments de type block, des éléments de type inline ou du texte.
Il est possible de fixer une largeur est une hauteur à ces éléments
Par défaut, leurs largeurs et leurs hauteurs dépendent du contenu de l'élément
Ils s'écoulent selon le flux du texte HTML

Cela va avoir quelques conséquences :

La hauteur d'un élément de type inline-block va contrarier la hauteur des lignes de texte (même si vous l'avez fixée avec la propriété line-height) et donc potentiellement compromettre le rythme vertical de votre design.
Vous pouvez influer sur le positionnement de l'élément sur la ligne de base typographique en utilisant la propriété vertical-align.
Si une partie du contenu de l'élément doit passer à la ligne, c'est tout l'élément qui passera à la ligne

Implémentation de cette valeur dans les navigateurs

Le plus important à retenir, c'est que tous les navigateurs du marché implémentent la valeur inline-block pour la propriété display.

Attention tout de même à sont utilisation dans IE6 et IE7. En effet, l'implémentation de cette valeur est buggée sur ces deux navigateurs et ils ne supportent celle-ci que pour les éléments HTML qui sont nativement considérés de type inline par ces navigateurs. Cela à peu d'incidence pour peu qu'on y prenne garde. De toute façon, IE6 va bien finir par disparaitre et IE7 va rapidement être remplacé par IE8. D'ailleurs, IE8 est déjà le navigateur dominant de la gamme IE sur le marché des particuliers, il est donc plus que temps d'utiliser cette valeur de la propriété display.

Cas d'utilisations

Menu de navigation

L'usage de la propriété display:inline-block peut résoudre bon nombre des difficultés liées à l'usage de la propriété float. Néanmoins, il faut rester prudent.

Ce premier exemple reprend un balisage classique de menu sur une base de liste non-ordonnée. Cela fonctionne bien mais à deux conditions qui disqualifient presque l'usage de la valeur inline-block ici. Premièrement, dans la mesure où la balise LI est considérée nativement comme étant de type block, IE6 et IE7 ne géreront pas correctement l'usage de display. En outre, si vous voulez pouvoir contrôler l'espacement entre les onglets, vous devez accoler les balises LI dans le code HTML. En effet, les balises étant déclarées comme inline-block, elles vont suivre le flux de texte HTML ce qui veux dire que les espaces entre les balises sont affichés.

Ce deuxième exemple utilise un balisage plus simple (une succession de balises A) et utilise les spécificités qu'offre inline-block : centrage horizontal et vertical et utilisation des espaces typographiques. De fait, cette approche fonctionne parfaitement dans IE6 et IE7.

Nuage de tags

L'utilisation de inline-block sur un nuage de tags offre un monde de possibilités. Le fait de pouvoir donner explicitement une hauteur et une largeur ou de pouvoir spécifier des marges explicites aux éléments ouvre d'énormes portes aux graphistes. L'avantage le plus immédiat est d'éviter que des tags en plusieurs mots soient coupés par un retour à la ligne impromptu.

Titraille dépendante du contenu

Ce dernier exemple montre comment cette valeur permet de gagner en subtilité sur la gestion graphique des titres en permettant de créer simplement des effets liés à la taille du contenu plutôt qu'à la taille du contenant.

Aller plus loin

La propriété display a bien d'autres valeurs : certaines sont peu ou pas implémentées (la valeur compact), certaines sont partiellement implémentées et particulièrement difficiles à comprendre (la valeur run-in) et certaines sont largement implémentées mais peu ou pas utilisées (les valeurs table-* qui mériteraient un article à elles-seules... peut-être un jour si j'ai le temps ).

Pour en savoir plus sur le sujet, je vous renvoie vers ma bible du support des propriétés CSS : le site quirksmode.org et plus spécifiquement, sa section dédié à la propriété display.
Pour savoir comment contourner les limites des vieux navigateurs, je vous recommande l'excellent article de Florent Verschelde : Inline-block dans tous les navigateurs modernes ?
Pour une vue d'ensemble de la propriété display, il y a cette excellent tutoriel chez Alsacréations : Mise en page CSS avancée grace à la propriété display
En anglais : Robert Nyman, CSS display: inline-block: why it rocks, and why it sucks

Attention, il s'agit de la définition générale (selon la norme CSS) de ce qu'est un élément de type block. Cela ne remet pas en cause les spécificités propres à HTML comme par exemple la balise P qui selon la norme HTML 4.01/ XHTML 1.0 est bien de type block mais ne peut pas contenir d'autres éléments de type block.

Chez Jérémie

SVG et HTML5 font bon ménage avec Firefox

Les premiers seront les derniers

Mais pourquoi, John ? Pourquoi ?

Bouger ou ne pas bouger, tel est la question

One piece to rule them all

T'as d'beaux yeux tu sais !

Pimp my mouse

Ombrage, ô désespoirs !

Allo ! Caroline ! C'est Roger.

Parfois, c'est le vil coyote qui gagne

Is there a Road Runner over here?

Robert ! Il y a un cafard dans la machine.

Allo ! Tonton ? Pourquoi tu tousses ?

Canvas pas aller ça monsieur.

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

Le mot de la fin (des haricots)

Introduction à SVG

C'est quoi SVG ?

Comment l'utiliser

Structure de base d'un document SVG

Embarquer un document SVG dans une page HTML

L'utilisation directe de balises SVG dans le code HTML

SVG c'est un format d'image, alors pourquoi pas la balise img ?

Et avec CSS aussi pourquoi pas !

L'utilisation de la balise object

Quand tout le reste a échoué, il reste les iframe !

Qu'est-ce qu'on peut faire avec ce langage ?

Dessin

Filtres et transformation

Transformations

Filtres

Animation, Scripting et gestion évènementielle

Des logiciels pour se simplifier la vie

Conclusion

En savoir plus

Améliorez vos liens avec la génération de contenu CSS

Le résultat attendu

L'arrière plan des liens

La génération de contenu

Le positionnement et le design du badge

CSS 3 is sexy !

Couleur transparentes

Bords arrondis

Ombres et lumières

Attention à l'accessibilité

Au royaume des aveugles les borgnes sont rois.

Les souris, ce fléau de l'humanité !

Mon royaume pour un cheval.

Conclusion

@media London 2010 : Day 4

@media London 2010 : Day 3

@media London 2010 : Day 2

@media London 2010 : Day 1

Devenir beta-testeur de Firefox sous Ubuntu/Linux

Télécharger Firefox

Installer Firefox

La phase de tests

Automatisez vos tests

L'équipe Assurance Qualité de Mozilla

Signaler un bug

Vérifier si ce bug n'a pas déjà été signalé

Qualifier votre bug

Ouvrir un bug

Conclusion

Le marketing du choix des navigateurs

Mozilla Firefox

Google Chrome

Apple Safari

Microsoft Internet Explorer

Opera Browser

Et finalement, cela nous donne... ?

La propriété CSS display: inline-block

Block et inline, les basiques

Les caractéristiques d'un élément de type block :

Les caractéristiques d'un élément de type inline :

inline-block, un mélange des deux !

Implémentation de cette valeur dans les navigateurs

Cas d'utilisations

Menu de navigation

SVG c'est un format d'image, alors pourquoi pas la balise `img` ?

L'utilisation de la balise `object`

Quand tout le reste a échoué, il reste les `iframe` !

`Block` et `inline`, les basiques

Les caractéristiques d'un élément de type `block` :

Les caractéristiques d'un élément de type `inline` :