Missverständnisse bezüglich Aufrufübergängen

Die View Transition API ist ein Gamechanger für die Webentwicklung. Egal, ob Ihre Website eine oder mehrere Seiten hat, mit dieser leistungsstarken API können Sie nahtlose Übergänge zwischen den Ansichten erstellen. Das sorgt für eine native Benutzeroberfläche, die Nutzer begeistert. Derzeit in Chrome verfügbar, bald auch in Safari.

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.

Ein wiedergegebenes Video, das an einem Ansichtsübergang teilnimmt Minimale Demo. Quelle.

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)

Obwohl dieser Baum mehrere Snapshot-Paare enthält, wird nur eine einzige Ansichtsübergang 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 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. Mit der Zeit, wenn immer mehr Browser Ansichtsübergänge unterstützen, können immer mehr Nutzer diese erweiterte Version automatisch nutzen.

Dasselbe gilt für Übergänge zwischen Dokumentansichten. In Browsern, die sie nicht unterstützen, wird die CSS-Opt-in-Funktion beim Parsen von Stylesheets ignoriert.

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 Ansichtsübergänge das inkrementelle Rendering stören. Das ist nicht richtig: Dokumentübergreifende Ansichtsübergänge wurden so festgelegt, dass dieser grundlegende Aspekt des Webs nicht beeinträchtigt wird.

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 verwendet werden sollte. Die Auswirkungen des Blockierens des Renderings müssen von Fall zu Fall bewertet werden. Verwenden Sie blocking=render standardmäßig nur, wenn Sie die Auswirkungen auf Ihre Nutzer aktiv messen und bewerten 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 führt pageswap beispielsweise zu höchstens zwei veralteten Frames: einem für die Ausführung der Logik und einem zusätzlichen Frame, um sicherzustellen, dass Snapshots zusammengesetzt 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“ erwähnt. 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, ist, dass Sie die View Transition API verwenden, um eine oder mehrere Ansichtsübergänge zu erstellen.