La API de View Transition es un cambio radical en el desarrollo web. Ya sea que tu sitio web tenga una o varias páginas, esta potente API te permite crear transiciones fluidas entre vistas, lo que genera experiencias similares a las nativas que cautivan a los usuarios. Actualmente, está disponible en Chrome, y las mismas transiciones de vista de documentos pronto estarán disponibles en Safari.
Dado que cada vez más personas comienzan a analizar la API de View Transition, es hora de desmentir algunos conceptos erróneos.
Error de concepto 1: La API de View Transition toma capturas de pantalla
Cuando se ejecuta una transición de vista, la API toma instantáneas del estado anterior y el nuevo del contenido. Luego, estas instantáneas se animan, como se detalla en la sección "Cómo funcionan estas transiciones" de la documentación.
Si bien puedes usar el término captura de pantalla para la instantánea anterior, la nueva instantánea no es una captura de pantalla, sino una representación en vivo del nodo. Piensa en él como un elemento reemplazado.
::view-transition
└─ ::view-transition-group(root)
└─ ::view-transition-image-pair(root)
├─ ::view-transition-old(root) 👈 Screenshot
└─ ::view-transition-new(root) 👈 Live representation
Gracias a este aspecto en vivo, funcionan demos como esta: el video, que proviene de la nueva instantánea, sigue reproduciéndose mientras se produce la transición de vista.
La lógica y el CSS que se usan para esto se detallan en nuestra documentación.
Error de concepto 2: Capturar más de un elemento genera que se ejecuten varias transiciones de vista.
Cuando captures varios elementos, el proceso de creación de instantáneas capturará todos los estados nuevos y anteriores. Cuando capturas un .box, además del elemento :root, obtienes este seudoárbol:
::view-transition
└─ ::view-transition-group(root)
| └─ ::view-transition-image-pair(root)
| ├─ ::view-transition-old(root)
| └─ ::view-transition-new(root)
└─ ::view-transition-group(box)
└─ ::view-transition-image-pair(box)
├─ ::view-transition-old(box)
└─ ::view-transition-new(box)
Si bien este árbol contiene varios pares de instantáneas, solo se ejecuta una sola transición de vista.
Actualmente, Chrome se limita a ejecutar una transición de vista por documento al mismo tiempo. Intenta hacer clic rápido en esta demostración para iniciar una nueva transición de vistas. Notarás que la transición en curso se salta al final cuando comienza una nueva.
Error de concepto 3: No puedes implementar transiciones de vista debido a la compatibilidad con el navegador
Muchos desarrolladores se preocupan porque no pueden implementar transiciones de vistas porque solo son compatibles con Chrome. La buena noticia es que Safari está trabajando en ello y lo incluirá en la próxima versión de Safari 18.
Aun así, no permitas que la compatibilidad irregular del navegador te impida implementar transiciones de vistas hoy. Las transiciones de vista son el material perfecto para la mejora progresiva. En la documentación original, se comparte un método para agregar esta metodología a tu código.
function handleClick(e) {
// Fallback for browsers that don't support this API:
if (!document.startViewTransition) {
updateTheDOMSomehow();
return;
}
// With a View Transition:
document.startViewTransition(() => updateTheDOMSomehow());
}
Si el navegador admite transiciones de vista del mismo documento, obtendrás la versión enriquecida y animada. Si no es así, obtendrás la experiencia actual. Con el tiempo, a medida que más navegadores admitan transiciones de vistas, más usuarios podrán experimentar esta versión enriquecida, todo automáticamente.
Lo mismo se aplica a las transiciones de vistas entre documentos. Los navegadores que no los admitan ignorarán la habilitación de CSS cuando analicen las hojas de estilo.
Este enfoque se implementó correctamente en el comercio electrónico, como se detalló en este caso de éxito.
Error de concepto 4: Las transiciones de vista interrumpen la renderización incremental
Hay afirmaciones de que las transiciones de vista interrumpen la renderización incremental. Esto no es cierto: las transiciones de vista entre documentos se especificaron para no romper este aspecto fundamental de la Web.
Los navegadores comienzan a renderizar una página cuando tienen "suficiente" contenido. En la mayoría de los navegadores, esto ocurre después de cargar todos los editores de estilo en <head>, analizar todo el código JavaScript que bloquea la renderización en <head> y cargar suficiente lenguaje de marcado. Las transiciones de vista entre documentos no cambian esto: el contenido necesario para el primer procesamiento de imagen con contenido no se altera. Después de esta primera renderización, el navegador puede renderizar de forma incremental el contenido recién recibido.
Puedes bloquear la representación hasta que cierto elemento esté presente en el DOM. Esto resulta conveniente en situaciones en las que quieras asegurarte de que los elementos que participan en la transición de vistas estén presentes en la página nueva.
Para ello, usa esta etiqueta de vínculo:
<link rel="expect" blocking="render" href="#elementId">
Esto anula las heurísticas del navegador que se usan para decidir cuándo realizar la primera renderización: la primera renderización se retrasa hasta que el elemento especificado esté presente en el árbol del DOM.
Este bloqueo manual tiene algunas protecciones integradas. Por ejemplo, cuando se vea la etiqueta de cierre </html>, pero no el elemento de bloqueo, ya no se bloqueará la renderización. Además, puedes agregar tu propia lógica de tiempo de espera que quite el atributo de bloqueo en cualquier momento.
Es evidente que el bloqueo del procesamiento se debe usar con precaución. El impacto de bloquear la renderización debe evaluarse caso por caso. De forma predeterminada, evita usar blocking=render, a menos que puedas medir y medir activamente el impacto que tiene en tus usuarios. Para ello, debes medir el impacto en tus métricas de rendimiento.
Error de concepto 5: El proceso de creación de instantáneas es lento o costoso
Mientras la API de View Transition prepara la vista nueva y obtiene sus instantáneas, el usuario puede ver la vista anterior. Debido a esto, el usuario puede ver la página anterior un poco más de tiempo que sin las transiciones de vistas. Sin embargo, esta demora es insignificante; en realidad, solo son algunos fotogramas. En Chrome, el impacto de pageswap, por ejemplo, es de dos fotogramas inactivos como máximo: uno para ejecutar la lógica y un fotograma adicional para garantizar que las instantáneas se hayan compuesto y almacenado en caché.
Además, los datos de las instantáneas se toman directamente del compositor, por lo que no hay pasos adicionales de diseño o repintado que se deban realizar para obtener los datos de la instantánea.
Error adicional: Es la API de View Transitions
Cuando se habla de transiciones de vistas, se suele hacer referencia a la "API de View Transitions". Incorrecto. La API se llama "API de View Transition"; observa la "transición" singular.
El error proviene de algunos artículos, incluidas nuestras propias documentos sobre DCC, en los que se usa el término incorrecto.
El truco para recordar el nombre correcto es usar la (una) API de View Transition para crear (una o más) transiciones de vista.