Amazing idea!

Q2: no

Q3: animate.out

Great Idea. Especially the Callbacks will be very useful in my opinion.

Wow 🤩, it would be great to use and implement all these powerful new CSS properties and get the full potential out of them. In my opinion, as I said earlier in the comments, the callback function will be the best feature proposed compared to what already exists (KIS 👍 ).

Q1 : Yes

Q2 : No, not really useful

Q3: No preferences as long as it's explicit

Q4: Callback function, 100% for simplicity and readability

Q5: To be able to debug / track problems with transitions or performance losses linked to animations in Angular Devtools( or to add direct compatibility with what Chrome already offers)

Q1: No, as it easily would lead to "too much logic in template", while not providing any additional use-cases.
Q2: Also, no, for the same reason. It will lead to things that should have be done with CSS-only, but now will use JS.
Q3: I slightly preferenter andleave.
Q4: Option#1. The callback is simpler to grok. Also, it doesn't require creating additional synthetic events, and doesn't add the cognitive overhead of the promise constructor.
Q5: Get out of the way. In 98% of the cases I encountered, animations add visual clues, but don't make a difference for the app's logic. The 2% where it does make a difference should be watched in e2e more as in unit tests.

I think these Animations would be very useful. Other frameworks require external libs for handling the animate-out for example. It would be really nice to have such features.

Q1: It's a good idea but I also would offer to style the animation in a Stylesheet by a custom CSS selector, since Angular is known to be better scalable in large codebase and separating HTML and CSS / SCSS is always a good idea.

Q2: To keep it consistent I would prefer animate.in. As a framework user I would expect to have the opposite of animate.out. Another reason for having an animate.in is to pass some handler function to animate.in. This behavior is not covered by CSS / SCSS and can be a new feature.

Q3: It's shorter to writeanimate.in oranimate.out instead without having a tradeoff in understanding, so I would prefer these.

Q4: In this caseOption 1 is more modern and doesn't require any creation or handling of Promises by offering the same features. It's API is clearer.

Q5: Testing an element with the new Vitest Support (or different Unit-, E2E-Frameworks) against before/after styling states can detect breaks in Styles. But instead, I would first focus on a clear animation API since testable animations on the presentational layer are a bit to overcomplicated by now.

Hey!

Just a point related to the FAQ / 3): I understand they are not directives... but my ng-brain is a bit confused by the syntax. 😅
I wonder: any explanation why we can't pretend they are directives?

Say, in a way changing the set of trade-offs:

<!-- I'd jump directly to the potential selectorless notation (just a draft) --><example-cmpanimate.out="fancy-animation-class"/><!-- IMHO this one is really off --><example-cmp@animate(out="fancy-animation-class")/><example-cmp[animate.out]="myDynamicCSSClasses"/><example-cmp@animate([out]="myDynamicCSSClasses")/><other-example-cmp(animate.out)="animateFn($event)"/><other-example-cmp@animate((out)="animateFn($event)")/>

Consequences:

• no directives / old animations namedanimate (forbidden),
• special treatment compared to regular directives (but I guess it would be more or less the same with the current proposal),
• newcomers can flag the feature as directives without any issue (no special syntax, ...). One day, there will be a "what???" moment and that's it!

Just an idea: I hope I haven't missed anything obvious!

I heard that the team is moving to native CSS styles from the Material team when proposing animation improvements, and finally here it is! The new solution is quite flexible and ergonomic, and I especially like that the function pattern supports third party animation libraries.

Btw, I guess the Vue team is the first to come up with the idea to toggle classes for animations. Evan You 👍

Q1: No. I personally is very against writing plain styles in the template.

Q2: I do prefer havinganimate.in. I think it would make the animation behaviors more predictable by looking only at the template.

Q3: I proposeanimation.enter andanimation.leave, for maximum semantic correctness and symmetry. Using verbs for bindings just feels off to me, so I preferanimation overanimate. I preferenter andleave because they are professional and symmetric.

Q4: I prefer Option 2. Why should we introduce a magic method if there is a Web standard for extending events, which is perfect for our use case? In practice, rather thannew Promise and stuff, we can create async helper methods to wrap the animation logic, so it would simply be:event.waitUtil(performFadeIn(event))

