Image classique, SVG ou canevas ?

Bonjour à tous,

Pardonnez-moi de venir vous poser une question hautement stupide, mais je m'interroge. Et puis, le vendredi, c'est permis !

A la suite de ce sujet: http://forum.alsacreations.com/topic-6-71937-1-Articleen-accessibilite-SVG.html et du lien qui y a été posté, Je me pose quelques questions sur SVG. Je n'ai pas continué sur le dit sujet car mes questions sont d'ordre beaucoup plus général que seimplement l'accessibilité.

Je note que les points forts généraux de SVG face aux images classiques sont :
* Possibilité de manipuler le DOM à l'intérieur de l'image pour faire des effets dynamiques
* Possibilité de faire des animations et des zones interactives
* Possibilité de dessiner des formes simples très facilement sans logiciel de dessin
* Image toujours nette quelque soit sa taille (pas d'effets type pixélisation; et donc très bien pour les malvoyants comme dit dans l'article)

Du coup je me demandais si ça valait la peine d'opter pour SVG plutôt que pour de l'image classique (PNG ou GIF), ou si au contraire il ne fallait surtout pas oser SVG, dans les cas suivants (même question mais réponses indépendantes pour les trois) :
1 - Icônes et symbolique d'interface, p.ex. drapeau de langue, vu/croix, flèches, boutons d'outils, etc.
2 - Représentation d'un tableau de jeu en de nombreuses images individuelles, p.ex. échiquier avec ses pièces
3 - Graphique en barre ou en camenbert, tracé de fonction etc.

En particulier, je me demandais ce qu'il en était des performances :

Construire un DOM c'est excessivement lent; donc si on ne prévoit pas de le modifier intérieurement, est-ce que ça a vraiment un intérêt ? Qu'est-ce qui se passe si on a 100 ou 1000 images et donc 100 ou 1000 DOM à construire ?

En gros, si on ne prévoit pas de faire d'animation ni de zone réactive à l'intérieur même des images, vaut-il mieux
* 100 images classiques <img alt="..." /> et on arrête de se prendre la tête inutilement
* 100 images SVG avec <img />
* 100 images SVG avec <object>
* 100 images SVG inline avec <svg>

Question subsidiaire n°1: la taille de fichier petite du SVG est-elle un mythe ou une réalité ? parce qu'il me semble que le PNG se défend drôlement bien pour les images qui ont peu de couleurs et des délimitations assez marquées (genre pas d'ombre, fondus, effets de transparence, et autres). A l'inverse le XML est rapidement très verbeux.

Question subsidiaire n°2: et canevas dans tout ça, ou est-ce que ça se positionne ? Canevas est un trou noir pour l'accessibilité donc je ne vais pas l'utiliser, mais je suis quand même intéressé d'avoir une réponse.

Désolé de balancer un troll aussi vaste un vendredi soir ! Si personne ne comprend rien à ce post, il s'auto-détruira de lui-même dans quelques jours, pour m'excuser d'avoir demandé quelque chose d'aussi idiot.

Merci pour vos réponses.
Modifié par QuentinC (16 May 2014 - 20:56)

Bonjour,

ça ne me parait pas idiot du tout, je suis également en train de me poser la question (sous une autre forme, mais le fond se rejoint).

Concernant les performances, sans avoir de réponses précises, voilà ce que je peux dire :
- 100 png chargés, ça fait 100 requête HTTP de plus. Niveaux perfs, je crois que c’est la pire chose imaginable (les sprites peuvent nous sauver tous, mais ça ne colle pas toujours à l’utilisation concrète des images) ;
- un SVG inline, peu importe son « volume » en terme de DOM, sera mis en cache navigateur et potentiellement gzippé. Côté performance, même en alourdissant grandement le DOM, je pense que par rapport aux autres hypothèses ce sont des avantages très importants.

Je me penche actuellement sur des questions de SVG interactifs pour générer des diagrammes, camemberts, etc. et il s’avère que le SVG inline est très simple à manipuler, et rapide en terme de rendu (par forcément côté script etc.) puisqu’il suffit de manipuler certaines coordonnées du tracé. On n’ajoute ni ne supprime de nœud du DOM (dans mon cas) et on modifie seulement les coordonnées, et ça s’avère très efficace.

