Des SVG qui donnent l’impression d’être des GIF

• Les images SVG animées conservent une haute résolution tout en ayant une taille de fichier très faible (49 KB)
• Elles produisent un effet visuel proche d’un GIF classique, mais reposent en réalité sur les fonctions d’animation SVG
• Elles peuvent être utilisées directement dans les fichiers README.md de GitHub
• Avec les outils asciinema et svg-term-cli, il est possible d’enregistrer une session terminal puis de la convertir en animation SVG
• Elles exploitent les éléments d’animation de SVG (<animate>, <animateTransform>, <animateMotion>)

---

Caractéristiques des SVG animés

• Les images animées créées en SVG ressemblent à des GIF classiques, mais utilisent en réalité les capacités d’animation vectorielle de SVG
• Cette approche permet une taille de fichier très réduite et un redimensionnement ou zoom sans perte de qualité
• Le fait de pouvoir les utiliser directement dans des endroits comme le README.md de GitHub constitue un gros avantage
• L’exemple présenté montre un perroquet animé en SVG haute résolution d’une taille de 49 KB

Méthode de création

• Une session terminal est enregistrée avec asciinema
• Le fichier asciinema enregistré est converti en fichier d’animation SVG à l’aide de l’outil svg-term-cli
• Le fichier SVG généré peut être facilement ajouté dans un README.md
• L’auteur utilise activement cette approche dans plusieurs projets, notamment bespoken

Principe de fonctionnement de l’animation SVG

• La spécification SVG intègre déjà des fonctions d’animation
  • <animate> : anime des attributs individuels au fil du temps
  • <animateTransform> : permet d’appliquer des animations de transformation comme la rotation, le redimensionnement ou le déplacement
  • <animateMotion> : déplace un objet le long d’un chemin
• svg-term-cli fonctionne en s’appuyant sur ces fonctions d’animation intégrées à SVG

[GN⁺]

Avis Hacker News

• Je suis émerveillé par tout ce qu’on peut faire d’impressionnant avec du simple SVG. Parmi les exemples trouvés sur Wikipédia, on remarque notamment un clone animé de Missile Command, le plan du métro de Londres et une animation de rolling shutter

  • Le SVG a commencé à l’origine comme concurrent open source de Shockwave/Flash Player, ainsi que comme format d’application pour PDA. Il est aussi mentionné que l’ajout d’un support réseau avait réellement été envisagé

  • Si le plan du métro de Londres est si impressionnant, c’est parce qu’il indique les « stations sans escaliers » pour les personnes à mobilité réduite, comme les usagers en fauteuil roulant. En voyant le premier exemple avec les missiles, j’ai immédiatement pensé à programmer un moyen de cliquer sur les ogives, avec cette impression d’avoir sauvé le monde

  • Je me demande pourquoi le premier lien Missile Command ne fonctionne pas correctement dans Safari. On peut cliquer sur les boutons, mais pas sur les ogives. Dans Firefox, on voit même le curseur en forme de réticule, alors que dans Safari, quelque chose ne va clairement pas

  • La fonction de cases à cocher sur le plan du métro est vraiment géniale. Ça me motive à améliorer davantage mes compétences en SVG. Bookmarké

  • En voyant seulement le titre de l’article, j’ai cru qu’il s’agissait d’un outil qui affiche visuellement le hash d’un fichier README, mais j’espère qu’un tel type de visualisation permettrait aux utilisateurs de repérer facilement quand des TOS ou EULA changent discrètement

• J’ai déjà développé un système qui intègre un SVG animé dans un README, et ce SVG mettait à jour une fois par jour la météo et le jour de la semaine. Référence. En réalité, c’est un projet que j’avais créé il y a quelques années pendant une période de convocation comme juré

• Si la cible est un README Github, on peut aussi intégrer directement une vidéo. Exemple avec le README de git-recent. Cela dit, pour une simple capture de terminal, utiliser la méthode SVG de l’OP peut être un choix plus malin

  • L’avantage de la vidéo, c’est qu’elle fournit une UI de lecture/pause et un curseur. Certaines plateformes ajoutent aussi une UI de contrôle aux GIF via JavaScript, mais comme ce n’est pas pris en charge nativement par le navigateur, ça reste limité. C’est pour ça que je préfère parfois la vidéo. Quand je fais des animations SVG pour RevealJS, je les pilote selon les besoins avec du CSS/JS

  • Si on ajoute un fichier vidéo, le téléverser en éditant directement le README sur Github, ce qui le stocke sur githubusercontent, est aussi un meilleur choix pour la taille du dépôt

  • Le SVG diffère aussi de la vidéo par sa capacité à réagir aux préférences clair/sombre de l’utilisateur. Il prend également en charge l’adaptation à la taille, ce que la vidéo ne peut pas faire. Voici une démo associée. Cela dit, même cette fonctionnalité marche bien dans Firefox/Chrome mais reste délicate à implémenter dans Safari, ce qui est regrettable

  • Ça fait longtemps que je n’avais pas vu mentionner Paul, et ça me rappelle avec affection ses anciens travaux autour d’Echo Nest et de l’API Rdio

  • À mon avis, pour une capture de terminal, l’approche SVG manque de fonctions de contrôle et est donc peu pratique. Ça peut bien marcher pour une courte démonstration animée de 5 secondes environ afin de présenter un logiciel, mais selon le besoin, la vidéo peut être meilleure