Q5: I would like to manually re-trigger enter and leave animations. I can imagine there are a lot of edge cases to handle but I still would like to re-trigger them if possible.

One feature that I really missed in the new API is to block child animations when parent animations are performing, and the ability to manually start or delay child animations.

Nice to see some input/discussion. I already wondered after the previous discussions around animations that we'd be seeing something like this. Good to get some input.

I would prefer enter/leave as that tells me more regarding what animation to expect. To me in/out can also relate to the direction or influence of the animation.

What I do wonder, for many animations I also need to do classes while it is animating. A common use case is not showing overflow scrollbars while the component is shrinking. Or alignment issues that may arise. Or making sure that the element animates between x and y. And so on. So that we move from something that is hidden, to something is animating, to something that is visible to something that is animating again and to something that is hidden once more. Where do these events/classes take place? Is this the part while animating or is this the hidden/visible parts? Am I right to assume that you would combine this with an@if or something and that the enter/leave are classes that take place while showing/hiding?

Discussion Question 1: Should these options support setting styles directly like ngStyle bindings? (seeexample)

I don't believe that's necessary. Given that bothstring/array values are supported, this should make Tailwind and other atomic CSS be able to do similar to whatngStyle does anyway.

Discussion Question 2: Is animate.in strictly necessary given the platform supports this behavior already?

I don't feel strongly here. I would prefer using@starting-style, but the argument for symmetry makes some sense. If it's tree-shakeable, I don't see any downside (except larger API surface for the Angular team).

Discussion Question 3: What is your preference on the naming? animate.in and animate.out? animate.enter and animate.leave? Something else?

While I do like the terseness ofin/out, I wonder if it would be better to align with@starting-style, such as using perhapsstart/end orstart/exit. I don't thinkenter/leave is better in any way, other than that it helps keep terminology from@angular/animations. I think my preferred order would be:

1. [animate.start] +[animate.end]
2. [animate.start] +[animate.exit]
3. [animate.in] +[animate.out]
4. [animate.enter] +[animate.leave]

Discussion Question 4: Which of these 2 options for using functions is the most ideal to you, and why? Do you have an alternative suggestion?

Option 2, for a couple of reasons. APromise fits well with the mental model of something that "completes later" (inherent with transition/animation), as well as fitting better with existingelement.getAnimations() and theAnimation.finished property.

animateFn=(event:AnimationEvent)=>{constallDone=Promise.all(event.element.getAnimations().map(a=>a.finished));event.waitUntil(allDone);}

The example provided for this option can be simplified usingPromise.withResolvers(). This adds minimal overhead to the callback-based example, and the API makes it aligns well with other web platform features like Service Workers.

animateFn=(event:AnimationEvent)=>{const{ promise, resolve}=Promise.withResolvers();animate(event.element,{x:'16rem',delay:500,loop:2,alternate:true,onComplete:resolve,});event.waitUntil(promise);}

Discussion Question 5: What would you want out of testing tools for animations?

Not sure I would actually test animations personally in unit tests. As long as the everything looks right after enter/leave animations.

1. Should animate.in and animate.out support direct styles (like ngStyle)?
Yes, but only for simple cases, like an option that u can have. It would be useful to set quick animations without creating CSS classes (I know its not a good practice but still). For example:

<div [animate.out]="{ opacity: 0, transition: '0.5s' }"></div>

But for complex animations, CSS classes (and tailwind) are still better because they keep the code clean.

2. Isanimate.in really needed if CSS already has@starting-styles?
To make Angular more consistent, Yes. If we haveanimate.out, it’s good to haveanimate.in too as well. Also,animate.in can automatically remove CSS classes after the animation as said, which@starting-styles doesn’t do.