Dans mon cas je suis certain que c’est la meilleure option, mais de là à généraliser…

Hors de mon cas d’usage il est également possible de créer des sprites avec SVG, de différentes manières, et pour les icônes symboliques par exemple il est envisageable de faire ça. Je le fais sur mon blog (à petite échelle donc rien de quantifiable) mais si je perds peut-être un peu côté performances, la qualité est nettement meilleure dans la quasi-totalité des configurations.

Réponse subsidiaire n°1 : En effet dans le cas d’un sprite monochrome sur fond transparent, le png est moins lourd (environ 30% de moins, dans mon cas).

Réponse subsidiaire n°2 : j’ai moi aussi snobbé canvas pour les mêmes raisons, et ne peut donc pas vraiment aider.
Modifié par Ten (17 May 2014 - 09:41)

a écrit :
- 100 png chargés, ça fait 100 requête HTTP de plus. Niveaux perfs, je crois que c’est la pire chose imaginable (les sprites peuvent nous sauver tous, mais ça ne colle pas toujours à l’utilisation concrète des images) ;

J'ai pas du tout pensé au nombre de requêtes HTTP... c'est effectivement bien vu. Encore que normalement, les navigateurs travaillent tous en HTTP/1.1 et donc peuvent télécharger plusieurs fichiers en même temps sur la même connexion TCP ou au moins n'ont pas besoin d'une connexion distincte par fichier; donc logiquement ça ne devrait plus être un gros problème. Mais peut-être que je me méprends totalement et que HTTP/1.0 est toujours la majorité ? J'avoue ne pas m'amuser à vérifier la version du protocole utilisée, ni sur mes sites, ni ailleurs.

Le problème avec les sprites, si j'ai bien compris, c'est que ça doit nécessairement se faire via des bakcground CSS. Suivant la situation, ça peut être bien ou pas bien pour l'accessibilité. Pour des images purement illustratives et passives c'est très bien que ça n'apparaisse même pas en HTML; pour les images réactives ou faisant office de liens/boutons, ça oblige à faire des entourloupes dégueulasses (et pas toujours bien supportées, ou pas à toute épreuve) pour rester accessible.


Merci; j'attends d'autres avis.

Salut,

QuentinC, ne détruis surtout pas cette discussion, qui survit très bien au vendredÿ.

Il y a un autre avantage à utiliser les SVG, qui n'a pas été cité et qui est, pourtant, essentiel : on ne s'enquiquine pas à devoir servir plusieurs versions d'une même image pour tenir compte de la variété des résolutions d'écran (écran Retina d'Apple, écran des smartphones comme le Galaxy S4 ou S5…), grâce aux tracés vectoriels.

Quant à la question de la maintenabilité de la manipulation de plusieurs images SVG, n'oublions pas qu'un document SVG peut se voir utiliser une feuille de style externe : la balise <?xml-stylesheet?> est là pour ça. Ainsi, plusieurs images SVG devant avoir des éléments de présentation communs peuvent se baser sur une même CSS, à l'instar des pages HTML ; et si la CSS destinée au SVG est générée au moyen d'un pré-processeur comme Sass, je vous laisse imaginer les merveilles. Je pense qu'il doit en être de même pour la manipulation du DOM en JavaScript, via l'élément script (auquel cas l'attribut xlink:href fait office d'attribut src).

J'irai même plus loin : si vos SVG doivent avoir une gueule différente en fonction de vos points de rupture, vous pouvez même faire du SVG responsive. Je vous recommande la lecture du très bon article qu'Ilya Pukhalski a publié sur Smashing Magazine, intitulé Rethinking Responsive SVG.

En ce qui concerne l'accessibilité, si le SVG en question véhicule de l'information, n'oubliez pas de renseigner les éléments title et desc (title pour donner une courte description du SVG, desc pour en donner une description détaillée, sachant que l'élément desc est actuellement mieux pris en charge que l'élément title par les technologies d'assistance), l'attribut aria-label pouvant également être utilisé au niveau de l'élément racine svg. En revanche, si le SVG est purement décoratif, ni title ni desc ni aria-label ni aria-labelledby ni aria-describedby.

