Die View Transition API ist ein Gamechanger für die Webentwicklung. Unabhängig davon, ob Ihre Website ein- oder mehrseitig ist, können Sie mit dieser leistungsstarken API 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.
Immer mehr Nutzer interessieren sich für die View Transition API. Daher ist es an der Zeit, einige Missverständnisse aus dem Weg zu räumen.
Irrtum 1: Die View Transition API erstellt Screenshots
Wenn ein Ansichtsübergang ausgeführt wird, erstellt die API Snapshots des alten und neuen Zustands der Inhalte. Diese Snapshots werden dann animiert, wie im Abschnitt Funktionsweise dieser Übergänge der Dokumentation beschrieben.
Für den alten Snapshot können Sie den Begriff „Screenshot“ verwenden. Der neue Snapshot ist jedoch keine Momentaufnahme, sondern eine Live-Darstellung des Knotens. Stellen Sie sich das als ersetztes Element vor.
::view-transition
└─ ::view-transition-group(root)
└─ ::view-transition-image-pair(root)
├─ ::view-transition-old(root) 👈 Screenshot
└─ ::view-transition-new(root) 👈 Live representation
Dank dieses Live-Aspekts funktionieren Demos wie diese: Das Video, das aus dem neuen Snapshot stammt, wird während des Ansichtsübergangs weiter abgespielt.
Die dafür verwendete Logik und das CSS werden in unserer Dokumentation ausführlich beschrieben.
Irrtum 2: Wenn mehr als ein Element erfasst wird, werden mehrere Ansichtsübergänge ausgeführt
Wenn Sie mehrere Elemente erfassen, werden beim Erstellen des Snapshots alle alten und neuen Status erfasst. Wenn Sie zusätzlich zum Element :root 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 es in Chrome nur möglich, gleichzeitig einen Ansichtsübergang pro Dokument auszuführen. Klicken Sie in dieser Demo schnell, um einen neuen Ansichtsübergang zu starten. Sie werden feststellen, dass der laufende Übergang zum Ende springt, wenn ein neuer beginnt.
Irrtum 3: Sie können keine Ansichtsübergänge implementieren, weil die Browserunterstützung fehlt
Viele Entwickler befürchten, dass sie Ansichtsübergänge nicht implementieren können, da diese Funktion nur in Chrome unterstützt wird. Die gute Nachricht ist, dass wir daran arbeiten und diese Funktion in der nächsten Version von Safari 18 einbinden werden.
Lassen Sie sich aber nicht davon abhalten, Ansichtsübergänge bereits jetzt zu implementieren. Ansichtsübergänge sind das perfekte Material für progressive Verbesserung. In der ursprünglichen Dokumentation wird eine Methode beschrieben, wie Sie diese Methodik in Ihren Code einfügen.
function handleClick(e) {
// Fallback for browsers that don't support this API:
if (!document.startViewTransition) {
updateTheDOMSomehow();
return;
}
// With a View Transition:
document.startViewTransition(() => updateTheDOMSomehow());
}
Wenn Ihr Browser Übergänge zwischen Ansichten desselben Dokuments unterstützt, wird die animierte Version angezeigt. Andernfalls wird die aktuelle Version angezeigt. 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 über Dokumente hinweg laufende Ansichtsübergänge. Browser, die diese Funktionen nicht unterstützen, ignorieren beim Parsen von Stylesheets das CSS-Opt-in.
Dieser Ansatz wurde erfolgreich im E-Commerce implementiert, wie in dieser Fallstudie beschrieben.
Irrtum 4: Ansichtsübergänge stören das inkrementelle Rendering
Es gibt Anzeigen, dass Bildübergänge das inkrementelle Rendering stören. 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, wenn sie „genügend“ Inhalt haben. In den meisten Browsern geschieht dies, nachdem alle Stylesheets in der <head> geladen, das gesamte JavaScript in der <head> geparst und ausreichend Markup geladen wurde. Das ändert sich auch nicht durch Ansichtsübergänge zwischen Dokumenten: Die für First Contentful Paint erforderlichen Inhalte bleiben unverändert. Nach diesem ersten Rendern kann und wird der Browser neu empfangene Inhalte inkrementell rendern.
Sie können das Rendering blockieren, bis ein bestimmtes Element im DOM vorhanden ist. Das ist praktisch, wenn Sie sicher sein möchten, dass die Elemente, die am Ansichtsübergang beteiligt sind, auf der neuen Seite vorhanden sind.
Verwenden Sie dazu dieses Link-Tag:
<link rel="expect" blocking="render" href="#elementId">
Dadurch werden die Heuristiken des Browsers überschrieben, mit denen entschieden wird, wann das erste Rendern ausgeführt wird. Das erste Rendern wird verzögert, bis das angegebene Element im DOM-Baum vorhanden ist.
Bei der manuellen Blockierung sind einige Sicherheitsvorkehrungen eingebaut. Wenn beispielsweise das schließende </html>-Tag erkannt wird, das blockierende Element aber nicht, wird das Rendering nicht mehr blockiert. Außerdem können Sie eine eigene Zeitüberschreitungslogik hinzufügen, mit der das blockierende Attribut jederzeit entfernt wird.
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.
Irrtum 5: Das Erstellen 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. Daher sieht ein Nutzer die alte Seite etwas länger als ohne Ansichtsübergänge. Diese Verzögerung ist jedoch vernachlässigbar und beträgt in der Realität 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 zusammengestellt und im Cache gespeichert wurden.
Außerdem werden die Daten für die Snapshots direkt aus dem Compositor übernommen. Es sind also keine zusätzlichen Layout- oder Neumalvorgänge erforderlich, um die Snapshot-Daten zu erhalten.
Zusätzliche Fehlinformation: Es ist die View Transitions API
Wenn von Ansichtsübergängen die Rede ist, wird häufig die „View Transitions API“ verwendet. Das ist falsch. Die API heißt „View Transition API“ (Ansichtsübergang-API).
Der Irrtum rührt daher, dass in einigen Artikeln – einschließlich unserer eigenen DCC-Dokumente – der falsche Begriff verwendet wurde.
Der Trick, sich den richtigen Namen zu merken, besteht darin, dass Sie die View Transition API verwenden, um eine oder mehrere Ansichtsübergänge zu erstellen.