Die View Transition API ist ein Game Changer für die Webentwicklung. Ganz gleich, ob Ihre Website ein- oder mehrseitig ist – mit dieser leistungsstarken API können Sie nahtlose Übergänge zwischen Ansichten schaffen und so nativ gestaltete Inhalte erstellen, die die Nutzer begeistern. Derzeit in Chrome verfügbar, Änderungen der Dokumentansicht sind bald auch in Safari verfügbar.
Da sich immer mehr Menschen die View Transition API ansehen, ist es an der Zeit, einige Missverständnisse aufzuräumen.
Missverständnis 1: Die View Transition API erstellt Screenshots
Beim Ausführen einer Ansichtsumstellung erstellt die API Snapshots des alten und des neuen Status des Inhalts. Diese Momentaufnahmen werden dann animiert, wie im Abschnitt "Funktionsweise dieser Übergänge" der Dokumentation beschrieben.
Sie können den Begriff „Screenshot“ für den alten Snapshot verwenden. Der neue Snapshot ist jedoch kein Screenshot, sondern eine Live-Darstellung des Knotens. Betrachten Sie es als ersetztes Element.
::view-transition
└─ ::view-transition-group(root)
└─ ::view-transition-image-pair(root)
├─ ::view-transition-old(root) 👈 Screenshot
└─ ::view-transition-new(root) 👈 Live representation
Durch diesen Live-Aspekt funktionieren Demos wie diese: Das Video, das aus der neuen Momentaufnahme stammt, wird während des Übergangs zwischen den Ansichten weiter abgespielt.
Die hierfür verwendete Logik und der CSS-Code sind in unserer Dokumentation ausführlich beschrieben.
Missverständnis 2: Beim Erfassen von mehr als einem Element werden mehrere Ansichtsübergänge ausgeführt.
Wenn Sie mehrere Elemente erfassen, werden bei der Erstellung von Snapshots alle alten und neuen Zustände erfasst. Wenn Sie zusätzlich zum :root-Element ein .box erfassen, erhalten Sie diesen Pseudobaum:
::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)
Diese Baumstruktur enthält zwar mehrere Snapshot-Paare, aber nur ein einziger Ansichtsübergang wird ausgeführt.
Derzeit ist in Chrome nur eine Ansichtsumstellung pro Dokument gleichzeitig möglich. Klicke in dieser Demo schnell auf die Schaltfläche, um einen neuen Übergang zwischen den Ansichten zu starten. Sie werden feststellen, dass der laufende Wechsel ans Ende gesprungen ist, wenn ein neuer beginnt.
Missverständnis Nr. 3: Ansichtsübergänge können aufgrund der Browserunterstützung nicht implementiert werden
Viele Entwickler befürchten, dass sie keine Übergänge für Ansichten implementieren können, da diese Funktion nur von Chrome unterstützt wird. Die gute Nachricht ist, dass Safari daran arbeitet und es in der kommenden Safari 18-Version enthalten wird.
Lassen Sie sich dennoch nicht von gestörter Browserunterstützung daran gehindert, Ansichtenübergänge zu implementieren. Ansichtsübergänge sind das perfekte Material für das progressive Verbesserung. In der Originaldokumentation wird eine Methode beschrieben, wie Sie diese Methode in Ihren Code einfügen können.
function handleClick(e) {
// Fallback for browsers that don't support this API:
if (!document.startViewTransition) {
updateTheDOMSomehow();
return;
}
// With a View Transition:
document.startViewTransition(() => updateTheDOMSomehow());
}
Falls Ihr Browser Übergänge bei der Ansicht im selben Dokument unterstützt, erhalten Sie die angereicherte, animierte Version. Wenn dies bei Ihrem Browser nicht der Fall ist, können Sie die aktuelle Version nutzen. Da immer mehr Browser den Wechsel zwischen den Ansichten unterstützen, wird diese angereicherte Version automatisch für immer mehr Nutzer freigeschaltet.
Dasselbe gilt für dokumentübergreifende Übergänge. Browser, die diese Funktionen nicht unterstützen, ignorieren beim Parsen von Stylesheets das CSS-Opt-in.
Dieser Ansatz wurde im E-Commerce erfolgreich implementiert, wie in dieser Fallstudie beschrieben wird.
Missverständnis 4: Durch Wiedergabeübergänge wird das inkrementelle Rendering unterbrochen.
Es gibt Ansprüche, die das inkrementelle Rendering durch Aufrufübergänge unterbrechen. Das stimmt nicht: Dokumentübergreifende Übergänge für die Ansicht wurden angegeben, um diesen grundlegenden Aspekt des Webs nicht zu stören.
Browser beginnen mit dem Rendern einer Seite, sobald sie „genügend“ Content haben. In den meisten Browsern geschieht dies, nachdem alle Stylesheets im <head> geladen, alle das Rendering blockierende JavaScript im <head> geparst und ausreichend Markup geladen wurden. Bei dokumentübergreifenden Übergängen der Ansicht ändert sich nichts: Der für First Contentful Paint erforderliche Inhalt bleibt unverändert. Nach diesem ersten Rendern kann der Browser neu empfangene Inhalte inkrementell rendern.
Sie können das Rendering blockieren, bis ein bestimmtes Element im DOM vorhanden ist. Dies ist in Situationen praktisch, in denen Sie sicherstellen möchten, dass die am Ansichtsübergang beteiligten Elemente auf der neuen Seite vorhanden sind.
Verwenden Sie dazu dieses Link-Tag:
<link rel="expect" blocking="render" href="#elementId">
Dadurch wird die Heuristik des Browsers überschrieben, mit der entschieden wird, wann das erste Rendering durchgeführt wird: Das erste Rendering wird verzögert, bis das angegebene Element in der DOM-Struktur vorhanden ist.
Bei dieser manuellen Blockierung sind einige Sicherheitsmaßnahmen integriert. Wenn beispielsweise das schließende </html>-Tag erkannt wird, das blockierende Element jedoch nicht, wird das Rendering nicht mehr blockiert. Darüber hinaus können Sie Ihre eigene Zeitüberschreitungslogik hinzufügen, die das Attribut zum Blockieren jederzeit entfernt.
Es ist offensichtlich, dass das Blockieren des Renderings mit Vorsicht eingesetzt werden sollte. Welche Auswirkungen das Blockieren des Renderings hat, muss von Fall zu Fall bewertet werden. Standardmäßig sollten Sie blocking=render nur verwenden, wenn Sie die Auswirkungen auf Ihre Nutzer aktiv messen und messen können, indem Sie die Auswirkungen auf Ihre Leistungsmesswerte messen.
Missverständnis 5: Die Erstellung von Snapshots ist langsam oder teuer
Während die View Transition API die neue Ansicht vorbereitet und ihre Snapshots abruft, bleibt die alte Ansicht für den Nutzer sichtbar. Aus diesem Grund wird einem Nutzer die alte Seite etwas länger angezeigt als ohne Übergänge in der Ansicht. Diese Verzögerung ist jedoch vernachlässigbar, in Wirklichkeit sind es nur wenige Frames. In Chrome wirkt sich pageswap beispielsweise auf maximal zwei veraltete Frames aus: einer zum Ausführen der Logik und ein zusätzlicher Frame, um sicherzustellen, dass Snapshots zusammengesetzt und im Cache gespeichert wurden.
Darüber hinaus werden die Daten für die Snapshots direkt aus dem Compositor übernommen, sodass keine zusätzlichen Layout- oder Darstellungsschritte erforderlich sind, um die Snapshot-Daten abzurufen.
Bonus-Missverständnis: Es ist die View Transitions API
Wenn es um Aufrufübergänge geht, wird oft die View Transitions API verwendet. Das ist falsch. Die API wird als „View Transition API“ bezeichnet. Beachten Sie den Singular „Transition“.
Dieser Irrtum ergibt sich aus einigen Artikeln – darunter auch aus unseren eigenen Dokumenten auf DCC – die Verwendung des falschen Begriffs.
Der Trick, sich den richtigen Namen zu merken, besteht darin, dass Sie die (eine) View Transition API verwenden, um einen oder mehrere Ansichtsübergänge zu erstellen.