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, y compris moi-même. Je pense que nous avons réussi à les implémenter de manière à équilibrer les valeurs par défaut avec l'extensibilité et la personnalisation. Cela peut sembler être un coup de chapeau à nous-mêmes, mais les commentaires des développeurs ont été essentiels à la conception de cette fonctionnalité. Un prototype précédent de cette fonctionnalité était beaucoup moins flexible, et les personnes (comme vous ?) qui ont pris le temps de jouer avec les prototypes et de nous faire part de leurs commentaires ont déclenché une refonte totale. Merci !
Pour vous familiariser avec cette fonctionnalité et tester quelques démonstrations, consultez notre guide. Si vous pensez que certains points ne sont pas abordés, n'hésitez pas à me contacter sur Twitter, Mastodon ou par e-mail.
L'API View Transitions n'est actuellement disponible que dans Chrome. Heureusement, elle peut être utilisée comme amélioration progressive. Le guide inclut une fonction d'assistance que vous pouvez utiliser dans tous les navigateurs, mais seuls les navigateurs compatibles avec les transitions de vue recevront l'animation.
Nous avons développé cette fonctionnalité au sein du groupe de travail CSS, avec les contributions d'autres fournisseurs de navigateurs et d'acteurs indépendants. Nous ne savons pas si et quand d'autres navigateurs adopteront les transitions de vue, mais gardez un œil sur la position de Mozilla sur les normes et la position de WebKit sur les normes.
Mais ce n'est pas tout !
La fonctionnalité disponible dans Chrome 111 n'est que la première version. Nous espérons avoir déjà trouvé tous les bugs, mais veuillez signaler tout problème que vous rencontrez sur crbug.com, de préférence avec une démonstration réduite. Si vous ne savez pas comment procéder, contactez-moi sur Twitter, Mastodon ou par e-mail. Je me ferai un plaisir de vous aider.
Cette version n'est qu'une petite partie d'un ensemble plus vaste, mais nous espérons qu'elle vous sera utile. Nous avons déjà esquissé quelques extensions de cette fonctionnalité pour nous assurer que les pièces que nous expédions aujourd'hui seront compatibles à l'avenir.
Voici un aperçu de ce que nous pensons. Ces fonctionnalités ne sont pas classées par ordre de priorité (à part peut-être la première, qui est la plus importante pour beaucoup d'utilisateurs). Nous aimerions donc connaître votre avis sur les fonctionnalités qui vous intéressent le plus.
Transitions entre les documents
C'est celle que la plupart des développeurs veulent que nous abordions ensuite. La bonne nouvelle est que nous y travaillons déjà !
L'API View Transitions a été conçue pour fonctionner avec les documents de même origine. La seule différence est que, au lieu que startViewTransition signale le changement d'état du DOM, la navigation elle-même le signale.
Notre prototype derrière l'indicateur chrome://flags/#view-transition-on-navigation. Voici une démonstration super simple et une démonstration plus complexe.
Pour avancer, nous devons déterminer comment chaque page active la transition. Pour le moment, nous utilisons une balise méta: <meta name="view-transition" content="same-origin">, mais nous pensons que le CSS est plus approprié. Nous souhaitons également vous permettre de savoir plus facilement de quel type de page vous passez, de préférence sans avoir à écrire du code JavaScript.
Il y a beaucoup de travail à faire, et nous préférons le faire correctement plutôt que rapidement, mais c'est une priorité pour nous.
Animations basées sur le moteur de composition
Nous avons choisi d'animer la largeur et la hauteur des groupes de transition par défaut, car cela est beaucoup plus facile à personnaliser. 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 basées sur le moteur de composition pour améliorer les performances.
Transitions de portée
Pour le moment, les transitions SPA sont limitées à l'ensemble du document, et une seule transition peut s'exécuter à la fois. Nous souhaitons lancer une fonctionnalité permettant de limiter le champ d'application des transitions à un élément particulier afin que plusieurs composants de page puissent exécuter des transitions 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 transitions imbriqués
Pour le moment, tous les ::view-transition-group sont frères et sœurs. C'est souvent une bonne chose, car cela permet aux vues de passer d'un conteneur à un autre, et vous n'avez pas à vous soucier du recadrage.
Toutefois, il arrive que vous souhaitiez qu'une vue soit rognée par un parent, qui peut également être impliqué dans la transition.
Nous souhaitons examiner une option d'activation qui place un ::view-transition-group particulier dans un 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 "le même" de chaque côté du changement de DOM, même s'il ne s'agit pas littéralement du même élément.
Toutefois, il arrive que des éléments avec des view-transition-name différents doivent utiliser le même type d'animation. Pour le moment, cela signifie ajouter une règle de sélecteur 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 un view-transition-name à un élément, il sera impliqué dans la transition en tant que groupe. Ce n'est pas toujours idéal. Par exemple, si vous attribuez un view-transition-name à un en-tête et que vous passez d'un état où vous avez fait défiler la page de 2 000 pixels à un état en haut de la page, l'en-tête s'animera à partir de 2 000 pixels, ce qui semble incorrect en termes de timing.
Nous souhaitons plutôt ajouter une option permettant d'ignorer un élément, comme s'il n'avait pas de view-transition-name, s'il se trouve entièrement en dehors du viewport.
Vous pouvez déjà le faire avec JavaScript en définissant dynamiquement style.viewTransitionName, mais il semble que nous devrions disposer d'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 gérer les choses image par image avec requestAnimationFrame.
Vous pouvez déjà le faire, mais c'est un peu compliqué. Voici une démonstration avec quelques outils qui pourraient vous être utiles. Nous voulons que ce ne soit pas un hack.
Nous allons procéder en deux étapes. 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 peut représenter un travail assez important, mais il semble que ce soit la bonne chose à faire à long terme.
Maintenant, créez des transitions de vue de qualité !
J'espère que, comme moi, vous êtes enthousiaste à l'égard du présent et de l'avenir de cette fonctionnalité. Si vous avez des commentaires ou si vous souhaitez simplement montrer des transitions de vue que vous avez créées, qu'elles soient fluides et fonctionnelles ou tout simplement bêtes et amusantes, n'hésitez pas à me contacter sur Twitter ou Mastodon.