Si vous embarquez votre SVG dans un élément object (pratique pour fournir un fallback en PNG à destination des versions d'IE antérieures à la 9 et de celles du navigateur Android antérieures à la 3) et que vous voulez que ce SVG soit cliquable (intégration dans un lien), n'oubliez pas d'englober toute la structure SVG dans un élément rect dont les dimensions sont celles du SVG et auquel vous appliquez la déclaration CSS fill: transparent. Ainsi, la main du curseur s'affichera bien au survol du SVG, et pas seulement sur les tracés dudit SVG ; seule ombre au tableau : Opera Presto (du moins Opera 12.1) applique un fond noir au SVG au lieu de respecter la transparence (en revanche, pas de souci sous Opera Blink, du moins sous la dernière version).

Enfin, si vous exportez vos SVG depuis Illustrator (en tâchant de suivre les conseils de Stéphanie), Illustrator génère un code SVG syntaxiquement valide (du moins Illustrator CS 6).

Bref, SVG, c'est bon, mangez-en !

Bonjour,
Pour ce qui est de l'alternative au sprite, on peut stylé directement des éléments ou groupe d’éléments et faire des trucs comme ça avec même une transition, impossible a partir d'un sprite classique : http://jsfiddle.net/ZBb6D/show/

on peut résumer le test a ceci :

svg:hover #cup{
  opacity:1;
  transition:1s;
}
svg:hover #plate , #cup{
  opacity:0;
    transition:1s;
}

pour un SVG qui contient là, 2 icônes.

Avec l'avantage de supporter le redimensionnement http://jsfiddle.net/ZBb6D/1/ , mais le defaut d'une compatibilité réduite aux récents navigateurs et une dépendance au style pour l'affichage
Modifié par gc-nomade (18 May 2014 - 13:18)

Bonjour,

a écrit :
Du coup je me demandais si ça valait la peine d'opter pour SVG plutôt que pour de l'image classique (PNG ou GIF), ou si au contraire il ne fallait surtout pas oser SVG, dans les cas suivants (même question mais réponses indépendantes pour les trois) :
1 - Icônes et symbolique d'interface, p.ex. drapeau de langue, vu/croix, flèches, boutons d'outils, etc.
2 - Représentation d'un tableau de jeu en de nombreuses images individuelles, p.ex. échiquier avec ses pièces
3 - Graphique en barre ou en camenbert, tracé de fonction etc.

1. icones : je dirais svg (icones accompagnées de texte, caché ou pas)
car le svg sera adapté à tous les types d'écran (hd 2x 3x ... ou pas).
grunticon / grumpicon est une solution intéressante pour la mise en place (les icon fonts sont une autre solution mais on oublie souvent que le support pose problème : opera mini...)

2. échiquier avec ses pièces : je n'y connais pas grand chose en jeux mais pour un jeu "simple" (comprendre sans nombreux déplacements et visuels limités en nombre) svg semble adapté, un échiquier en svg c'est quelques lignes (1 <rect> défini 1 fois puis utilisé avec <use> ou même un pattern). Pour ce qui est de l'animation, le déplacement, javascript permet de manipuler les pièces (<g> en svg) et de les déplacer sur l'échiquier.
Canvas serait également une option et quelques bibliothèsques supportant svg & canvas permettraient de combiner les 2.

3. graphiques : svg semble très adapté: un graphique en barre est composé de <rect> en svg et la hauteur correspond à la valeur à représenter.
Mais, cela dépend des graphiques à représenter. Si c'est toujours le même "en dur" une <img> svg (avec fallback onerror pour charger un png) fera l'affaire.
Si on veut un effet au survol c'est envisageable avec un <object> (qui offrira un fallback intégré comme l'a signalé Victor)
Pour des choses plus complexes (changement de représentation des données, de "en barre" en camembert par ex. ou graphiques "intéractifs") canvas serait peut-être à envisager.
Pour l'accessibilité le svg permettra de fournir un texte alternatif (alt, longtesc pour <img>, texte à l'intérieur de <object>) ; une autre solution serait de transformer un tableau de données (<table>) en graphique grâce à javascript. Là le choix canvas / svg dépendra certainement des performances de calcul et rendu, a priori avec un avantage pour canvas (à voir au cas par cas quand même)



