L'API View Transition vous permet de mettre à jour le DOM en une seule étape, tout en générant une transition animée entre les deux états.
Ces types de transitions étaient une fonctionnalité fréquemment demandée par les développeurs, dont moi, et je pense que nous avons réussi à trouver le juste équilibre entre de bonnes valeurs par défaut, l'extensibilité et la personnalisation. Nous sommes peut-être fiers de pouvoir compter sur nous, mais les commentaires des développeurs ont joué un rôle essentiel dans la conception de cette fonctionnalité. Un prototype antérieur de cette fonctionnalité était beaucoup moins flexible, et les personnes (comme vous ?) qui ont pris le temps d'essayer les prototypes et de fournir des commentaires ont provoqué un repens total. Merci !
Pour vous familiariser avec la fonctionnalité et regarder quelques démos, consultez notre guide. Si vous pensez que quelqu'un n'y est pas couvert, n'hésitez pas à me contacter sur Twitter ou sur Mastodon, ou par e-mail.
L'API View Transition n'est actuellement disponible que dans Chrome. Heureusement, elle peut être utilisée comme une amélioration progressive. Le guide comprend une fonction d'assistance que vous pouvez utiliser dans tous les navigateurs, mais seuls ceux qui acceptent les transitions de vue peuvent voir l'animation.
Nous avons développé cette fonctionnalité au sein du CSS Working Group, avec l'aide d'autres éditeurs de navigateurs et d'indépendants. Nous ne savons pas si ni quand d'autres navigateurs adopteront les transitions de vue, mais vous devez garder un œil sur la position standard de Mozilla et la position standard de WebKit.
Mais ce n'est pas encore fini !
La fonctionnalité disponible dans Chrome 111 n'est que la première version. Nous espérons que nous avons déjà repéré tous les bugs. Si vous constatez un problème, veuillez le signaler sur crbug.com, de préférence avec une démo réduite. Si ce n'est pas quelque chose que vous connaissez ou ne connaissez pas, contactez-moi sur Twitter, Mastodon ou par e-mail, et je vous aiderai.
Cette version est une petite partie, espérons-le, utile d'une vue d'ensemble. Nous avons déjà esquissé quelques extensions de cette fonctionnalité pour nous assurer que les pièces que nous expédions aujourd'hui sont compatibles avec l'avenir.
Voici un aperçu de ce que nous pensons. Ils ne sont pas classés par ordre de priorité (le premier est peut-être le plus important pour de nombreuses personnes). Nous aimerions donc connaître votre avis sur les ajouts les plus importants pour vous.
Transitions entre les documents
Je pense que la plupart des développeurs veulent que nous travaillions sur celui-ci, et la bonne nouvelle, c'est que nous y travaillons déjà !
L'API View Transitions a été conçue pour fonctionner sur des documents de même origine. La seule différence est qu'au lieu que startViewTransition signale le changement d'état du DOM, la navigation elle-même le signale.
Notre prototype de ceci derrière l'indicateur chrome://flags/#view-transition-on-navigation. Voici une démonstration très simple et une démonstration plus complexe.
Pour cela, nous devons déterminer comment chaque page active la transition. Pour le moment, nous utilisons la balise Meta <meta name="view-transition" content="same-origin">, mais nous pensons que le CSS est mieux adapté. Nous souhaitons également vous aider à identifier plus facilement le type de page à partir duquel vous effectuez la transition, de préférence sans avoir à écrire du code JavaScript.
Il y a beaucoup de travail à accomplir, et nous préférons y arriver « bien » plutôt que « rapide », mais c'est sans aucun doute une priorité pour nous.
Animations basées sur le compositeur
Nous avons choisi d'animer la largeur et la hauteur des groupes de transition par défaut pour faciliter leur personnalisation. Toutefois, cela signifie que l'animation s'exécute sur le thread principal, ce qui n'est pas idéal, en particulier lors du chargement de la page.
Nous prévoyons de détecter les animations par défaut et les personnalisations courantes, puis de les réinterpréter en tant qu'animations gérées par le compositeur afin d'améliorer les performances.
Transitions délimitées
Pour le moment, les transitions SPA sont limitées à l'ensemble du document, et une seule transition peut être exécutée à la fois. Nous souhaitons introduire une fonctionnalité permettant de limiter les transitions à un élément particulier afin que plusieurs composants de page puissent les exécuter indépendamment.
Par exemple, un lecteur vidéo intégré pourrait utiliser des transitions de vue en même temps qu'un widget de chat intégré.
Groupes de transition imbriqués
Pour le moment, tous les ::view-transition-group sont frères. C'est souvent une bonne chose, car cela permet aux vues de passer d'un conteneur à un autre sans vous soucier du rognage.
Cependant, il peut arriver qu'une vue soit coupée par un parent, qui peut être impliqué dans la transition.
Nous voulons étudier une activation qui place une ::view-transition-group spécifique dans une autre ::view-transition-group.
Classes de transitions
Chaque view-transition-name doit être unique. C'est ainsi que nous identifions qu'un élément particulier est conceptuellement "identique" de chaque côté du changement DOM, même s'il ne s'agit pas littéralement du même élément.
Toutefois, des éléments comportant des view-transition-name différents doivent parfois utiliser le même type d'animation. Pour le moment, cela implique d'ajouter une règle de sélection pour chaque view-transition-name.
Nous aimerions ajouter un moyen de créer des classes de transitions pour contourner cette limitation.
Ignorer les éléments hors écran
Si vous attribuez une view-transition-name à un élément, il sera impliqué dans la transition en tant que groupe distinct. Parfois, ce n'est pas idéal. Par exemple, si vous attribuez un view-transition-name à un en-tête et que vous passez d'un état où vous faites défiler 2 000 pixels vers un état en haut de la page, l'en-tête sera animé à partir de 2 000 pixels, ce qui semble fausse au niveau des codes temporels.
À la place, nous souhaitons ajouter une option d'activation pour qu'un élément soit ignoré, comme s'il n'était pas associé à une propriété view-transition-name, s'il se trouve entièrement en dehors de la fenêtre d'affichage.
Vous pouvez déjà le faire avec JavaScript en définissant style.viewTransitionName de manière dynamique, mais il semble que nous devrions avoir une solution déclarative pour cela.
Animations basées sur requestAnimationFrame
Vous pouvez déjà créer des animations de transition de vue avec JavaScript via l'API Web Animations, mais vous devez parfois piloter les éléments frame par frame avec requestAnimationFrame.
Vous pouvez déjà le faire, mais c'est un peu compliqué. Voici une démonstration qui contient des informations qui pourraient vous être utiles. Nous voulons qu'il soit facile à utiliser.
Nous allons procéder en deux parties. Premièrement, en fournissant une API pour indiquer quand l'animation est terminée. Et deuxièmement, en fournissant un accès JavaScript aux pseudo-éléments. Cette deuxième partie pourrait être un travail assez important, mais cela semble être la bonne chose à faire sur le long terme.
À présent, réalisez de superbes transitions d'affichage.
J'espère que, comme moi, vous avez hâte de découvrir cette fonctionnalité aujourd'hui. Si vous avez des commentaires ou si vous voulez simplement montrer certaines transitions que vous avez effectuées, qu'elles soient fluides et fonctionnelles, ou tout simplement simples drôles, contactez-moi sur Twitter ou Mastodon.