3. What names are better? animate.in/out or animate.enter/leave?
animate.enter andanimate.leave are clearer names imo. They are easier to understand, especially for new developers. Other frameworks like Vue use similar names (enter/leave, I don't think they changed it), so it’s a familiar pattern.

4. Which is better callback function or ExtendableEvent?
The first option for me, is simpler and more familiar, why familiar? 'cus GSAP and Anime.js they are using callbacks like(onComplete) so it feels natural. Again most Angular developers already use callbacks in other parts of their apps. Promises can be confusing for beginners as well. Also, the 4-second timeout is a good safety feature imo

5. What should testing tools for animations do?
Just test animations when needed, tools to check if animations work correctly especially with third party libraries.

Just an idea regarding Q3:

The@ is already well-known for animation, so how about dropping theanimate. prefix and directly using@enter and@leave instead?

Nice to see something like GSAP into this.

it reminders me of something I did back in the day building overlays:

<divclass="canvas_container">@animate(in: {  opacity:0  x:-300px // or any other measure that indicate out of the stage, container, or screen...  delay: 3000 // or some sort of function or promise that observe other elements so animations can be chained or handled manually  transform: {...}}, out:{  opacity:1  x:600px // or any other measure that indicate out of the stage, container, or screen...  delay: 100 // or some sort of function or promise that observe other elements so animations can be chained or handled manually  transform: {...}}, ... other parameters?: {...}) {<component/>}</div>

parameters could be anything like events, callbacks, etc...

notes on in/out: from the perspective of a canvas, elements go in our out. enter or leave are probably synonyms with the same purpose, however a mouse can "enter" or "leave" an element, in our out acts more on the context that elements on the DOM are in the screen as elements of a scene in a canvas.

Question 1: being able to set a css custom variable in angStyle like pattern would be great to reuse css animations with variable parameters. For example creating a from/to animation with variable heights or the current mouse position.

Question 2: being able to set a specific (dynamic) css class on enter of an element would be beneficial to further fine grain an intro animation. Like the direction of which an element should animate from. Another example would be an animation via GSAP that would can use a local signal for its calculation when an element is added.

Question 3: is the naming convention changing overall for bindings in Angular?
Otherwise my first instinct would have been that the naming should be camel case bindings such as[animateIn] (for classes) and(onAnimateIn) (for callbacks)

I really like this proposal. It seems much simpler and more ergonomic compared to the old@angular/animations. I can’t wait to use it in my applications. Thanks for modernizing animations in Angular!

Discussion Question 1: Should these options support setting styles directly like ngStyle bindings? (see [example]

This encourages sloppy code, and is particularly detrimental in large applications with reusable and extendable components, and annoys designers when developers drop inline styles in html.

Discussion Question 2: Is animate.in strictly necessary given the platform supports this behavior already?

For consistency, yes. I shouldn't need to take two separate approaches for each side of the same coin.

Discussion Question 3: What is your preference on the naming? animate.in and animate.out? animate.enter and animate.leave? Something else?

Enter and Leave are consistent with the Angular Animations:enter and:leave aliases which might smooth transition from that package (I know I'm holding off on moving to native CSS animation on out product for now because of the extra work to deal with animating out)

Discussion Question 4: Which of these 2 options for using functions is the most ideal to you, and why?

The callback function looks cleaner and is easier to understand for people who generally like to avoid directly using Promises.

Discussion Question 5: What would you want out of testing tools for animations?

Disabling when running test suite (already mentioned), and that the animation (and the correct animation) is being triggered when expected.

Great work on this proposal! I believe this is exactly what I needed for applying animations in Angular.
Here is my feedback on the questions

Q1: I believe that for consistency, we should avoid supporting direct style setting options like ngStyle bindings here, as ngStyle and ngClass are moving towards deprecation.

Q3: I prefer enter and leave. In and out could be misleading, suggesting easing functions rather than the creation or destruction of a component.

Additional Suggestion:
One thing I'd like to mention is that in most cases, I would probably use a string of CSS classes to trigger the animation. However, when applying a CSS animation this way, the current proposal doesn't seem to offer a clear way to determine when the 'in' animation has completed. It would be great to have an optional parameter for a callback to handle this, similar to the example below:

[animate.in]="{classes:myDynamicCSSClasses,onComplete:()=>{// ... do something after the animation ends}}"

hi,

1. Animation naming-style

both animation namein,out does make sense for naming animation, howeverenter andleave can every body know that about when element or component inserted or removed from DOM,

we can associate or bind a class names or arrays of class names toenter &leave

<component [enter]='class-name-expression'/></component><component leave='[class1, 'class2', 'class3, ... class-n']'/>

2. Animation callback

both enter & leave should be handle animation event like (start, complete, restart if user refresh while prev animation not complete yet)

type AnimationCallbackHandler {     onStart: () => void | {},     onComplete: () => void | {},     onRestart: () => void | {}}

and associate this type withenter andleave

<component (enter.onStart)='callback function when animation start'/'><component (enter.onComplete)='callback function when animateion complete'/'><component (enter.onRestart)='callback function when animation restart''/>

3. Animate Route Navigation

combine this new style of animation with modern navigation styleview-transition

In which version this update will be introduced ?

Discussion Question 1: Should these options support setting styles directly like ngStyle bindings? (see example)

While I'm generally for giving a bit more freedom, it would add unnecessary typing complexity to directives. Unless you want to make something likeanimate.out andanimate.out.style.

Discussion Question 2: Is animate.in strictly necessary given the platform supports this behavior already?

What if I want to use GSAP for in and out - usinganimate.out directive and defining "in" animation in completely different place I would need to look for then? Not saying about tracking whether some condition changes to show the element and then waiting for next render to actually put it into DOM.

Havinganimate.in would not only provide opposite option but also allow to keep things consistent (one place for in and out animations; same way of defining them). As I understand argument with CSS'@starting-style, some people may see it as more consistent and clear to use both directives than defining "in" and "out" in two completely different places. I wouldn't force opinions here

Discussion Question 3: What is your preference on the naming? animate.in and animate.out? animate.enter and animate.leave? Something else?

in andout is shorter and explanatory enough

Discussion Question 4: Which of these 2 options for using functions is the most ideal to you, and why?

I seeevent.animationComplete() as more clear way in case of events

Discussion Question 5: What would you want out of testing tools for animations?

Possibility to disable animations in e2e testing to speed them up - not sure if you covered this in FAQ#5. In general some possibility to switch animations dynamically would be good if possible (eg. user decided to enable reduced motion)

Other than that some benchmarking / performance

Discussion Question 1: Should these options support setting styles directly like ngStyle bindings? (seeexample)

No, but mostly because I don't like ngStyle either and don't think animations should need it.

Discussion Question 2: Is animate.in strictly necessary given the platform supports this behavior already?

Strictly necessary ? No. Sensible? Yes, for the reason you mentioned of having a symmetrical API. If you provide animate.out, given the history of the angular animations package, I expect also to find an animate.in, even if technically it's not that necessary.

Discussion Question 3: What is your preference on the naming? animate.in and animate.out? animate.enter and animate.leave? Something else?

enter and leave, solely for consistent vocabulary with angular animations and because they're solid words for this.

Discussion Question 4: Which of these 2 options for using functions is the most ideal to you, and why? Do you have an alternative suggestion?

No preference

Discussion Question 5: What would you want out of testing tools for animations?

At my workplace we mostly want to be able to test "Is this specific animation running?". I think for that purpose it would already suffice if I could check if the CSS class associated with the animation is currently being applied or not.

The rest would just be able to usetick to skip to the end timepoint of an animation which should then trigger corresponding aniimationEnd events (whose effects would then be tested for).

Did you consider the implication this will have on routing transitions?
Maybe the adding of the event binding feature could be coupled with some modification to current Router, so the animation.out could be bound to something like a routeLeaving Event?

I wish Angular supported global animations for@if(cond) {} blocks, with the ability to override them like@if(userData, custom_animation_name) {}. This would be especially helpful when dealing with async data fetched from the backend, so that some animation plays when the data is retrieved.

Will it also work seamlessly with the@defer when actually deferred loading should fire first then animation? They will definitely elevate the visual experience along with some neat lazy loading.

My comments will be from the perspective of library maintainer. So this is written under assumption that component code isnt directly available to the consumer.

Discussion Question 1: Should these options support setting styles directly like ngStyle bindings?

Yes! This would allow to make a simple Input to pass in animation styles. Supporting only class based animation will require to break encapsulation with ng-deep or global styles which is dangerous and risks leaks. Style object can be declared as const and reused safely.

Discussion Question 2: Is animate.in strictly necessary given the platform supports this behavior already?

Yes! This is very important for dynamically configured animations. as well for consistency. I would hate to have half of my code use new API forout and rest is some mix of different approaches. Also for some complex library animation configs its important to have extra control via callbacks.

For example: I would trigger parallel animations in some components/directives which would in turn trigger stagger animations inside to create layout with multiple columns where each column staggers its elements in parallel. The animation itself is configured via DI and can be overridden per element. Elements also remember their animation in case they were toggled via@if. I would needin out callback functionality to make something like this without@angular/animations

We should also add support for animate.in and animate.out in hostbindigs and@HostBinding() to make it possible to encapsulate reusable animation logic in directives.

Discussion Question 3: What is your preference on the naming? animate.in and animate.out? animate.enter and animate.leave? Something else?

in-out is more concise. It is clear its a new API not like enter leave of the old animations.

Discussion Question 4: Which of these 2 options for using functions is the most ideal to you, and why? Do you have an alternative suggestion?

Option 1: Callback function. If i were a junior developer I would not want to think what it this all extra syntax is for or have some funny async await ideas. I dont see any need to make it a promise becauseanimateFn wont be awaited. it relies on callback in both cases(resolve()) just with extra syntax on second case.

Q1: Yes
Q2: No
Q3: animate.out
Q4: callback

Questions

Q1:No, makes it to complicated IMHO
Q2: Technically No, but I also sucker for symmetry soYes
Q3:enter/ leave but in/ out is as fine for me
Q4:option 1 - the callback option
Q5: as just mentioned, to be able to skip them for unit tests AND something that any js framework can provide (I assume) to manipulate time, by ticking forward or backward, but in a real browser (for visual regression tests)

Template Syntax

I'd like to provide some feedback and a potential alternative for the proposed template syntax, regarding the use of directive-like bindings ([] and()).

First, I'm curious if there's a public design doc outlining the decisions, including the pros and cons, behind the current syntax choices. Understanding your thoughts here would be very helpful IMHO.

My primary motivation for asking is that I agree with the decision that this new functionality shouldnot be a directive. Based on that, I'd like to propose a different syntax that clearly shows a compile-time transformation rather than mimicking a directive.

I suggest we re-use the@ symbol, which has already been introduced for flow control anddefer, to serve as the official indicator for compiler-based code sections. This would provide a consistent visual cue for developers.

Here are a few examples of how this could look:

HTML

<example-cmp @animate.out="'fancy-animation-class'" /><example-cmp @animate.out="myDynamicCSSClasses" /><other-example-cmp @animate.out="animateFn($event)" />

Alternatively, to differentiate between static and dynamic values while maintaining the@prefix:

HTML

<example-cmp @animate.out="fancy-animation-class" /><example-cmp @[animate.out]="myDynamicCSSClasses" /><other-example-cmp @(animate.out)="animateFn($event)" />

I believe this approach would visually enhance the code and leverage an already established symbol within the framework.
Looking forward to your thoughts on this alternative syntax.

Does the framework actually need an 'animations' feature?

First let me start by saying that I have not been privy to the many dicussions that have occured amoungst the team about this feature and while I am certain that they were quite thorough in investigating all possiblities, something keeps nagging me - is this the right solution to the stated problem? It seems to me that the problem that is trying to be solved is that the framework needs to know when it is safe to remove an element from the DOM if there is an 'exit' animation applied to it. Also, it is stated and keeps getting repeated that theanimate.in is not necessary because it can be handled with native CSS. Why add something that is not necessary.

Isn't this a life-cycle issue? Shouldn't it perhaps be part of the life-cycle of destroying a component. You mentioned theevent.waitUntil method onExtendableEvent. Wouldn't a similar API on DestroyRef maybe (just a guess, I am not sure of the actual framework process of removing a component) be the solution. We could then use the native browser eventsanimationEnd andtransisitonEnd in some way to delay the removal of the component.

Just my CDN$0.02

Instead ofanimate.out, can we think aboutonDestroy?

Example:

<other-example-cmp(onDestroy)="destroyFn($event)"/>

And extend the event like below:

event.cleanUpComplete()

Or

event.waitUntil(cleanUpPromise)