La API de View Transition cambia las reglas del juego para 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 nativas que cautivan a los usuarios. Actualmente disponible en Chrome, pero pronto estarán disponibles en Safari las mismas transiciones de vistas de documentos.
Dado que cada vez más personas comienzan a analizar la API de View Transition, es hora de desmentir algunos conceptos erróneos.
Concepto erróneo 1: La API de transición de vistas 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, se animan estos resúmenes, como se indica 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. Considéralo 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, las demostraciones como esta funcionan: el video extraído de la nueva instantánea se sigue reproduciendo mientras se realiza la transición de las vistas.
La lógica y el CSS que se usan para esto se detallan en nuestra documentación.
Concepto erróneo 2: Capturar más de un elemento genera varias transiciones de vistas en ejecución.
Cuando captures varios elementos, el proceso de captura de instantáneas capturará todos los estados antiguos y nuevos. 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 transición de vista única.
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 hasta el final cuando comience una nueva.
Concepto erróneo 3: No puedes implementar transiciones de vistas debido a la compatibilidad del navegador
A muchos desarrolladores les preocupa no poder 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 vistas 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. De lo contrario, tendrá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 las admiten omitirán la habilitación de CSS cuando analicen las hojas de estilo.
Este enfoque se implementó con éxito en el comercio electrónico, como se detalla en este caso de éxito
Concepto erróneo 4: Las transiciones de vistas interrumpen la renderización incremental.
Existen reclamos que indican que las transiciones de vistas interrumpen la renderización incremental. Este no es el caso: se especificaron las transiciones de vistas entre documentos para que no dañen 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 todas las hojas 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 vistas entre documentos no cambian esto: el contenido requerido para First Contentful Paint 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 hacerlo, usa esta etiqueta de vínculo:
<link rel="expect" blocking="render" href="#elementId">
Esto anula la heurística del navegador que se usa para decidir cuándo realizar la primera representación: la primera 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 de la representación debe usarse con precaución. El impacto de la renderización de bloqueo se debe evaluar 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.
Concepto erróneo 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, la vista anterior permanece visible para el usuario. 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, son como máximo dos fotogramas inactivos: uno para ejecutar la lógica más un fotograma adicional para garantizar que las instantáneas se hayan compuesto y almacenado en caché.
Además, los datos para las instantáneas se toman directamente del compositor, por lo que no es necesario realizar pasos adicionales de diseño o volver a pintar para obtener los datos de la instantánea.
Concepto erróneo adicional: Es la API de transiciones de vistas
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 concepto erróneo se origina en algunos artículos, incluidos nuestros propios documentos sobre DCC, en los que se usa el término equivocado.
El truco para recordar el nombre correcto es usar la (una) API de View Transition para crear (una o más) transiciones de vistas.