L'API View Transition è un punto di svolta per lo sviluppo web. Che il tuo sito web sia a una o più pagine, questa potente API ti consente di creare transizioni fluide tra le visualizzazioni, il che si traduce in esperienze simili a quelle native che affascinano gli utenti. Attualmente disponibile in Chrome, le stesse transizioni tra le visualizzazioni dei documenti saranno presto disponibili in Safari.
Sempre più persone stanno iniziando a esaminare l'API View Transition, quindi è il momento di sfatare alcuni miti.
Concetto errato 1: l'API View Transition acquisisce screenshot
Quando esegui una transizione di visualizzazione, l'API acquisisce istantanee dello stato precedente e di quello nuovo dei contenuti. Questi istantanei vengono poi animati, come descritto nella sezione "Come funzionano queste transizioni" della documentazione.
Sebbene tu possa utilizzare il termine screenshot per il vecchio snapshot, il nuovo snapshot non è uno screenshot, ma una rappresentazione in tempo reale del nodo. Immaginalo come un elemento sostituito.
::view-transition
└─ ::view-transition-group(root)
└─ ::view-transition-image-pair(root)
├─ ::view-transition-old(root) 👈 Screenshot
└─ ::view-transition-new(root) 👈 Live representation
Grazie a questo aspetto in tempo reale, demo come questa funzionano: il video, tratto dal nuovo istantaneo, continua a essere riprodotto durante la transizione di visualizzazione.
La logica e il CSS utilizzati sono descritti dettagliatamente nella nostra documentazione.
Concetto errato 2: la cattura di più elementi comporta l'esecuzione di più transizioni di visualizzazione
Quando acquisisci più elementi, il processo di acquisizione degli istantanei acquisisce tutti gli stati vecchi e nuovi. Quando acquisisci un .box
oltre all'elemento :root
, ottieni questa pseudo-struttura ad albero:
::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)
Sebbene questo albero contenga più coppie di istantanee, viene eseguita una sola transizione di visualizzazione.
Al momento, Chrome è limitato a eseguire una transizione di visualizzazione alla volta per documento. Prova a fare clic rapidamente in questa demo per avviare una nuova transizione di visualizzazione. Noterai che la transizione in corso salta alla fine quando ne inizia una nuova.
Concetto errato 3: non puoi implementare le transizioni di visualizzazione a causa del supporto del browser
Molti sviluppatori temono di non poter implementare le transizioni di visualizzazione perché sono supportate solo su Chrome. La buona notizia è che Safari sta lavorando a questa funzionalità e la includerà nella prossima release di Safari 18.
Tuttavia, non lasciare che il supporto discontinuo dei browser ti impedisca di implementare le transizioni di visualizzazione oggi stesso. Le transizioni tra le visualizzazioni sono il materiale perfetto per il miglioramento progressivo. La documentazione originale illustra un metodo per aggiungere questa metodologia al codice.
function handleClick(e) {
// Fallback for browsers that don't support this API:
if (!document.startViewTransition) {
updateTheDOMSomehow();
return;
}
// With a View Transition:
document.startViewTransition(() => updateTheDOMSomehow());
}
Se il tuo browser supporta le transizioni tra visualizzazioni dello stesso documento, visualizzerai la versione animata e arricchita. Se il tuo browser non lo supporta, visualizzerai l'esperienza attuale. Nel tempo, man mano che sempre più browser supportano le transizioni di visualizzazione, un numero maggiore di utenti potrà usufruire di questa versione arricchita, il tutto automaticamente.
Lo stesso vale per le transizioni tra visualizzazioni di più documenti. I browser che non li supportano ignoreranno l'attivazione del CSS durante l'analisi dei fogli di stile.
Questo approccio è stato implementato con successo nell'e-commerce, come descritto in questo caso di studio
Concetto errato 4: le transizioni della visualizzazione interrompono il rendering incrementale
Esistono affermazioni secondo cui le transizioni tra le visualizzazioni interrompono il rendering incrementale. Non è vero: le transizioni tra visualizzazioni di documenti sono state specificate per non interrompere questo aspetto fondamentale del web.
I browser iniziano a eseguire il rendering di una pagina quando hanno contenuti "sufficienti". Nella maggior parte dei browser, questo avviene dopo aver caricato tutti gli stili nel <head>
, analizzato tutto il codice JavaScript che blocca il rendering nel <head>
e caricato markup sufficiente. Le transizioni tra visualizzazioni di documenti non cambiano questo aspetto: i contenuti richiesti per First Contentful Paint rimangono invariati. Dopo questo primo rendering, il browser può e deve eseguire il rendering incrementale dei contenuti appena ricevuti.
Puoi scegliere di bloccare il rendering finché non è presente un determinato elemento nel DOM. Questa opzione è utile quando vuoi assicurarti che gli elementi che partecipano alla transizione di visualizzazione siano presenti nella nuova pagina.
A tale scopo, utilizza questo tag link:
<link rel="expect" blocking="render" href="#elementId">
Questo sostituisce le strategie di ricerca heuristiche del browser utilizzate per decidere quando eseguire il primo rendering: il primo rendering viene ritardato fino a quando l'elemento specificato non è presente nella struttura DOM.
Questo blocco manuale prevede alcune misure di salvaguardia. Ad esempio, quando viene visualizzato il tag di chiusura </html>
, ma non l'elemento di blocco, il rendering non verrà più bloccato. Inoltre, puoi aggiungere la tua logica di timeout che rimuove l'attributo di blocco in qualsiasi momento.
È evidente che il blocco della visualizzazione deve essere utilizzato con cautela. L'impatto del blocco del rendering deve essere valutato caso per caso. Per impostazione predefinita, evita di utilizzare blocking=render
, a meno che tu non possa misurare e valutare attivamente l'impatto che ha sugli utenti, misurando l'impatto sulle metriche sul rendimento.
Concezione errata 5: la procedura di creazione di snapshot è lenta o costosa
Mentre l'API View Transition prepara la nuova visualizzazione e ne acquisisce gli istantanei, la visualizzazione precedente rimane visibile all'utente. Di conseguenza, un utente può vedere la vecchia pagina un po' più a lungo rispetto a quando non sono presenti transizioni di visualizzazione. Tuttavia, questo ritardo è trascurabile, in realtà solo pochi fotogrammi. In Chrome, l'impatto di pageswap
, ad esempio, è di massimo due frame non aggiornati: uno per eseguire la logica e un altro frame aggiuntivo per assicurarsi che gli istantanei siano stati composti e memorizzati nella cache.
Inoltre, i dati degli snapshot vengono estratti direttamente dal compositore, quindi non sono necessari passaggi aggiuntivi di layout o ridisegni per ottenere i dati degli snapshot.
Concetto errato aggiuntivo: si tratta dell'API View Transitions
Quando si parla di transizioni di visualizzazione, spesso si fa riferimento all'API View Transitions. Risposta errata. L'API si chiama "API View Transition", nota la forma singolare "Transition".
Il fraintendimento deriva dal fatto che alcuni articoli, tra cui a un certo punto le nostre documentazioni sul DCC, utilizzano il termine sbagliato.
Il trucco per ricordare il nome corretto è utilizzare l'API View Transition (una) per creare (una o più) transizioni di visualizzazione.