Résumé

  • Le premier projet public du W3C, en juin 2013, cherchait un modèle de temps et d’effets commun aux transitions CSS, aux animations CSS et aux animations SVG.
  • Le texte de 2014 associait ce modèle à une interface de création par script, exécutée ensuite par le navigateur. Celui de 2023 détaillait le temps courant, la pause, l’inversion du sens, la fin et l’annulation.

Les machinistes ne se comprennent pas toujours. Le premier fait entrer un graphique par transition, le deuxième le fait tourner avec des images clés, le troisième déplace un trait SVG. Le lecteur veut revoir le trajet d’un paquet sur le schéma. L’éditeur doit alors demander « où sommes-nous dans le temps ? » à trois systèmes voisins. Il pourrait installer une minuterie JavaScript derrière chaque accessoire et recalculer chaque image lui-même. Ce serait un drôle de cumul de métiers pour quelqu’un qui veut surtout expliquer un réseau.

Le premier projet Web Animations, daté du 25 juin 2013, part d’un constat technique : transitions CSS, animations CSS et SVG possèdent des fonctions proches, décrites dans des termes différents. Le modèle proposé réunit leurs notions communes de calendrier, de période active et d’effet. Les valeurs intermédiaires peuvent être calculées à partir de ce temps, puis combinées avec d’autres effets. Le modèle ne décide pas de la scène à montrer; il fournit une langue commune pour que plusieurs scènes puissent suivre la même logique.

Le projet du 5 juin 2014 décrit plus nettement la répartition du travail. Il contient un modèle abstrait et une interface qui permet au script de créer une animation. Une fois créée, celle-ci est exécutée par l’agent utilisateur. Le script n’a donc pas nécessairement à peindre chaque image intermédiaire avec son propre rappel. Le document situe également cette interface par rapport à requestAnimationFrame, notamment pour les valeurs de temps et l’ordre d’exécution. Le navigateur garde l’horloge; le site peut choisir de mettre la scène en marche.

La commande devient intéressante lorsqu’un mouvement sert à comprendre quelque chose. Une lectrice peut arrêter le dessin à mi-parcours pour lire une légende. Un enseignant peut remonter le chemin d’un signal afin d’expliquer son origine. S’il existe une réponse cohérente à la question « où en est l’animation ? », la pause et le retour deviennent des outils éditoriaux. On peut manipuler une progression sans réinventer le temps pour chaque transition, chaque séquence de CSS et chaque forme SVG.

Le projet Level 1 du 11 octobre 2018 poursuit cette séparation entre calendrier, objet animation et effet. L’effet décrit ce qui change; le calendrier fournit la progression; l’état de lecture dit si le mouvement attend, joue, s’arrête ou s’achève. Modifier une vitesse ou repartir en arrière n’oblige pas à redessiner la figure image par image. Sous le simple bouton retour se cache une notion de temps courant que tous ces gestes doivent respecter.

Le texte du 5 juin 2023 précise ce pupitre de commande : régler le temps courant ou le départ, jouer, mettre en pause, terminer, annuler, changer la vitesse et inverser le sens. Il traite aussi les états de préparation et d’achèvement. L’insistance sur les états a une raison très concrète. Une demande de pause peut tomber pendant que l’animation se prépare, ou juste avant sa fin. Un changement de vitesse peut croiser un retour en arrière. Pour afficher la bonne image, le navigateur doit savoir quel état précède lequel. Le spectateur ne voit qu’un bouton; le mécanisme, lui, ne peut pas improviser.

La chronologie du W3C date les étapes de 2013, 2014, 2018 et 2023. Cette histoire concerne l’horloge commune et les commandes de lecture. La question ultérieure d’un défilement qui fournit la progression appartient à un autre chapitre. Ici, l’auteur conserve le choix du mouvement utile, du moment où le lecteur doit pouvoir l’arrêter et de l’image à revoir. Le navigateur fait marcher les engrenages. Trois machinistes peuvent enfin ranger leurs trois chronomètres.