Bref, comme toujours "ça dépend", on doit toujours faire des choix : support navigateur, accessibilité, performances (chargement), performances de rendu etc.
Le gros avantage de svg c'est qu'il est vectoriel (pas besoin de x versions de la même image pour satisfaire les écrans HD...), c'est un format texte donc il se gzippe très bien, il est manipulable en js.
Les inconvénients : le support navigateur, quand supporté les différences entre navigateurs (chrome et ie pixelise les svg en background css... un comble ; firefox est chatouilleux avec xlink pour des raisons de sécurité etc.)


Pour la taille par rapport à un png : jpeg, cela dépend (oui, encore) il n'y a pas de règle absolue.
Il faut penser à "nettoyer" le svg (enlever le code inutile mis par illustrator ou inkscape) ou outil comme SVGO peut être utile. Il faut comparer la taille des fichiers optimisé (gzip pour svg et après imageoptim ou autre pour jpeg/png)
En général, plus les formes sont simples, plus svg est avantageux.


Quelques ressources:

présentation très complète sur svg (workflow, outils) : https://docs.google.com/presentation/d/1CNQLbqC0krocy_fZrM5fZ-YmQ2JgEADRh3qR6RbOOGk/edit?pli=1#slide=id.g272ed8bf3_00 (malheureusement pas très accessible google docs)

spritemaps avec callback : https://github.com/jonathantneal/svg4everybody (l'avantage du inline svg en minimisant la quantité de code à intégrer et améliorant le cache et prise en compte de l'accessibilité)

grunticon dont j'ai parlé : https://github.com/filamentgroup/grunticon pour les icones (css background et fallbacks) et grumpicon (outil en ligne) http://www.grumpicon.com/
Ils (filament group) travaillent à une version de grunticon qui utiliserait du inline svg, à suivre...

a écrit :
Quant à la question de la maintenabilité de la manipulation de plusieurs images SVG, n'oublions pas qu'un document SVG peut se voir utiliser une feuille de style externe : la balise <?xml-stylesheet?> est là pour ça. Ainsi, plusieurs images SVG devant avoir des éléments de présentation communs peuvent se baser sur une même CSS, à l'instar des pages HTML ;

Est-ce que ça signifie qu'on pourrait avoir une seule image SVG et choisir par exemple dynamiquement sa couleur, en la passant comme variable quelque part ?
Ca serait par exemple utile de passer la couleur de base quelque part et ensuite demander à SVG de faire des calculs genre la couleur de cette autre forme là-bas c'est la moyenne entre 75% de couleur de base et 25% de noir. ON peut ça ?
Exemple concret, si je lui donne la couleur de base #ff0000 (=rouge), il déduit #c00000 automatiquement
et si je décide de changer pour #0000ff (=bleu), vraisenblablement suite à une action, il recalcule automatiquement #0000c0 et met à jour sans avoir rien à faire d'autre.

Ca vous paraît sûrement un peu étrange comme question, désolé. Mais ça serait un moyen malin de construire un graphique, ou pour un jeu ou la seule différence entre soi et son adversaire, c'est la couleur différente des objets.

Ca permettrait peut-être d'avoir le choix des couleurs... très très intéressant quand on est malvoyant.

a écrit :
2. échiquier avec ses pièces : je n'y connais pas grand chose en jeux mais pour un jeu "simple" (comprendre sans nombreux déplacements et visuels limités en nombre) svg semble adapté, un échiquier en svg c'est quelques lignes (1 <rect> défini 1 fois puis utilisé avec <use> ou même un pattern). Pour ce qui est de l'animation, le déplacement, javascript permet de manipuler les pièces (<g> en svg) et de les déplacer sur l'échiquier.
Canvas serait également une option et quelques bibliothèsques supportant svg & canvas permettraient de combiner les 2.

