Appropriate animations are a great way to help users build an accurate mental model of how a web page UI works and therefore increase usability of a web site, and are important for a UI to feel polished and fluid to users. A common example is elements being visible or modal on the page only when they are “open”. Entry and exit animations for such elements are types of animations where an element enters or exits (respectively) the visible screen, or substantially changes their rendering in some other way; examples include dismissible dialogs, popovers, or similar UI patterns that do not use those built-in elements.
There are currently several gaps in declarative web platform APIs for the entry and exit animations in particular:
-
Animations or transitions involving the display CSS property do not work.
-
Some use cases work with CSS animations but not CSS transitions.
-
Animations and transitions are impossible to coordinate with entry or exit from the top layer.
We propose to close those gaps.
-
Support CSS transitions for discrete properties, and for discrete states of continuous properties (e.g. the
auto
value ofwidth
). Currently they can be CSS animated but not CSS transitioned. It’s tracked in this CSSWG issue for standardization and this chromestatus entry. This is a prerequisite for 2 and 4 below. -
Support animating and transitioning the display css property. Currently it is impossible to use display in an animation or transition. It’s tracked in this CSSWG issue for standardization and this chromestatus entry.
-
Support for CSS transitions on entry animations from a display:none state by adding the
@initial
syntax. (Currently this use case is only possible via CSS animations.) It’s tracked in this CSSWG issue for standardization. -
Support for specifying a CSS transition delay on entry to or exit from the top layer via an
overlay
CSS property (that is in effect restricted to CSS transitions). It’s tracked in this CSSWG issue for standardization and this chromestatus entry. -
Ensuring exit animations are inert to user input, to avoid accidental clicks against content that no longer conceptually visible, by making animations to
display:none
automatically inert. It's tracked in this CSSWG issue for standardization.
With these five changes, web developers will be able to use CSS transitions and CSS animations for discrete-animatable properties, the display CSS property, and a CSS transition (but not CSS animations; see Alternatives Considered for why) for the top layer.
Instructions for a complete working example of an exit animation for a <dialog>
element is here.
Inline:
<dialog id=dialog>
Content here
<button onclick="dialog.close()">close</button>
</dialog>
<button onclick="dialog.showModal()">Show Modal</button>
<div id="high">
</div>
<style>
dialog {
transition: overlay 5s, opacity 5s, display 5s step-end; /* New! */
/* duplicate UA styles during the animation */
position: fixed;
inset-block-start: 0px;
inset-block-end: 0px;
max-width: calc((100% - 6px) - 2em);
max-height: calc((100% - 6px) - 2em);
user-select: text;
visibility: visible;
overlay: browser !important;
overflow: auto;
}
dialog:not(:modal) {
opacity: 0;
}
#high {
z-index: 999999999;
background: green;
position: fixed;
height: 100%;
width: 100%;
}
</style>
And a demo of an entry animation for an element with popover
that uses CSS transitions is here.
Inline:
<button popovertoggletarget=f popovertarget=f>Toggle the popover</button>
<div popover=auto id=f>I'm a Popover! I should animate.</div>
<style>
[popover],
[popover]:initial {
opacity: 0;
transition: display 0.5s, overlay 0.5s, opacity 0.5;
}
[popover]:open {
opacity: 1;
}
[popover] {
top: 100px;
left:100px;
right:auto;
bottom:auto;
}
</style>
In the use case addressed by solution 3 above, it’s already possible to use CSS animations instead of CSS transitions, so in that sense this solution is not strictly required. However, this alternative is more verbose and confusing to developers already used to CSS transitions.
For solution 4, an alternative could be for the user agent to automatically detect animations when entering or exiting the top layer. This was prototyped in Chromium and discussed in detail here (see comments towards the end). The proposal in this document is more explicit and simple than the alternative described there. Another alternative could be to directly expose the overlay
CSS property in all cases, but that would result in circularity and loss of UA-guaranteed accessibility for existing top-layer elements (which are: fullscreen, dialog and popover, all of which are UA controlled to ensure accessibility).
Similarly, the overlay
CSS property could be exposed to CSS animations in addition to CSS transitions. On top of introducing the problems of directly exposing an top-layer CSS property, this would also: allow unbounded-in-time animations (and therefore lead to top layer elements failing to ever open or close); and lead to other implementation complications in the implementation of the CSS cascade.