Angular-Animationen mit CSS und animate.enter sauber umsetzen

Ein Menü soll nicht plötzlich erscheinen, ein Dialog nicht ruckartig verschwinden und ein Seitenwechsel soll sich nicht wie ein harter Schnitt anfühlen. Die englische Bezeichnung angular animations umfasst genau diese Bewegungen in Angular-Anwendungen. Ich zeige, welche Methode 2026 für neue Projekte sinnvoll ist, wie animate.enter und animate.leave funktionieren, wann CSS ausreicht und wo Performance, Barrierefreiheit und ältere Angular-APIs Grenzen setzen.

Welche Animationsmethode passt zu einer Angular-Anwendung

Die meisten Bewegungen in einer Webanwendung sind kleiner, als man zunächst denkt. Ein Dialog wird sichtbar, eine Karte wird entfernt, ein Akkordeon öffnet sich oder ein Ladeindikator verändert seinen Zustand. Für solche Fälle würde ich keine zusätzliche Animationsbibliothek einführen, sondern Angular mit nativer CSS-Unterstützung kombinieren.

Der entscheidende Unterschied liegt zwischen einer Zustandsänderung und dem Einfügen oder Entfernen eines Elements. Ein aufgeklapptes Menü bleibt im DOM und wechselt nur seine Darstellung. Ein Dialog, der durch @if aus dem Template verschwindet, braucht dagegen eine Leave-Animation, damit Angular den Knoten erst nach dem Effekt entfernt.

Die frühere Trigger-Syntax mit trigger(), state() und transition() funktioniert in bestehenden Anwendungen weiterhin. Für neue Komponenten würde ich sie im Jahr 2026 jedoch nicht mehr als erste Wahl verwenden, weil die Angular-API als veraltet markiert ist und die native CSS-Variante meist einfacher zu lesen bleibt.

Ein- und Ausblenden mit animate.enter und animate.leave

Die moderne Angular-Lösung bindet eine CSS-Klasse direkt an den Lebenszyklus eines Elements. Beim Einfügen fügt animate.enter die angegebene Klasse hinzu. Angular entfernt sie nach dem längsten laufenden Effekt wieder. Für das Entfernen übernimmt animate.leave die Animation und wartet, bevor der Knoten aus dem DOM verschwindet.

Ein Element weich einblenden

Ein kleines Beispiel reicht, um das Prinzip zu zeigen. Der Zustand wird mit einem Signal verwaltet, während die eigentliche Bewegung vollständig in CSS bleibt.

import { Component, signal } from '@angular/core';

@Component({
  selector: 'app-panel',
  templateUrl: './panel.html',
  styleUrl: './panel.css'
})
export class PanelComponent {
  isVisible = signal(false);

  toggle() {
    this.isVisible.update(value => !value);
  }
}

  Panel anzeigen


@if (isVisible()) {
  

    
Neue Nachricht
    
Das Panel erscheint mit einer kurzen Bewegung.
  
}

.panel {
  padding: 1rem;
  border: 1px solid #d8dee9;
  border-radius: 0.75rem;
  background: white;
}

.panel-enter {
  animation: panel-in 220ms ease-out;
}

@keyframes panel-in {
  from {
    opacity: 0;
    transform: translateY(0.75rem);
  }

  to {
    opacity: 1;
    transform: translateY(0);
  }
}

Die Bewegung dauert hier 220 Millisekunden. Das wirkt bei einem kleinen Panel schnell genug, ohne hektisch zu sein. Aus meiner Erfahrung sind kurze Einblendungen zwischen etwa 150 und 300 Millisekunden für Standardoberflächen meist angenehmer als Effekte von einer Sekunde, die jede kleine Interaktion unnötig in die Länge ziehen.

Beim Entfernen nicht nur opacity ändern

Für das Ausblenden wird die Klasse direkt mit animate.leave verbunden. Das Element bleibt während der Animation vorhanden, obwohl der Angular-Zustand bereits auf unsichtbar gesetzt wurde.

@if (isVisible()) {
  

    
Nachricht
    
Dieser Inhalt wird vor dem Entfernen ausgeblendet.
  
}

.panel-leave {
  animation: panel-out 180ms ease-in forwards;
}

@keyframes panel-out {
  from {
    opacity: 1;
    transform: translateY(0);
  }

  to {
    opacity: 0;
    transform: translateY(-0.5rem);
  }
}

Ein häufiger Fehler ist eine CSS-Klasse ohne tatsächliche Dauer oder mit einer Animation, die sofort endet. Dann kann der Effekt unsichtbar bleiben. Ich prüfe deshalb zuerst im Browser-Inspektor, ob die Klasse angelegt wird und ob eine berechenbare Animationsdauer vorhanden ist.

Zustände mit CSS-Transitions sauber animieren

Nicht jedes Verhalten ist ein Enter- oder Leave-Fall. Ein Akkordeon, ein aktiver Navigationspunkt oder ein Umschalter bleibt im DOM und verändert nur Klassen. Dafür ist eine CSS-Transition meist die klarste Lösung.

 !value)">
  Details



  
