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

Des effets pour le Web

Jeremie — Thu, 12 Jan 2012 09:00:00 +0100

Cet article est la traduction d’un article de Christian « Schepp » Schaefer à propos des nouvelles propriétés de filtres CSS3 et montre comment commencer à les utiliser tout en proposant des solution de repli basées sur ce que supportent les navigateurs actuels.

A la fin des années 90, CSS 2.1 nous a fourni un ensemble d’outils de base pour pouvoir enfin se débarrasser des mises en page en tableaux. Maintenant c’est le tour de CSS3 qui nous donne de nouveaux outils plus précis pour gérer les détails de mise en forme : Les fontes embarquées, les coins arrondis, les dégradés, la transparence des éléments et des couleurs, les ombre portées sur le texte et les boites, etc.

Évidement, lorsqu’on compare notre outillage à celui de logiciels comme Photoshop, on se dit qu’on pourrait rêver mieux. Ce genre de logiciel permet, par exemple, de désaturer une image ou bien de la rendre plus nette ou plus floue. Pourquoi aurions-nous besoin de ce genre d’outil pour le Web ? Et bien, désaturer ou flouter une partie de page Web peut être un moyen de guider le regard de vos visiteurs sur des zones choisies. Ça pourrais aussi aider vos visiteurs à concentrer leur attention sur les zones qui n’ont pas été modifiées. Par exemple, on peut utiliser ce genre d’effets pour mettre en scène une galerie d’images :

D’un autre coté, un effet de netteté peut être utile lorsque vous réduisez une image dans le navigateur. Sans lui, vous allez perdre un certain nombre de détails sur cette image.

Voila, ce serait génial si nous pouvions avoir ce genre d’effets à notre disposition, un peu comme la propriété CSS opacity qui nous permet de rendre un élément transparent. Malheureusement, ce n’est pas le cas.

Le status quo actuel

Au lieu de cela, pour simuler un effet de désaturation/niveau de gris nous sommes actuellement obligés de passer en revue « à la main », via Javascript, toutes les propriétés utilisant de la couleur sur un éléments donnée pour leur attribuer la valeur de gris que l’on veut. Dès que l’on doit faire face à des images ou de la vidéo, c’est encore plus compliqué : Dans ce cas-là, nous avons besoin de nous appuyer sur la balise Canvas de HTML5 pour pouvoir changer leur couleur pixel par pixel puis pour remplacer l’élément d’origine. Même si nous nous appuyons sur des bibliothèques tel que CamanJS ou Hoverizr, ça reste quand même un truc assez sale.

Un effet de flou peut également être simulé à l’aide des propriétés text-shadow et box-shadow en leur appliquant la même couleur que le texte ou l’arrière-plan auquel elles se rapportent. Le problème, c’est que cette illusion ne fonctionnera pas avec les boîtes multicolores non plus qu’avec les images ou les vidéos comme précédemment. Une fois de plus, il faudra se reposer sur des manipulation à base de Canvas HTML5. Arf!

Á propos de la balise Canvas: La bibliothèque blurry.js propose une solution particulièrement brutale à cette histoire de flou. Elle va extraire tout le contenu à flouter, va le recréer dans une balise Canvas (en utilisant partiellement Cufón), va le flouter et enfin va réinjecter le tout à l’emplacement de l’original.

En ce qui concerne la netteté, il n’existe actuellement aucun truc basé sur CSS pour réaliser un tel effet, ce qui nous laisse une fois de plus seul face à la balise Canvas.

SVG à la rescousse

Il est intéressant de noter que SVG connaît la notion de filtres depuis des lustres avec, entre autre, les mélanges de couleurs, l’ajustement de la luminosité et du contraste, les effets d’éclairage, le « displacement mapping », les flous gaussien et de déplacement, le bruit, la netteté, etc.

Ainsi, maintenant que SVG est de plus en plus largement supporté, nous pourrions essayer de placer nos contenus, non plus dans du HTML, mais plutôt dans du SVG que l’on placerait dans du HTML. Nous serions alors capables d’appliquer n’importe quel effet à notre contenu. Le problème, c’est que la plupart des intégrateurs HTML risquent de ne pas être très chauds pour se mettre à produire du balisage SVG de ce genre :

<text font-family="Arial" font-weight="900" font-size="40" x="20" y="55%">SVG Example</text>

