Hi @josepharhar,

@ylafon and I spent quite some time during our Tokyo F2F looking at the various issues, and the explainer.

Overall we like the direction that this is going. Designing a solution to this problem as small independently useful improvements on existing features that can together be leveraged to solve the problem is a good practice.

We also like that existing transition syntax could be leveraged to do the right thing, rather than introducing new syntax.

We see discussion went from :initial to @initial due to specificity issues (?), but we could not find a definition of what @initial is/does. We are also concerned that the name will be confusing for authors, as initial is an existing, unrelated concept in CSS (initial values).

Making transitions to display: none inert seems preferable, though it is unfortunate the inert property was resolved against, and thus authors can not opt out or use this behavior for other use cases.

For some of these issues (e.g. 6429) there seemed to be still active discussion after any resolutions, making us wonder if shipping this might be a little premature.

we could not find a definition of what @initial is/does

Here is a spec PR which should make a clear definition: https://github.com/w3c/csswg-drafts/pull/8876

We are also concerned that the name will be confusing for authors, as initial is an existing, unrelated concept in CSS (initial values).

It was changed to @starting-style based on additional discussion

For some of these issues (e.g. 6429) there seemed to be still active discussion after any resolutions, making us wonder if shipping this might be a little premature.

We just resolved on additional behavior details on https://github.com/w3c/csswg-drafts/issues/6429

The PR for @starting-style is now in css-transitions-2:

https://drafts.csswg.org/css-transitions-2/#defining-before-change-style-the-starting-style-rule

I think one question I'd be interested in seeing answered regarding this new feature is why:

dialog {
  @starting-style {
     opacity: 0;
  }
  transition: opacity 0.4s;
}

is preferable over:

@keyframes fade-in {
  0% { opacity: 0 }
}
dialog {
  animation: fade-in 0.4s;
}

They both work and achieve the same use case, and the new syntax isn't that much shorter.

For the simple use case they indeed both work, however developers often prefer transitions for their ergonomic simplicity in dealing with arbitrary subsequent changes. For example, with the fade animation:

@keyframes fade-in {
  0% { opacity: 0 }
}
dialog {
  animation: fade-in 0.4s;
}

1. Any subsequent changes to the opacity while it is animating in take effect immediately, even if transition: opacity 0.4s; is set.
2. If you hide the dialog while it is still progressing through the showing animation, a transition will implicitly reverse from the point it is currently at - and at the appropriate speed per css-transitions-3.1

These behaviors are often desirable and much harder to get right with animations. For example, I put together a demo showing the difference between naively using animations vs transitions for entry and/or exit: https://jsbin.com/coxewex/edit?html,css,output Note: Move the mouse out before the animation finishes to see the significant differences.

You can see with an animation in and transition out the transition is completely skipped if the animation hasn't finished yet, and if you use an animation in both direction then it's not easy to prevent it from playing from the shown state.

This makes sense, thanks. I guess the other question I have now that we're talking about @keyframes is how both features interact together. What happens if someone uses animations and @starting-style on the same element? or if they set animations in @starting-style.

This makes sense, thanks. I guess the other question I have now that we're talking about @Keyframes is how both features interact together. What happens if someone uses animations and @starting-style on the same element? or if they set animations in @starting-style.

The same as any other time that transitions and animations are running at the same time?

Ah right, need for think more before I write 😅. The reason this popped in my mind was that I could see sites using both @starting-style and @keyframes on the same element (not necessarily as intended).

Hi there, quick question as we do some end-of-year housekeeping. We notice the title of this issue is "Entry and Exit Animations", but right now CSS only includes entry animations, and exit animations have been contentious. Is this meant as a design review for both, or just about @starting-style?

I think the exit bits are somewhat covered by the discrete transition stuff.

I think the exit bits are somewhat covered by the discrete transition stuff.

Not sure I follow, could you please elaborate?

This was about being able to do exit animations for display: none for most part (so from display: block to display: none), since it's the most common case for popovers. AFAIK, transition: display 1s allow-discrete, opacity 0.1s covers this case. I don't think exit animations for element removal was ever a goal of this specific issue.

Exit animations can be done with transition-behavior:allow-discrete as Tim said. Here is a minimal example: https://jsfiddle.net/jarhar/cyugx34v/4/ The overlay property also allows these elements to stay in the top layer during their exit animation.

These have both been specced, have tests, and have been shipped in chrome: https://github.com/web-platform-tests/interop/issues/580 https://github.com/web-platform-tests/interop/issues/581

As discussed in TAG calls this week: We see that the browsers have agreed to focus on implementing these features as part of Interop 2024. While some of the details may still not be optimal, we don't think there are any architectural concerns, and we think the CSSWG is the right place to continue refining the design, if necessary. Thank you for bringing us this review!