View Transitions: Mehr Möglichkeiten, weniger Bewegung

An den Übergängen dieser Website lässt sich ziemlich gut ablesen, wie ich über Animation denke. Wir haben auffälligere Varianten ausprobiert und sind wieder bei einem ruhigen Ausblenden und Einblenden gelandet. Die interessantere Technik war nicht automatisch die bessere Gestaltung.

Das beschäftigt mich gerade wieder, weil die View Transition API mehr Möglichkeiten bekommt. Besonders spannend finde ich Übergänge, die nur einen Teil der Oberfläche betreffen. Eine sortierte Liste verändert sich, während ich daneben weiterarbeiten kann. Dafür sehe ich deutlich mehr sinnvolle Anwendungen als für die nächste bildschirmfüllende Inszenierung.

Was dieses Jahr dazugekommen ist

Chrome 147 hat elementbezogene View Transitions eingeführt. Über Element.startViewTransition() lässt sich ein Übergang auf einen DOM-Teilbaum begrenzen. Dadurch werden auch gleichzeitige und verschachtelte Übergänge möglich. Die Ankündigung vom 27. März 2026 beschreibt diesen Schritt und zeigt Beispiele. Das ist eine konkrete Chrome-Veröffentlichung, keine Zusage für sämtliche Browser. Chrome: Element-scoped View Transitions

Ich finde daran vor allem die Begrenzung interessant. Wenn sich eine Karte verändert, sollte meine Navigation nicht ebenfalls Teil einer Animation werden. Wenn ich eine Liste filtere, möchte ich erkennen, welche Einträge bleiben. Der Effekt sollte mir diese Veränderung erklären.

Die dokumentweite Variante verwendet dagegen document.startViewTransition(). Sie erfasst den Zustand vor und nach einer DOM-Aktualisierung innerhalb desselben Dokuments. Navigation zwischen getrennten Dokumenten ist ein eigener Anwendungsfall und braucht eine andere Einrichtung. MDN: Document.startViewTransition

Erst eine funktionierende Änderung, dann der Übergang

Für einen kleinen Versuch reicht mir eine Funktion, die eine vorhandene Karte aktualisiert. Das folgende JavaScript ist bewusst ein isoliertes Beispiel für eine bereits gerenderte Oberfläche. Es ist keine Anleitung, DOM-Manipulation mit dem Zustandsmodell eines React-Routers zu vermischen.

function updateCard(card, update) {  const reduced = matchMedia(    '(prefers-reduced-motion: reduce)'  ).matches;
  if (reduced || typeof card.startViewTransition !== 'function') {    update();    return;  }
  card.startViewTransition(update);}
const card = document.querySelector('[data-status]');if (card) {  updateCard(card, () => {    card.textContent = 'Gespeichert';  });}

Der wichtige Teil ist für mich der direkte Aufruf von update(), wenn der Effekt nicht verfügbar oder nicht gewünscht ist. Die Karte funktioniert trotzdem. Eine Animation darf niemals Voraussetzung dafür sein, dass eine Änderung sichtbar wird.

Die Einstellung für reduzierte Bewegung lässt sich mit prefers-reduced-motion abfragen. Ich behandle sie als echte Gestaltungsanforderung und überspringe hier den Übergang vollständig. MDN: prefers-reduced-motion

Meine Reihenfolge bei der Gestaltung

Ich beginne mit der Oberfläche ohne Animation. Bleiben Abstände stabil? Ist nach einer Navigation klar, wo ich bin? Springt der Inhalt beim Laden eines Bildes? Solche Probleme verschwinden nicht durch einen Fade. Manchmal fallen sie während des Fades sogar stärker auf.

Erst danach entscheide ich, ob ein Übergang hilft. Für einen Seitenwechsel genügt mir häufig eine kurze Überblendung. Für eine Galerie kann die erkennbare Verbindung zwischen Vorschaubild und großem Bild hilfreich sein. In einer dichten Arbeitsoberfläche würde ich Bewegung noch sparsamer einsetzen.

Anschließend probiere ich schnelle wiederholte Klicks, lange Inhalte und den Zurück-Button. Eine Animation, die beim sorgfältig vorbereiteten ersten Klick gut aussieht, ist noch keine belastbare Interaktion.

Die neuen APIs machen lokale Übergänge interessanter. Meine gestalterische Regel bleibt trotzdem einfach: Ich möchte Veränderungen verständlicher machen. Sobald ich die Animation stärker wahrnehme als die Veränderung selbst, nehme ich wieder etwas heraus.