L'API View Transition è un punto di svolta nello sviluppo web. Che il tuo sito web sia di una o più pagine, questa potente API ti consente di creare transizioni fluide tra le visualizzazioni, dando vita a esperienze simili a quelle native che attirano 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.
Idea errata 1: l'API View Transizione 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. Consideralo 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 dal vivo, demo come questa funzionano: il video, proveniente dalla nuova istantanea, continua a essere riprodotto durante il passaggio della 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.
Idea errata 3: non è possibile implementare le transizioni di visualizzazione a causa del supporto del browser
Molti sviluppatori temono di non poter implementare le transizioni di visualizzazione perché questa funzionalità è supportata solo su Chrome. Una buona notizia è che Safari ci sta lavorando e lo includerà nell'imminente 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. In caso contrario, verrà visualizzata 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
Idea errata 4: le transizioni di visualizzazione interrompono il rendering incrementale
Esistono rivendicazioni secondo le quali le transizioni della visualizzazione 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 operazione è utile se vuoi assicurarti che gli elementi che partecipano alla transizione della 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: il processo di creazione di snapshot è lento o costoso
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, ad esempio, l'impatto di pageswap è pari al massimo a due frame inattivi: uno per eseguire la logica e un frame aggiuntivo per garantire che gli snapshot siano stati composti e memorizzati nella cache.
Inoltre, i dati degli snapshot vengono presi direttamente dal compositore, quindi non sono necessari passaggi aggiuntivi di layout o ridipintura 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 è denominata "API View Transizione" (nota: "Transizione".
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 la (una) API View Transizione per creare (una o più) transizioni di visualizzazione.