Zusätzliche Informationen werden angezeigt.

.details {
  max-height: 0;
  overflow: hidden;
  opacity: 0;
  transform: translateY(-0.25rem);
  transition:
    max-height 220ms ease,
    opacity 180ms ease,
    transform 180ms ease;
}

.details-open {
  max-height: 20rem;
  opacity: 1;
  transform: translateY(0);
}

Bei max-height muss der Zielwert groß genug für den Inhalt sein. Das ist praktisch, aber nicht perfekt, weil die Höhe des Inhalts dynamisch sein kann. Für variable Inhalte würde ich entweder eine moderne Layoutstrategie verwenden oder die Höhe gezielt per JavaScript messen. Ein beliebiges transition: all wirkt bequem, erschwert aber die Kontrolle und kann unnötige Eigenschaften animieren.

Für sichtbare Bewegungen bevorzuge ich grundsätzlich opacity und transform. Eigenschaften wie top, left, width oder height können das Layout neu berechnen lassen. Bei wenigen Elementen fällt das kaum auf, in langen Listen oder komplexen Dashboards kann es jedoch zu Rucklern führen.

Keyframes für wiederholbare Effekte

Keyframes sind dann hilfreich, wenn ein Effekt mehrere Zwischenstationen hat. Ein kurzer Hinweis kann beispielsweise leicht aufsteigen, sichtbar werden und anschließend wieder in seine normale Position gleiten. Die Klasse bleibt klein, während die Bewegungslogik in einer wiederverwendbaren CSS-Datei liegt.

.notification-enter {
  animation: notification-in 360ms cubic-bezier(0.2, 0.8, 0.2, 1);
}

@keyframes notification-in {
  0% {
    opacity: 0;
    transform: translateY(1rem) scale(0.98);
  }

  70% {
    opacity: 1;
    transform: translateY(-0.15rem) scale(1);
  }

  100% {
    transform: translateY(0);
  }
}

Solche kleinen Überschwinger können eine Oberfläche lebendig machen. Ich setze sie aber sparsam ein, denn eine Bewegung sollte die Hierarchie der Oberfläche unterstützen und nicht selbst zum wichtigsten Ereignis werden.

Routenwechsel und externe Animationsbibliotheken

Bei Navigationen zwischen Seiten oder größeren Ansichten kann die native View Transitions API interessant sein. Angular Router unterstützt diese Technik, allerdings ist die Integration laut offizieller Dokumentation noch als Developer Preview gekennzeichnet. Deshalb würde ich sie zuerst in einer Anwendung testen, deren Zielbrowser und Fallback-Verhalten klar feststehen.

View Transitions arbeiten mit einem alten und einem neuen visuellen Zustand. CSS-Selektoren wie ::view-transition-old() und ::view-transition-new() können deren Darstellung beeinflussen. Die zugehörigen Regeln gehören in globale Styles, weil die gekapselten Component Styles diese Pseudo-Elemente nicht zuverlässig erreichen.

import { provideRouter, withViewTransitions } from '@angular/router';

bootstrapApplication(AppComponent, {
  providers: [
    provideRouter(routes, withViewTransitions())
  ]
});

Für viele Unternehmensanwendungen reicht jedoch ein ruhiger Wechsel ohne spektakuläre Seitenanimation. Wenn Nutzer häufig zwischen Ansichten springen, kann ein langer Übergang sogar bremsen. Ich würde zuerst testen, ob die Navigation mit einer kurzen visuellen Kontinuität verständlicher wird, und nicht automatisch jede Route animieren.

Wann GSAP sinnvoll wird

Bibliotheken wie GSAP lohnen sich bei komplexen, interaktiven Bewegungen, etwa bei Drag-and-Drop-Szenarien, verschachtelten Sequenzen, physikalischen Effekten oder synchronisierten Timelines. Angular unterstützt dafür Callback-Funktionen bei animate.enter und animate.leave.

Beim manuellen Leave-Effekt muss die Callback-Funktion event.animationComplete() aufrufen. Sonst weiß Angular nicht sicher, wann das Element entfernt werden darf. Ohne diesen Aufruf greift zwar ein Timeout, doch ein solches Sicherheitsnetz sollte nicht die normale Ablaufsteuerung ersetzen.

leaveAnimation(event: AnimationCallbackEvent) {
  // Beispiel für eine externe Bibliothek
  gsap.to(event.target, {
    opacity: 0,
    y: 16,
    duration: 0.2,
    onComplete: () => event.animationComplete()
  });
}

Der Preis für diese Freiheit ist mehr Abhängigkeit, mehr Testaufwand und eine zusätzliche Abstraktion zwischen Angular und dem DOM. Für ein ein- oder ausgeblendetes Menü wäre das aus meiner Sicht überdimensioniert. Bei einer stark visuellen Anwendung kann es dagegen die bessere Investition sein.

Barrierefreiheit, Performance und Tests gehören zur Animation

Reduzierte Bewegung anbieten