Utiliser un seul canevas pour un échiquer entier, je sais déjà que c'est une très mauvaise idée: c'est impossible de rendre accessible (ou alors on construit une usine à gaz ingérable à base d'ARIA & co). Mais alors du coup 64 canevas différents, ça n'a pas trop d'intérêt face à SVG finalement; sauf si on dessines tout en live en js plutôt que de préparer des images à l'avance; Et dessiner tout en live en js me paraît beaucoup plus compliqué à concevoir et à tester.

a écrit :
Il faut penser à "nettoyer" le svg (enlever le code inutile mis par illustrator ou inkscape) ou outil comme SVGO peut être utile.

Question outils, pas besoin de trop épiloguer, je vais basiquement m'amuser à la main et faire des trucs de toute façon très simples. Je cherche pas à faire compliqué, juste accessible et suffisament utilisable. Si c'est un peu moche et très carré genre 90s je m'en fiche, c'est pas la beauté que je recherche.

Je vais vous dire quelqeu chose que vous savez déjà sûrement ou qui va peut-être vous surprendre sinon (en tout cas les plus habitués le savent déjà), je suis non-voyant et utilisateur de lecteur d'écran; le seul vrai moyen que j'ai de dessiner quelque chose, c'est à base de formes très simples; je ne vois pas les détails de toute façon. En cela, SVG peut être vu comme une petite révolution en fait: quelques minutes et un peu de réflexion pour faire quelques formes basiques à peu près utilisables, lä où il faudrait trois fois plus de temps pour le faire à la souris, au doigt ou au crayon.

C'est malgré tout intéressant, et finalement pas étonnant, de constater que les programmes de dessin insèrent du code inutile; ça valait le coup d'être rappelé je pense.


Du coup SVG ça paraît vraiment être un bon truc. Et puis la compatibilité IE8, à la rigueur, tant pis

QuentinC a écrit :
Est-ce que ça signifie qu'on pourrait avoir une seule image SVG et choisir par exemple dynamiquement sa couleur, en la passant comme variable quelque part ?
Ca serait par exemple utile de passer la couleur de base quelque part et ensuite demander à SVG de faire des calculs genre la couleur de cette autre forme là-bas c'est la moyenne entre 75% de couleur de base et 25% de noir. ON peut ça ?
Exemple concret, si je lui donne la couleur de base #ff0000 (=rouge), il déduit #c00000 automatiquement
et si je décide de changer pour #0000ff (=bleu), vraisenblablement suite à une action, il recalcule automatiquement #0000c0 et met à jour sans avoir rien à faire d'autre.

Pourrais-tu reformuler ta question ? Je crains de n'avoir rien compris.

Oui c'est possible en JavaScript ou avec des instructions CSS, notamment si le code SVG est placé en ligne dans le code HTML avec la balise SVG.

a écrit :
Pourrais-tu reformuler ta question ? Je crains de n'avoir rien compris.

Disons par exemple que j'ai un unique fichier SVG de base qui contient ça :

<?xml version="1.0" encoding="utf-8"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="100" height="100">
<rect x="25" y="25" width="75" height="75" fill="0.75*$base + 0.25*black" />
<rect x="0" y="0" width="75" height="75" fill="$base" />
</svg>

AVec bien sûr la vraie syntaxe à la place de mon invention dans les attributs fill.

A un moment, je veux fixer $base = #ff0000, et si on veut, le fichier deviendrait automatiquement :

<?xml version="1.0" encoding="utf-8"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="100" height="100">
<rect x="25" y="25" width="75" height="75" fill="#c00000" />
<rect x="0" y="0" width="75" height="75" fill="#ff0000" />
</svg>

Et à un autre moment, je veux changer le rouge en bleu , alors je change la valeur de $base en #0000ff et alors le fichier devient :

<?xml version="1.0" encoding="utf-8"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="100" height="100">
<rect x="25" y="25" width="75" height="75" fill="#0000c0" />
<rect x="0" y="0" width="75" height="75" fill="#0000ff" />
</svg>

Ce que je demande, c'est si cela est possible avec CSS, ou avec une seule manip DOM en js, ou s'il faut faire un script js complet et compliqué qui devra savoir les couleurs à recalculer et celles à garder telles quelles.
J'ose imaginer que s'il faut faire un script compliqué et qu'il faut changer les couleurs de chaque forme une à une, la vitesse d'affichage risque d'être affreusement lente et à ce moment-là il vaudra mieux regénérer une autre image côté serveur (vu que le browser par définition ne peut pas comprendre ce que fait js, et qu'il va s'amuser à repaindre à chaque petite modif pour des prunes)
Tiens d'ailleurs, s'il faut faire un script compliqué, est-ce que c'est seulement possible de passer des variables via des attributs data-* ou autre procédé ?