Il existe un truc un peu plus sympa en SVG, c’est la balise foreignObject. Elle nous permet d’inclure n’importe quel type de balisage à l’intérieur d’un contenu SVG. C’est un peu comme mettre du SVG directement dans un document HTML5, mais dans l’autre sens. Dès que vous avez inclus vos trucs dans du SVG, vous pouvez y appliquer des filtres comme vous le feriez pour n’importe qu’elle autre partis de votre contenu SVG. Vous pouvez embarquer une page HTML entière et lui appliquer des filtres, ou vous restreindre à une simple image bitmap. Bien sûr, vous devez mettre votre contenu SVG lui-même dans une page HTML, ce qui peut conduire à quelques migraines (du HTML embarqué dans du SVG embarqué dans du HTML). Le support navigateur pour la balise foreignObject est plutôt bon. Seul Internet Explorer reste à la traine. Heureusement, Internet Explorer 10 va rattraper le coup en supportant à la fois les filtres SVG et la balise foreignObject.

Les filtres SVG sur du contenu HTML via CSS

Depuis sa version 3.5, Firefox va encore plus loin. Il vous permet d’appliquer un filtre SVG, défini dans un document externe, à n’importe quel contenu HTML en passant simplement par une feuille de style. Nous pouvons, par exemple, définir dans un document SVG un filtre de flou gaussien (feGaussianBlur) ayant un rayon de 2 pixels et lui donner l’identifiant gaussian_blur :

<?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="1" height="1" version="1.1" 
xmlns="http://www.w3.org/2000/svg" 
xmlns:xlink="http://www.w3.org/1999/xlink">
  <defs>
    <filter id="gaussian_blur">
      <feGaussianBlur in="SourceGraphic" stdDeviation="2" />
    </filter>
  </defs>
</svg>

On peut alors référencer ce filtre à l’aide du nom du fichier SVG et de son l’identifiant au sein de notre feuille de style pour l’appliquer à toutes les images :

