Met de View Transition API kunt u de DOM in één stap bijwerken, terwijl u een geanimeerde overgang tussen de twee statussen genereert.
Dit soort overgangen waren een vaak gevraagde functie van ontwikkelaars, waaronder ikzelf, en ik denk dat we erin zijn geslaagd om deze op een manier te brengen die goede standaardwaarden in evenwicht brengt met uitbreidbaarheid en aanpassing. Dat klinkt alsof we onszelf een schouderklopje geven, maar feedback van ontwikkelaars was de sleutel tot het ontwerp van deze functie. Een eerder prototype van deze functie was veel minder flexibel, en mensen (zoals jij?) die de tijd namen om met de prototypes te spelen en feedback te geven, brachten een totale heroverweging teweeg. Bedankt!
Bekijk onze handleiding om de functie onder de knie te krijgen en met enkele demo's te spelen. Als er iets is waarvan u denkt dat het daar niet wordt behandeld, neem dan contact met mij op via Twitter , Mastodon of via e-mail .
De View Transition API is momenteel alleen beschikbaar in Chrome; Gelukkig kan het worden gebruikt als een progressieve verbetering. De gids bevat een helperfunctie die u in alle browsers kunt gebruiken, maar alleen browsers die weergaveovergangen ondersteunen, krijgen de animatie te zien.
We hebben deze functie ontwikkeld binnen de CSS Working Group , met input van andere browserleveranciers en onafhankelijke browsers. We weten niet of en wanneer andere browsers View Transitions zullen overnemen, maar houden de standaardpositie van Mozilla en WebKit in de gaten.
Maar we zijn nog niet ‘klaar’!
De functionaliteit die in Chrome 111 belandt, is slechts de eerste release. We hopen dat we alle bugs al hebben gevonden, maar meldt eventuele problemen die u tegenkomt op crbug.com , bij voorkeur met een beperkte demo. Als dat niet iets is waarmee u vertrouwd of vertrouwd bent, neem dan contact met mij op via Twitter , Mastodon of via e-mail , en ik zal u helpen.
Deze release is een klein, maar hopelijk nuttig onderdeel van een groter geheel. We hebben al enkele uitbreidingen op deze functie geschetst om ervoor te zorgen dat de onderdelen die we vandaag verzenden toekomstbestendig zijn.
Hier is een voorproefje van wat we denken. Deze staan niet in volgorde van prioriteit (nou ja, misschien is de eerste voor veel mensen het belangrijkst), dus we willen graag feedback over welke toevoegingen voor jou het belangrijkst zijn.
Overgangen tussen documenten
Ik denk dat de meeste ontwikkelaars willen dat we hieraan werken, en het goede nieuws is dat we er al aan werken!
De View Transitions API is zo ontworpen dat deze in documenten van dezelfde oorsprong kan werken. Het enige verschil is dat in plaats van dat startViewTransition de verandering in de DOM-status signaleert, de navigatie zelf die verandering signaleert.
Ons prototype hiervan achter de chrome://flags/#view-transition-on-navigation vlag. Hier is een supereenvoudige demo en een complexere demo .
Om dit verder te brengen moeten we uitzoeken hoe elke pagina zich aanmeldt voor de transitie. Op dit moment gebruiken we een metatag: <meta name="view-transition" content="same-origin"> , maar we denken dat CSS hiervoor een betere plek is. We willen het ook gemakkelijker maken om te weten van welk type pagina u overstapt, bij voorkeur zonder dat u JavaScript hoeft te schrijven.
Er is veel werk te doen, en we landen het liever 'goed' dan 'snel', maar het heeft absoluut een prioriteit voor ons.
Compositor-gestuurde animaties
We hebben ervoor gekozen om standaard de breedte en hoogte van overgangsgroepen te animeren, omdat dit veel gemakkelijker aan te passen is. Dit betekent echter dat de animatie op de hoofdthread wordt uitgevoerd, wat niet ideaal is, vooral niet tijdens het laden van pagina's.
We zijn van plan de standaardanimaties en algemene aanpassingen te detecteren en deze vervolgens opnieuw te interpreteren als door de compositor aangestuurde animaties voor een mooie prestatieverbetering.
Bereikte overgangen
Op dit moment zijn SPA-overgangen van toepassing op het hele document en kan er slechts één overgang tegelijk worden uitgevoerd. We willen een functie introduceren waarmee overgangen kunnen worden beperkt tot een bepaald element, zodat meerdere paginacomponenten afzonderlijk overgangen kunnen uitvoeren.
Hierdoor zou bijvoorbeeld een ingebedde videospeler weergaveovergangen kunnen gebruiken, tegelijkertijd met een ingebedde chatwidget.
Geneste overgangsgroepen
Op dit moment zijn alle ::view-transition-group broers en zussen. Dit is vaak een goede zaak, omdat weergaven hierdoor van de ene container naar de andere kunnen overgaan en u zich geen zorgen hoeft te maken over clippen.
Soms wilt u echter dat een weergave wordt geknipt door een ouder, die mogelijk ook bij de overgang betrokken is.
We willen een opt-in onderzoeken die een bepaalde ::view-transition-group binnen een andere ::view-transition-group plaatst.
Klassen van overgangen
Elke view-transition-name moet uniek zijn. Dat is hoe we vaststellen dat een bepaald element conceptueel "hetzelfde" is aan beide kanten van de DOM-verandering, zelfs als het niet letterlijk hetzelfde element is.
Soms moeten dingen met verschillende view-transition-name echter dezelfde soort animatie gebruiken. Op dit moment betekent dit dat er een selectieregel moet worden toegevoegd voor elke view-transition-name .
We willen graag een manier toevoegen om overgangsklassen te creëren om deze beperking te overwinnen.
Negeer offscreen-elementen
Als je een element een view-transition-name geeft, wordt het als zijn eigen groep bij de transitie betrokken. Soms is dit niet ideaal. Als u bijvoorbeeld een koptekst een view-transition-name geeft en u gaat van een staat waarin u 2000 pixels naar beneden wordt gescrolld naar een staat bovenaan de pagina, dan wordt de kop geanimeerd vanaf 2000 pixels afstand, wat qua timing verkeerd voelt.
In plaats daarvan willen we een opt-in toevoegen waarbij een element wordt genegeerd , alsof het geen view-transition-name heeft, als het zich volledig buiten de viewport bevindt.
Je kunt dit al doen met JavaScript door style.viewTransitionName dynamisch in te stellen, maar het voelt alsof we hiervoor een declaratieve oplossing moeten hebben.
requestAnimationFrame-gestuurde animaties
U kunt al weergaveovergangsanimaties maken met JavaScript via de webanimaties-API , maar soms moet u dingen frame voor frame aansturen met requestAnimationFrame .
Dat kun je al doen, maar het is een beetje hacky. Hier is een demo met enkele helpers die u wellicht nuttig vindt. We willen het niet-hacky maken!
We zullen dit in twee delen doen. Ten eerste door een API aan te bieden die aangeeft wanneer de animatie klaar is . En ten tweede door JavaScript-toegang te bieden tot pseudo-elementen . Dat tweede deel is misschien een behoorlijk grote klus, maar het voelt als het juiste om op de lange termijn te doen.
Maak nu een aantal geweldige weergaveovergangen!
Hopelijk ben je, net als ik, enthousiast over het heden en de toekomst van deze functie. Als je feedback hebt, of gewoon wilt pronken met enkele weergaveovergangen die je hebt gemaakt, of ze nu soepel en functioneel zijn , of gewoon dom , neem dan contact met me op via Twitter of Mastodon !