Animationen können bei Menschen mit vestibulären Beschwerden Unwohlsein auslösen. Eine respektvolle Anwendung reagiert deshalb auf die Systemeinstellung prefers-reduced-motion. Dabei muss nicht jede Bewegung vollständig verschwinden, aber große Verschiebungen und wiederholte Effekte sollten auf ein Minimum reduziert werden.

@media (prefers-reduced-motion: reduce) {
  *,
  *::before,
  *::after {
    animation-duration: 1ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 1ms !important;
    scroll-behavior: auto !important;
  }
}

Bei Dialogen und Menüs ist außerdem der semantische Zustand wichtig. aria-expanded, Fokusmanagement und Tastaturbedienung dürfen nicht von der Animation abhängen. Ein Panel gilt für die Bedienung bereits als geöffnet, auch wenn der Übergang noch 150 Millisekunden läuft.

Die richtigen CSS-Eigenschaften verwenden

Für flüssige Effekte sind transform und opacity meistens eine gute Basis. Schatten, Filter und große Blur-Werte können auf schwächeren Geräten trotzdem teuer werden. Ich teste Animationen deshalb nicht nur auf einem schnellen Entwicklerrechner, sondern auch auf einem mittelmäßigen Smartphone und mit einer langen Liste von Elementen.

Eine Animation sollte außerdem nicht die Interaktion blockieren. Ein Button, der während eines 900-Millisekunden-Effekts nicht erneut bedienbar ist, fühlt sich schnell kaputt an. Für zentrale Aktionen halte ich unter 300 Millisekunden oft für einen guten Ausgangspunkt, bei Dialogen oder komplexeren Übergängen kann etwas mehr Zeit vertretbar sein.

Lesen Sie auch: Softwarebeispiele für Webentwicklung und passende Frameworks

Tests nicht auf das visuelle Ergebnis beschränken

Angular deaktiviert Animationen in Testumgebungen standardmäßig. Das ist sinnvoll, weil Unit-Tests nicht auf Browser-Timings warten sollten. Ich teste deshalb im normalen Komponententest vor allem, ob der Zustand korrekt wechselt, die passende Klasse erscheint und ARIA-Attribute aktualisiert werden.

Das tatsächliche Bewegungsgefühl gehört in einen Browser- oder End-to-End-Test. Dort sollte geprüft werden, ob Elemente nach einem Leave-Effekt wirklich entfernt werden, ob kein Overlay unsichtbar im DOM liegen bleibt und ob die Anwendung bei reduzierter Bewegung weiterhin vollständig bedienbar ist.

Alte Angular-Animationen sicher ablösen

In älteren Projekten findet man häufig das Paket @angular/animations zusammen mit BrowserAnimationsModule, provideAnimations() und Triggern wie trigger('openClose', ...). Diese APIs sind nicht plötzlich unbrauchbar, aber Angular markiert sie seit Version 20.2 als veraltet und empfiehlt für neuen Code native CSS-Animationen mit animate.enter und animate.leave.

Eine komplette Umstellung in einem einzigen Schritt ist selten nötig. Ich würde zuerst einfache Ein- und Ausblendungen migrieren, danach Zustandswechsel und erst zuletzt komplizierte Sequenzen. So bleibt jede Änderung klein und lässt sich visuell wie funktional prüfen.

• Einfacher Einstieg: Ersetze Trigger für Enter- und Leave-Fälle durch CSS-Klassen.
• Zustände trennen: Verwende [class.klasse] für Elemente, die im DOM bleiben.
• Komplexe Logik prüfen: Behalte eine Bibliothek nur dort, wo sie echte Vorteile bringt.
• Keine Mischformen in einer Komponente: Legacy-Animationen und die neuen Enter- und Leave-Mechanismen können dort zu unerwarteten Zuständen führen.
• Schrittweise testen: Kontrolliere besonders Listen, Dialoge, Projektionen und verschachtelte dynamische Inhalte.

Der größte Migrationsgewinn ist nicht nur weniger Code. CSS-Animationen lassen sich leichter außerhalb der Component-Logik betrachten, von Designern anpassen und mit Browserwerkzeugen untersuchen. Bei sehr alten Angular-Versionen müssen die konkreten Syntaxmöglichkeiten allerdings zuerst geprüft werden.

Ein klares Bewegungsbudget hält Angular-Oberflächen schnell

Gute Angular-Animationen beantworten eine kleine Frage des Nutzers: Ist der Klick angekommen, wo ist der Inhalt hingegangen oder welche Ansicht ist jetzt aktiv? Für neue Komponenten würde ich deshalb mit CSS, kurzen Übergängen und den nativen Enter- und Leave-APIs beginnen.

Erst wenn ein konkreter Effekt darüber hinausgeht, kommen View Transitions oder eine Bibliothek wie GSAP ins Spiel. Wer zusätzlich reduzierte Bewegung, Fokusverhalten, reale Geräte und das Entfernen von DOM-Knoten testet, erhält nicht nur eine schönere Oberfläche, sondern eine Anwendung, die sich auch unter echten Bedingungen stabil und verständlich anfühlt.