img {
    filter: url(blur.svg#gaussian_blur);
}

Vous pouvez voir cette démo en live ici. Hélas, comme je vous le disais, ça ne fonctionne qu’avec Firefox.

Bien heureusement, ce n’est pas la fin de l’histoire. Internet Explorer connaît lui aussi les filtres. Ceux-ci ne sont pas basés sur SVG, mais sur des mécanismes propres à la bibliothèque graphique de Windows : DirectX. Parmi ces filtres certains sont bien connus pour nous aider à résoudre certains bugs (le filtre alpha pour les image PNG) ou pour imiter certaines fonctionnalités de CSS3 (le filtre des dégradé). Néanmoins, il en existes d’autres très similaires aux filtres SVG :

/* Flou de 2 pixels de rayon */
filter: progid:DXImageTransform.Microsoft.Blur(pixelradius=2);
/* Flou de mouvement de 13 pixel avec un angle de 310° */
filter: progid:DXImageTransform.Microsoft.MotionBlur(strength=13, direction=310);
/* niveau de gris / désaturation */
filter: gray;
/* Effet « Rayon X » (inversion des niveaux de gris) */
filter: xray;
/* cône de lumière */
filter: light();
/* Extrusion */
filter: progid:DXImageTransform.Microsoft.emboss();

Vous trouverez une liste complète de ces filtres ici : http://msdn.microsoft.com/en-us/library/ms673539(v=VS.85).aspx

Ainsi, à l’aide de commentaires conditionnels, nous pouvons désormais proposer un certain nombre d’effets à deux familles de navigateurs qui à elles deux représente une part non négligeable du marché :

<!DOCTYPE HTML>
<!--[if lte IE 9]> <html class="ie" lang="en"> <![endif]-->
<!--[if gt IE 9]><!--> <html lang="en"> <!--<![endif]-->
<head>
<meta charset="utf-8">
<title>Blur via CSS</title>
<style>
img {
  filter: url(blur.svg#gaussian_blur);
}
.ie img {
  margin: -2px;
  filter: progid:DXImageTransform.Microsoft.blur(pixelradius=2);
  zoom: 1;
}
</style>
</head>
<body>
  <img src="http://jeremie.patonnier.net/post/2012/01/12/stadt.jpg"
   alt="Some rights reserved by zigazou76"
   width="500" height="333">
</body>
</html>

margin: -2px permet de contre balancer le changement de dimension de l’image provoqué par le filtre. zoom: 1 est necessaire pour que la plupart des filtres fonctionnent avec in IE6/7. Malheureusement, IE10 ne supporte plus les filtres propriétaires de Microsoft et n’autorise pas encore les filtres SVG sur du contenu HTML

Vous trouverez ici la version modifié de l’exemple

Un certain nombre de personnes ont apprécié l’idée de Firefox d’ouvrir les filtres SVG au contenu HTML. Ils ont donc formé un nouveau groupe au W3C appelé W3C FX Task Force dont l’objectif est de standardiser et simplifier l’usage des filtres SVG dans tous les navigateurs. Puisque Firefox avait défriché le terrain des filtres d’effets, le premier brouillon de spécification est vite arrivé sous le nom de W3C Filter Effects 1.0. Les mécanismes proposés dans ce brouillon fonctionnent à peu près comme dans Firefox tout en offrant en plus un certain nombre de raccourcis vers les effets les plus intéressants. Les filtres bénéficiant d’un raccourci fonctionnent sans l’aide d’un fichier SVG externe. Ils sont directement codés au cœur du navigateur. Les raccourcis en question sont :

grayscale
sepia
saturate
hue-rotate
invert
opacity
brightness
contrast
blur
drop-shadow

Un autre avantage de ces raccourcis, c’est qu’ils peuvent être animés via les transformations et les animations CSS :

.foo {
  filter: blur(2px);
  transition: filter 1s ease-in-out;
}
 
.foo:hover {
  filter: blur(0);
}

Ce serait plus difficile et moins efficace de réaliser cela dans un document SVG.

Pour finir, les effets de filtre prévois d’être enrichie à l’aide des vertex shaders et fragment shaders d’OpenGL/WebGL. Les vertex shaders permettront d’appliquer un maillage 2D sur un élément que vous pourrez alors déformer en déplaçant tous les points du maillage selon une formule mathématique de votre choix. Les fragment shaders d’un autre côté permettront de réaliser ces transformations mathématiques sur les couleurs de chacun des pixels de cet élément. Ces deux types de filtres bénéficieront en plus de l’accélération matérielle de votre carte graphique.

Par un heureux hasard, il y a quelques semaines les premières implémentations de ces filtres sont apparues dans les compilations nocturnes de Webkit et sont à présent disponibles dans Chrome Canary. Ça veut dire que d’ici 3 mois les filtres CSS seront disponibles dans la version stable de Chrome et à brève échéance dans Safari. Ça veut également dire que nous ne sommes pas loin de pouvoir commencer à utiliser des filtres CSS sur 90 à 95% du marché des navigateurs !

Si l’on en revient à notre exemple, tout ce que nous avons à faire pour supporter Webkit est de rajouter un simple -webkit-filter: blur(2px);. Néanmoins, il faudra faire attention de le placer après la propriété filter non-préfixée. La raison étant que lorsque Webkit supportera la version non-prefixée de la propriété filter, la syntaxe propre à Firefox créra des problèmes avec la transition CSS que nous allons appliquer pour passer doucement entre la version flou et nette de l’image via -webkit-transition: -webkit-filter 1s ease-in-out;.

<!DOCTYPE HTML>
<!--[if lte IE 9]> <html class="ie"> <![endif]-->
<!--[if gt IE 9]><!--> <html> <!--<![endif]-->
<head>
<meta charset="utf-8">
<title>Blur via CSS</title>
<style>
img {
  filter: url(blur.svg#gaussian_blur);
  -webkit-filter: blur(2px);
  -webkit-transition: -webkit-filter 1s ease-in-out;
}
img:hover {
  filter: none;
  -webkit-filter: blur(0);
}
.ie img {
  margin: -2px;
  filter: progid:DXImageTransform.Microsoft.blur(pixelradius=2);
  zoom: 1;
}
.ie img:hover {
  margin: 0;
  filter: none;
}
</style>
</head>
<body>
  <img src="http://jeremie.patonnier.net/post/2012/01/12/stadt.jpg"
   alt="Some rights reserved by zigazou76"
   width="500" height="333">
</body>
</html>

La dernière version de l’exemple

Et voila, des effets de filtres pour tout le monde ! Faisons de 2012 l’année des filtres CSS et amusez-vous bien avec.

Paris Web 2011 : SVG et Typographie

Jeremie — Tue, 18 Oct 2011 16:58:00 +0200

Paris Web 2011 s’est tenu les 13, 14 et 15 octobre dernier. Cette année encore j’y étais et force et de reconnaitre qu’une fois de plus, l’équipe a sué sang et eau pour en faire un évènement de qualité inégalé. Bravos à tous, vous avez assuré grave

Le programme était vraiment d’excellente facture, et je retiendrai en particulier deux conférences : D’une part, celle d’Antony Ricaud qui a pris le temps d’expliquer et de détailler comment fonctionne un navigateur (chose que peu de web designer connaissent mais qui explique beaucoup de choses, comme par exemple “pourquoi les sélecteurs CSS sont lus de droite à gauche”) ; D’autre part, celle de celinecelines qui a fait la démonstration d’une énergie incroyable et d’un enthousiasme peu commun, mais ô combien communicatif et stimulant. Merci Céline.

De mon coté, ça a été un peu le grand schelem. En effet, l’équipe d’organisation à accepter toutes mes propositions (‘^_^) je me suis donc retrouvé à présenter un lightning talk, une conférence et un atelier… argle !

Lightning talk

Le challenge consistait à parler d’un sujet pendant seulement 4 minutes. Ça demande d’aller droit à l’essentiel et d’être percutant. Vu que je traitai déjà de sujet assez sérieux pour ma conférence et mon atelier, j’ai proposé un “truc rigolo”. J’ai donc fait une animation SVG pour illustrer la lutte permanente des standards du Web pour un Internet meilleur. J’ai demandé l’aide de ma collègue Corinne Massacry pour réaliser tout le “Character Design” et j’ai réalisé toute les animations à la main (il n’y a pas d’éditeur d’animation SVG connu à ce jour, donc, tout à la mimine… ce qui prend un temps infinie, j’ai terminé l’animation la veille de la conf en y passant la nuit :-/)

Voila le résultat :

Vous pouvez télécharger le fichier SVG ici : http://jeremie.patonnier.net/experiences/parisweb2011/animation.svg

Pour la petite histoire, l’ensemble des éléments graphiques ont été réalisés avec Adobe Illustrator. Pour ce qui est de la réalisation de l’animation, dans le mesure où, lorsqu’on code à la main, c’est très difficile de se déplacer d’un point à l’autre de l’animation, je l’ai animée à l’envers. Concrètement, j’ai animé la dernière scène, puis l’avant dernière scène, etc. De cette manière, à chaque fois que je rafraichissais l’animation, je voyais immédiatement ce que je venais d’animer sans avoir à attendre que le début de l’animation soit joué (plusieurs minutes) pour pouvoir vérifier ce que je venais de faire (parfois moins d’une seconde d’animation)

Conférence : “La typographie, mon navigateur et moi”

Lors de cette conférence, j’ai eu l’occasion d’expliquer comment les polices typographiques sont miraculeusement affichées par les navigateurs Le coté sympa, c’est qu’à l’origine, cette conférence devait durée 30 minutes et que suite au désistement de dernière minute d’un orateur, elle a finalement pu durée 1 heure avec plein de questions et réponses. Je vous met les slides ici, mais la vidéo sera sans doute beaucoup plus intéressante. Je vous tiens au courant dès qu’elle est disponible.

Atelier : “SVG et le web design moderne”

1h30 à la découverte de SVG. Je ne cache pas que pendant l’atelier j’ai un peu angoissé en voyant les nombreux visages extrêmement sérieux et concentré en face de moi. Heureusement, il semblerai que l’atelier ait bien plus à tout le monde. Je vous met ici les slides, les exemples et les différents liens que j’ai eu l’occasion d’évoquer.

Les slides : http://jeremie.patonnier.net/experiences/parisweb2011/atelier/presentation.odp
Les exemples :
- Exemple d’un fichier SVG basic : http://jeremie.patonnier.net/experiences/parisweb2011/atelier/basic.svg
- Les différentes manière d’inclure du SVG dans du HTML : http://jeremie.patonnier.net/experiences/parisweb2011/atelier/inclusion.html
- Comparaison entre SVG, RaphaelJS et Canvas : http://jeremie.patonnier.net/experiences/parisweb2011/atelier/svg-raphael-canvas.htm
- Exemple d’usage avancé avec CSS3 : http://jeremie.patonnier.net/experiences/parisweb2011/atelier/monsieur-ou-madame-1.htm
Les liens à voir (en vrac) :
- http://raphaeljs.com
- https://github.com/wout/raphael-svg-import
- http://mbostock.github.com/d3/
- http://jvectormap.owl-hollow.net
- http://rickardsund.com
- http://discover.store.sony.com//piiq/
- http://evolutionofweb.appspot.com
- http://vlog.it
- http://type.method.ac
- http://www.goodreads.com (l’icone de “rating” est en SVG et reprend les données réelles de vote sur chaque livre)
- http://www.drawastickman.com
- http://www.nissanusa.com/leaf-electric-car/index
- https://developer.mozilla.org/en/SVG

Là aussi, la vidéo sera bien plus parlante, je vous la mettrai dès qu’elle sera là

Voila, comme d’habitude, c’était bien chouette, encore un gros merci aux organisateurs et vivement l’année prochaine (mais je proposerai moins de choses parce que là, c’était vraiment trop dur de préparer tout ça).

SudWeb 2011 : Coup d'essai, coup de maitre

Jeremie — Tue, 21 Jun 2011 09:54:00 +0200

Note for English speaker, there is an English version down below

Le 27 mai dernier, j’ai eu la chance de participer à la toute première édition de SudWeb à Nîmes. Partie sur une boutade lors du dernier Paris Web, les organisateurs se sont juste arrachés pour arriver à monter le truc en à peine 6 mois. Bravo à tous, ce fût beau ! Car on peut le dire, pour un coup d’essai, ce fût un coup de maitre. Au delà de la logistique impeccable, l’ensemble du programme des conférences était tout simplement parfait. Mixant à la fois les aspects fonctionnels, techniques et prospectifs, l’équilibre du déroulé m’a complètement estomaqué (ainsi que le respect des horaires, tenus d’une main de fer, couplé à des moments de pause ô combien conviviaux).

Vous n’y étiez pas ? Ce n’est pas grave. D’une part toutes les conférences ont été filmées et devraient être disponibles prochainement et d’autre part, il y aura une autre édition l’année prochaine, viendez-y

En ce qui concerne mon nombril, j’ai eu l’occasion d’y donner une conférence sur un sujet qui me tient à cœur depuis un peu plus d’un an : SVG. Au cours de cette conférence, j’ai montré ce qu’il était possible de faire aujourd’hui avec SVG (qui, rappelons le, est disponible dans tous les navigateurs moderne). Plutôt que de m’attacher aux questions techniques qui tourne autour de cette technologie, j’ai préféré mettre l’accent sur des outils et des résultats concrets. L’idée étant de montrer comment des designers et les développeurs on déjà utilisé SVG et ce qu’il apporte au web design moderne.

Évidemment, même si j’ai oublié de le préciser pendant la conférence, je n’ai pas pu m’empêcher de réaliser mes slides en SVG, les voici (cliquez sur l’image pour lui donner le focus et utilisez les flèches de direction pour passer d’un slide à l’autre) :

Vous pouvez accéder à ma présentation SVG à cette adresse : http://jeremie.patonnier.net/experiences/sudweb2011/presentation.svg

A noter que je cite tous les sites suivant :

Outils

http://code.google.com/p/svgweb
http://raphaeljs.com : Vous devriez tous avoir cette bibliothèque dans votre trousse à outils si vous voulez réaliser du SVG tout en étant compatible avec les vieux IE.
http://www.highcharts.com : LA bibliothèque pour faire des graphiques de données sans vous casser la tête.
http://mbostock.github.com/d3/ : D3.js est une bibliothèque qui vous permet de mapper des données au seins de graphiques vectoriels en SVG. C’est un pont technique idéal entre les développeurs qui doivent manipuler ces données et les designers qui doivent les mettre en scène.

Références

http://www.thenounproject.com : Projet mettant à disposition des icones libres de droit au format SVG. Indispensable pour réaliser de la signalétique. A noter que toutes les icones proposées sont composées d’un seul est unique chemin SVG ce qui en fait une base travail extrêmement propre et malléable pour les Web designers.
http://www.bifter.co.uk : Web comics humoristique intégralement réalisé en SVG.
http://opendata.zeit.de/pisa-wohlstands-vergleich/visualisierung.php : Le journal allemand Zeit propose une visualisation de données démographiques intégralement réalisée en SVG
http://www.nissanusa.com/leaf-electric-car/index : Dans la série “Non, ce n’est pas du Flash” Nissan USA fait une magnifique utilisation de SVG pour proposer une navigation non linéaire des caractéristiques de sa nouvelle voiture électrique. A noter que RaphaelJS est utilisé pour assurer la compatibilité avec IE6, 7 et 8 (et oui).
http://rickardsund.com : Je n’ai pas de mot assez fort pour exprimer l’adoration que j’ai pour ce site. Pour moi, Il représente la quintessence du Web design moderne. D’un coté un design épuré à l’extrême qui sert parfaitement son propos. Il est l’œuvre de Hugo Ahlberg qui a un lourd passif de designer Flash, ce qui lui a permis de s’extraire des contraintes (artificielles) du design web traditionnel. D’un autre coté, il est intégré à la perfection en utilisant exclusivement des standards Web : HTML5 (à noter en particulier la magnifique utilisation de l’API History), CSS3, JS (Du “mouse gesture” de toute beauté) et bien sur du SVG (par petites touches mais indispensables). Ce travail formidable a été réalisé par Daniel Mahal et Daniel Connor qui font là une démonstration d’excellence de ce que devrais toujours être une intégration aux standards, en particulier la maitrise de la dégradation élégante qui est quasi parfaite : Ce site fonctionne dans IE6 ! Vous DEVEZ regarder la source de ce site et vous en inspirer.

Pour conclure, je n’ai plus qu’une chose à dire : Longue vie à SudWeb, vivement l’année prochaine

On May 27th, I got the chance to attend the very first SudWeb event in Nîmes, France. Starting on a joke during the last Paris Web event, the people behind SudWeb make it possible in just 6 months. Thanks dudes that was awesome! We can say it, for a first run that was a master piece. Beyond the perfect logistic, the program was just great. Talks were amazingly well balanced between functional, technical and prospective subjects (and the schedule was perfectly mastered with good time to talk and network with people).

You wasn’t their ? Don’t worry. First, all the talks were camcorded and should be available soon. Second, there will be another edition next year, attend it

On my own, I had the opportunity to give a talk about one of my favorite subject for a year now : SVG. During this talk, I show off what is it possible to make with SVG today (which, as a reminder, is available in all modern browsers). Instead of talking about technical stuffs, I focused on tools and practical results. The idea was to demonstrate how designers and developers had used SVG and what that technology brings to modern Web design.

Of course, even if I forgot to mention it during my talk, I felt oblige to made my slides with SVG. Here there are (see above, click on the image to give it the focus then use the arrow keys to switch between the slides).

Note that I use all the following web sites as examples:

Tools

http://code.google.com/p/svgweb
http://raphaeljs.com : You should all have that library in your toolbox if you want to use SVG with IE compatibility in mind.
http://www.highcharts.com : THE library to build charts without headache.
http://mbostock.github.com/d3/ : D3.js is a library that allow you to connect data with graphics. This is an awesome bridge between developers that deal with data and designer that deal with graphics.

References

http://www.thenounproject.com : That project collect visual symbol and make them available in SVG. Note that all the symbols are made of one single SVG path. That make them highly usable as a work basis for Web designers.
http://www.bifter.co.uk : A humorous Web comics build with SVG.
http://opendata.zeit.de/pisa-wohlstands-vergleich/visualisierung.php : The dutch newspaper Zeit had a demographic data representation driven by SVG.
http://www.nissanusa.com/leaf-electric-car/index : Ok, so “This is NOT Flash”. This is a great SVG work made by Nissan USA to build a non-linear navigation system. Take care about the library behind the scene, it’s RaphaelJS. This means that it works properly even with IE6, 7 and 8 (crazy!).
http://rickardsund.com : I do not have strong enough words to express my love for this web site. To me, it’s the best of modern Web design. On the one hand, the simplistic design suits its subject perfectly. It has been made by Hugo Ahlberg who has extensive skills in Flash design. Those skills give him the ability to overcome the classic HTML web design. On the other hand, This Web site is perfectly develop with Web standards only : HTML5 (with a noticeable use of the History API), CSS3, JS (awesome mouse gesture) and, of course, some small (but essential) touches of SVG. This amazing work has been done by Daniel Mahal and Daniel Connor who demonstrate what a Web standards front-end development should always be. They especially mastered the graceful degradation: This site works perfectly with IE6 ! You SHOULD look at the source and use it as an inspiration.

To conclude, there is one thing left : Live long SudWeb, I strongly hope for the next edition

Alors s'en vient le temps du changement.

Jeremie — Wed, 13 Apr 2011 11:59:00 +0200

Je sais que je blogue assez peu en ce moment. Ne m’en veuillez pas, c’est qu’il se passe pas mal de choses actuellement pour moi avec peux de temps pour venir écrire ici.

D’abord, si vraiment vous voulez lire des trucs que j’ai écrit moi-même comme un grand, allez faire un tour sur typographisme.net, mon dernier billet en date parlant des ligatures dans les navigateurs.

En suite, je suis en train de préparer ma présentation pour SudWeb 2011. Comme je vais y parler de SVG, je ne peux bien sur pas faire autrement que de préparer un support de présentation lui aussi en SVG (il sera en ligne après la conf). Ça se passe le 27 mai à Nîmes, le programme est alléchant et le prix raisonnable, n’hésitez pas à venir y faire un tour.

Enfin, je change de travail Après 5 ans passé au sein de Cetelem (organisme de crédit pour les particulier du groupe BNP Paribas) en temps que responsable d’équipe de développement web, je vais rejoindre CleverAge où je serais consultant web (ou chef de projet ça dépendra des clients et des missions ). C’est prévu pour le 2 mai et en attendant, c’est un peu “je cours dans tous les sens pour plier les questions administratives”.

Sur ce… qu’un millier de colombes constipées illuminent votre journée.
A bientôt

Why are SVG Fonts so different?

Jeremie — Mon, 07 Feb 2011 09:30:00 +0100

Une version française de cet article est disponible sur typographisme.net : Pourquoi les fontes SVG sont-elles différentes des autres ?

I’m sad to see that there are many misconception about SVG fonts. I’ve read a lot of articles and complains about the SVG font format and the last (but not the least) was an article from Alexander Limi explaining why Firefox will not pass the Acid3 test mainly due to a lack of SVG font support. All those complain are misplaced in many way because SVG fonts are misunderstood. Really? But in this case, what are SVG fonts made for? Let’s see that.

Forget it for regular text

One of the biggest misconceptions about SVG fonts is thinking that this format is suitable for regular HTML text. Unfortunately, it is not! In my opinion, this misconception is mainly due to Apple. Until iOS 4.2, SVG was the only format available to use custom fonts on iPhone and iPad. And because this support was (is?) somewhat buggy, SVG fonts’ reputation was badly injured.

Anyway, beyond iOS SVG font support, it’s a fact that SVG font format does not support font hinting. To understand that so called “lack” it’s important to think back about the specificity of the SVG image format. SVG shapes are placed in an absolute coordinate system and SVG documents do not have text flow ability such as HTML documents. Also, SVG documents do not necessarily have pixel perfect dimensions and the shapes can be subjected to mathematical transformations (rotation, scaling, skewing, etc.). So this means that a glyph can be placed anywhere in a document and its shape modified, but most of the time it won’t match a pixel perfect size nor even a pixel perfect grid. With all those constraints, hinting is not really helpful because it needs a pixel grid system to give its best.

If you simply try to use a WOFF font in an HTML document and apply a CSS3 2D transform, you’ll see that even with a hinting system, this does not really make a difference. But on the contrary, on regular HTML text that is pixel perfect positioned, SVG fonts are not so beautiful especially at small size. So yes, in an HTML document, SVG fonts are poor. But, as I said, it’s not their main purpose.

The power of drawing tools

In regards of other fonts formats, one of the biggest advantages of SVG fonts is the way shapes can be drawn.

Technically speaking, the shapes in SVG fonts can be made of any kind of curves (cubic or quadratic Bezier in different flavors or arc definitions) where shapes in TrueType fonts can only be made of quadratic Bezier curves. OpenType fonts are a bit smarter by supporting cubic Bezier curves, but for what I know no other font format supports arc definition. So, in theory the outlines produced for SVG fonts could be much more optimized than in other font formats. Ok, let’s be honest, it is not often the case in classical glyph design. But there is more. Because SVG fonts could use all the power of SVG it is possible to draw very complex shapes by mixing arbitrary paths and basic SVG shapes, which gives you a more control over your font design. So when you want to design an ornamental font, SVG gives you better tools to do so.

Practically speaking, it’s possible to use any software supporting SVG to draw fonts. This includes traditional font software such as FontForge but it’s also possible to take full advantage of drawing software such as Adobe Illustrator or Inkscape (this one provides powerful tools for drawing fonts). Of course such drawing software can be used to produce outlines for other font formats but you’ll always need to export them inside a specific font tool to convert those outlines to the right curves definition (which can have side effects on your design). With SVG, you don’t need to. You can directly use the output from your drawing software.

Animation, filters, video… \o/

Let’s go forward. SVG, beyond its drawing ability, has some amazing extension such as gradients, patterns, clipping, masking, animations, filters or even foreign object inclusion. It means that you can use all of this inside your SVG fonts. Yes it’s possible to produce native animated font with SVG. With filters, you can produce blurry or textured fonts. And with foreign object inclusion… Wow ! There’s no limit. Why not imagine a font with a sound background? Yes it’s possible, just include an HTML audio element and it’s done.

Of course it’s not necessarily wise to do such things. Especially if you want to use such a font for regular text. But think about it. The SVG font format unleashes your creativity to a brand new world. Say good-bye to the legacy “lead & paper” typography and jump out the final frontier with the upcoming of fonts made FOR the web (and not just backported to it).

Embedding and DOM Access

You think it’s amazing? Let’s go one step further in the twilight zone.

Historically speaking, ten years ago, SVG font was the only font format that could be embedded inside an SVG document. This feature was required to ensure that the rendering of a font inside an SVG document would remain consistent across different platforms and user-agents. Today, thanks to CSS @font-face and Data URI, it’s possible to embed any type of font format, but still, SVG fonts have always a huge advantage here.

As you know, SVG is an XML format so SVG font as well. This means that you can embed SVG fonts inside any XML document (for example in an SVG image or in an XHTML document and, in a near future, with HTML5, in any ordinary HTML document) and still have access to the glyphs through the DOM of the XML document. And this is huge because it means two crazy things:

You can easily access the font content through Javascript and change it as you wish for whatever reason. The SVG font format lets you in control of each individual glyph at runtime.
You can use CSS to style each individual glyph which gives you an amazing control on how the font will be rendered.

The other font formats do not provide such an easy and full access to their core design.

Security, accessibility, bla, bla, bla…

With such great power come amazing responsibilities. Security is one of the main concerns about SVG fonts. As Borris Zbarsky points out : Once you put an <iframe> in a glyph, all sorts of issues arise and is damn right. This point have to be discussed but is it a reason to drop everything? I don’t think so.

Another concern is about accessibility - so highly interactive fonts raise many issues, for example “how the user can control the animation on an animated font?”. But these questions are basically of the same type as those SVG brings on its own. So it’s possible to rely on the solutions available for SVG in a general purpose.

Of course it’s necessary for both browser constructors and web authors to take care about all those constrains. I’m sure some evil web authors will use SVG fonts badly, sure that browser vendors (all of them) do not presently do their best to support SVG fonts. So be it - but I think that SVG fonts are a real turning point in the history of typography and should be taken for what they really are: an amazing tool to bring fresh design ideas in typography and cool typography in web design. And it’s important to remember that SVG fonts do not play the same game as WOFF fonts on the web. Both formats have their strengths and weaknesses but there are not mutually exclusive.

SVG et HTML5 font bon ménage avec Firefox

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

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

Les premiers seront les derniers

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

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

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

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

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

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

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

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

Mais pourquoi, John ? Pourquoi ?

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

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

Bouger ou ne pas bouger, tel est la question

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

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

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

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

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

One piece to rule them all

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

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

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

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

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

Quelques explications sur cette arborescence :

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

T'as d'beaux yeux tu sais !

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

Pimp my mouse

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

svg{
    pointer-events : none;
}

svg canvas{
    pointer-events : auto;
}

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

Ombrage, ô désespoirs !

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

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

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

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

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

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

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

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

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

Allo ! Caroline ! C'est Roger.

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

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

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

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

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

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

data = JSON.parse(data);

Parfois, c'est le vil coyote qui gagne

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

Is there a Road Runner over here?

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

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

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

Robert ! Il y a un cafard dans la machine.

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

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

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

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

Allo ! Tonton ? Pourquoi tu tousses ?

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

Canvas pas aller ça monsieur.

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

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

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

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

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

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

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

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

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

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

Le mot de la fin (des haricots)

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

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

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

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

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/Introduction-a-SVG#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/Introduction-a-SVG#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)