Entry and Exit Animations

[josepharhar]

こんにちは TAG-さん!

I'm requesting a TAG review of Entry and Exit Animations.
I am using one TAG issue for these features because they are used together to accomplish an important use case.

Entry and Exit Animations is a set of CSS features which makes it possible to animate elements to and from display:none, and to animate elements entering and leaving the top layer, like <dialog> and elements with the popover attribute.

The CSS features include:

1. CSS transitions for discrete properties, which allows the transition property to animate discrete properties like display.
   (formerly Transitions on specified discrete properties #825)
   CSSWG issue: [css-transitions-2] Start transitions on discrete animation types w3c/csswg-drafts#4441
2. CSS transitions and animations for the display property
   (formerly Display and content-visibility animations #824)
   CSSWG issue: [css-display] Why is display listed as not animatable instead of animation type: discrete? w3c/csswg-drafts#6429
3. CSS @initial rule, which allows animations to start from display:none.
   CSSWG issue: [selectors-4] Add syntax to establish before-change style for css-transitions on new elements. w3c/csswg-drafts#8174
4. CSS overlay property, which allows animations on elements entering or leaving the top layer.
   CSSWG issue: [css-animations-2, css-transitions-2] Entry and exit animations for top-layer elements w3c/csswg-drafts#8189

• Explainer¹ (minimally containing user needs and example code): https://github.com/chrishtr/rendering/blob/master/entry-exit-animations.md
• Specification URL:
  • CSS transitions for discrete properties:
    • [css-transitions-1] Make discrete properties transition at 50%; exclude them from 'all'. #4441 w3c/csswg-drafts#8520
    • https://drafts.csswg.org/css-transitions-2/#transition-name-property
  • CSS transitions and animations for the display property: https://drafts.csswg.org/css-display-4/#display-animation
  • CSS @initial rule: Not specced yet
  • CSS overlay property: Not specced yet
• Tests: [wpt folder(s), if available]
  • https://wpt.fyi/results/css/css-display/animations/display-interpolation.tentative.html
  • https://wpt.fyi/results/web-animations/animation-model/animation-types/display.tentative.html
  • https://wpt.fyi/results/css/css-transitions/all-with-discrete.tentative.html
  • CSSTransitionDiscrete: Fix overflow related crashes web-platform-tests/wpt#38860
  • CSSTransitionDiscrete: Fix align related crashes web-platform-tests/wpt#38815
  • CSSTransitionDiscrete: Fix counter related crashes web-platform-tests/wpt#38817
  • CSSTransitionDiscrete: Fix background-repeat related crashes web-platform-tests/wpt#38816
  • CSSTransitionDiscrete: Fix text-decor related crashes web-platform-tests/wpt#38997
• User research: none
• Security and Privacy self-review²: none, I believe this animations feature has no security/privacy implications.
• GitHub repo (if you prefer feedback filed there): none
• Primary contacts (and their relationship to the specification):
  • Joey Arhar @josepharhar Google
  • Robert Flack @flackr Google
  • Chris Harrelson @chrishtr Google
• Organization(s)/project(s) driving the specification: Google
• Key pieces of existing multi-stakeholder review or discussion of this specification: See above CSSWG issues
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status):
  • https://chromestatus.com/feature/5154958272364544
  • https://chromestatus.com/feature/5071230636392448
  • https://chromestatus.com/feature/5138724910792704
  • https://chromestatus.com/feature/4515377717968896

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: We are trying to ship this in Chrome 114 which branches on April 20th and goes to stable on May 30th
• The group where the work on this specification is currently being done: CSSWG
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): CSSWG
• Major unresolved issues with or opposition to this specification: none
• This work is being funded by: Google

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue and @-notify [github usernames]

[LeaVerou]

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.

[josepharhar]

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

Here is a spec PR which should make a clear definition: w3c/csswg-drafts#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 w3c/csswg-drafts#6429

[lilles]

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

[nt1m]

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.

[flackr]

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.

[nt1m]

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.

[LeaVerou]

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?

[nt1m]

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).

[LeaVerou]

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?

[nt1m]

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

[LeaVerou]

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

Not sure I follow, could you please elaborate?

[nt1m]

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.

[josepharhar]

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:
web-platform-tests/interop#580
web-platform-tests/interop#581

[torgo]

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!