• Le fait qu’on puisse directement copier le texte depuis l’animation n’est pas forcément intuitif, mais ça me semble être la fonctionnalité la plus cool

  • Ce serait encore plus intéressant si l’animation pouvait se mettre en pause au survol de la souris. Mais si le terminal défile, les fonctions copier/coller deviennent aussi plus difficiles à exploiter, ce qui rend l’ensemble plus délicat

• Point d’attention : certains fichiers SVG contiennent des bugs qui peuvent figer une page. Il vaut donc mieux éviter d’intégrer des liens vers des SVG tiers. Ni Google Chrome ni Firefox ne prévoient de corriger ce bug. Un exemple de SVG dangereux pour test est joint, mais cliquer dessus peut faire planter le navigateur

  • Le fait qu’une page ou un navigateur se fige ne relève pas forcément d’un problème de sécurité ; cela peut aussi arriver de façon générale via l’abus de diverses fonctions intégrées. Par exemple, une longue chaîne de filtres de flou peut surcharger le rendu au point de faire geler Chrome lui-même. Si l’impact dépasse l’onglet, c’est évidemment plus grave, mais de base cela ressemble plutôt à un problème d’ergonomie de l’UI

  • Je me demande si ce type de vulnérabilité SVG, comme les attaques XXE, est aussi possible dans un environnement restreint comme un README Github. Si oui, je me demande comment cela est bloqué

• Le fait que « le SVG soit intrinsèquement animé » me paraît très neuf et me fait imaginer plein d’idées. Je me demande si la boucle infinie est prise en charge

  • Avec les attributs repeatCount ou repeatDur de la balise <animate> réglés sur indefinite, on peut boucler à l’infini. Comme la répétition s’applique par propriété individuelle, chaque élément de l’image peut bouger selon son propre rythme

  • Exemple de code visible dans la documentation officielle des animations SVG

  • Il est aussi mentionné qu’en plus des animations basées sur les attributs, le SVG peut embarquer de l’Ecmascript (Javascript), ce qui permet d’y ajouter par script n’importe quelle fonctionnalité selon les besoins. Voir la documentation W3C sur les scripts

  • Un échantillon de code et des exemples d’animation SVG sont également partagés. Certains se voient au rechargement de la page

• Je rêve d’un système où l’on pourrait un jour brancher dans le navigateur n’importe quel moteur d’exécution — WASM, JVM, CLR, etc. — avec une sortie en SVG (texte/binaire). L’idée serait que les développeurs puissent librement choisir la combinaison entre modèle d’exécution et vue, sans être attachés au DOM, pour une véritable innovation future

  • Des apps comme AutoCAD Web, Photopea, Figma, Google Docs, Google Earth Web ou Flutter for Web(CanvasKit) sont déjà assez proches de cette approche, en contournant le DOM ou en choisissant un autre moteur de rendu. Autrement dit, nous ne vivons déjà plus dans un monde où seul le DOM est imposé

  • Par le passé, des runtimes tiers comme Flash, Java, Silverlight ou ActiveX dominaient le web, mais aujourd’hui je reste convaincu que l’avantage réside dans un environnement de langage/plateforme commun. Il est aussi souligné que, dans le contexte actuel de menaces de sécurité, les technologies additionnelles de l’époque auraient du mal à survivre

  • L’avantage du DOM (HTML), c’est d’avoir été conçu pour être réactif face à une grande variété d’environnements d’affichage. Le SVG offre moins de liberté sur ce point

• Cela peut sembler très farfelu, mais j’ai envie d’animer des diagrammes d’architecture SVG pour produire des vidéos où les nœuds bénéficient d’animations dramatiques — zooms façon scène de combat, arrêts sur image, effets de lignes clignotantes, etc.

• Ce genre de post de type TIL contribue énormément à stimuler la créativité, en partageant directement la découverte d’un nouvel outil et même des moyens de contourner les contraintes du Markdown de Github. En voyant le résultat SVG (exemple), j’ai découvert pour la première fois une structure avec du SVG inline imbriqué dans du SVG inline, et j’en suis reconnaissant pour cette découverte

  • En théorie, on pourrait même créer un SVG quine animé montrant un éditeur dans lequel il saisit son propre code source

• Excellente idée ; j’aimerais tester dans un README comment cela pourrait correspondre aux effets implémentés dans terminaltexteffects. Je ne connais pas très bien le SVG, mais je comprends bien que si l’on stocke le texte réel, le fichier peut devenir volumineux. Cela dit, j’ai quand même envie d’essayer pour le plaisir