De View Transition API is een gamechanger voor webontwikkeling. Of uw website nu uit één of meerdere pagina's bestaat, met deze krachtige API kunt u naadloze overgangen tussen weergaven creëren, wat resulteert in native-achtige ervaringen die gebruikers boeien. Momenteel beschikbaar in Chrome, met dezelfde documentweergave-overgangen binnenkort beschikbaar in Safari.
Nu steeds meer mensen zich verdiepen in de View Transition API, is het tijd om enkele misvattingen te ontkrachten.
Misvatting 1: De View Transition API maakt screenshots
Bij het uitvoeren van een weergaveovergang maakt de API momentopnamen van de oude en nieuwe status van de inhoud. Deze snapshots worden vervolgens geanimeerd, zoals beschreven in de sectie "Hoe deze overgangen werken" van de documentatie .
Hoewel u de term screenshot kunt gebruiken voor de oude momentopname, is de nieuwe momentopname geen schermafbeelding, maar feitelijk een live weergave van het knooppunt. Zie het als een vervangen element.
::view-transition
└─ ::view-transition-group(root)
└─ ::view-transition-image-pair(root)
├─ ::view-transition-old(root) 👈 Screenshot
└─ ::view-transition-new(root) 👈 Live representation
Dankzij dit live-aspect werken demo's zoals deze : de video – afkomstig van de nieuwe snapshot – blijft spelen terwijl de weergaveovergang plaatsvindt.
De logica en CSS die hiervoor worden gebruikt, worden gedetailleerd beschreven in onze documentatie .
Misvatting 2: Het vastleggen van meer dan één element resulteert in het uitvoeren van meerdere weergaveovergangen
Wanneer u meerdere elementen vastlegt, legt het momentopnameproces alle oude en nieuwe toestanden vast. Wanneer u naast het :root element ook een .box vastlegt, krijgt u deze pseudo-boom:
::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)
Hoewel deze boom meerdere momentopnameparen bevat, wordt er slechts één weergaveovergang uitgevoerd.
Momenteel is Chrome beperkt tot het tegelijkertijd uitvoeren van één weergaveovergang per document. Probeer snel te klikken in deze demo om een nieuwe weergaveovergang te starten. U zult merken dat de lopende overgang naar het einde springt wanneer een nieuwe begint.
Misvatting 3: U kunt geen weergaveovergangen implementeren vanwege browserondersteuning
Veel ontwikkelaars zijn bezorgd dat ze geen weergaveovergangen kunnen implementeren, omdat dit alleen in Chrome wordt ondersteund. Goed nieuws is dat Safari hieraan werkt en dit zal opnemen in de komende versie van Safari 18 .
Maar laat de vlekkerige browserondersteuning u er nog steeds niet van weerhouden om vandaag nog weergaveovergangen te implementeren. Beeldovergangen zijn het perfecte materiaal voor progressieve verbetering . De originele documentatie deelt een methode om deze methodologie aan uw code toe te voegen.
function handleClick(e) {
// Fallback for browsers that don't support this API:
if (!document.startViewTransition) {
updateTheDOMSomehow();
return;
}
// With a View Transition:
document.startViewTransition(() => updateTheDOMSomehow());
}
Als uw browser weergaveovergangen van hetzelfde document ondersteunt, krijgt u de verrijkte, geanimeerde versie. Als uw browser dit niet doet, krijgt u de huidige ervaring. Naarmate steeds meer browsers weergaveovergangen ondersteunen, zullen in de loop van de tijd steeds meer gebruikers deze verrijkte versie automatisch kunnen ervaren.
Hetzelfde geldt voor overgangen tussen documenten . Browsers die deze niet ondersteunen, zullen de CSS-opt-in negeren bij het parseren van stylesheets.
Deze aanpak werd met succes geïmplementeerd in de e-commerce, zoals beschreven in deze casestudy
Misvatting 4: Weergaveovergangen onderbreken de incrementele weergave
Er zijn beweringen dat weergaveovergangen de incrementele weergave verbreken . Dit is niet waar: overgangen tussen verschillende documenten zijn gespecificeerd om dit fundamentele aspect van het web niet te ondermijnen.
Browsers beginnen een pagina weer te geven wanneer ze ‘genoeg’ inhoud hebben. Dit is – in de meeste browsers – na het laden van alle stylesheets in de <head> , het parseren van alle render-blokkerende JavaScript in de <head> en het laden van voldoende markup. Overgangen tussen documenten veranderen hier niets aan: de inhoud die nodig is voor First Contentful Paint blijft ongewijzigd. Na deze eerste weergave kan en zal de browser nieuw ontvangen inhoud stapsgewijs weergeven.
U kunt ervoor kiezen om het renderen te blokkeren totdat een bepaald element aanwezig is in de DOM. Dit is handig in situaties waarin u er zeker van wilt zijn dat de elementen die deelnemen aan de weergaveovergang aanwezig zijn op de nieuwe pagina.
Gebruik hiervoor deze linktag:
<link rel="expect" blocking="render" href="#elementId">
Dit overschrijft de heuristieken van de browser die worden gebruikt om te beslissen wanneer de eerste weergave moet worden uitgevoerd: de eerste weergave wordt uitgesteld totdat het opgegeven element aanwezig is in de DOM-boom.
Bij deze handmatige blokkering zijn enkele veiligheidsmaatregelen ingebouwd. Wanneer bijvoorbeeld de afsluitende tag </html> wordt gezien, maar het blokkerende element niet, wordt de weergave niet langer geblokkeerd. Bovendien kunt u uw eigen time-outlogica toevoegen, waardoor het blokkerende attribuut op elk moment wordt verwijderd.
Het is duidelijk dat renderblokkering met voorzichtigheid moet worden toegepast. De impact van het blokkeren van weergave moet van geval tot geval worden beoordeeld. Vermijd standaard het gebruik van blocking=render tenzij u de impact die dit heeft op uw gebruikers actief kunt meten en peilen, door de impact op uw prestatiestatistieken te meten.
Misvatting 5: Het momentopnameproces is traag of duur
Terwijl de View Transition API de nieuwe weergave voorbereidt en momentopnamen ophaalt, blijft de oude weergave zichtbaar voor de gebruiker. Hierdoor krijgt een gebruiker de oude pagina iets langer te zien dan zonder weergaveovergangen. Deze vertraging is echter te verwaarlozen, in werkelijkheid slechts enkele frames. In Chrome is de impact van pageswap bijvoorbeeld maximaal twee verouderde frames: één om de logica uit te voeren plus één extra frame om ervoor te zorgen dat snapshots zijn samengesteld en in de cache zijn opgeslagen.
Bovendien worden de gegevens voor de snapshots rechtstreeks uit de compositor gehaald, zodat er geen extra lay-out- of herschilderstappen nodig zijn om de snapshotgegevens te verkrijgen.
Bonusmisvatting: het is de View Transitions API
Als het over weergaveovergangen gaat, verwijzen mensen vaak naar de "View Transitions API". Dit is incorrect. De API wordt de "View Transition API" genoemd; let op het enkelvoud "Transition".
De misvatting komt voort uit het feit dat in sommige artikelen – waaronder op een gegeven moment ook onze eigen documenten over DCC – de verkeerde term wordt gebruikt.
De truc om de juiste naam te onthouden is dat u de (één) View Transition API gebruikt om (een of meer) weergaveovergangen te maken.