[csswg-drafts] [css-animations-2] Proposal: Time-based Keyframe Animations (#4907)

shshaw has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-animations-2] Proposal: Time-based Keyframe Animations ==
`@keyframes` are a great way to define animations, but the percentage-based declaration can be difficult to adapt to. Users familiar with GUI based animation programs or recreating existing animations in CSS can struggle with the conversion from absolute _time_ to a _percent_.

Since we already have a `<time>` data type in CSS, could `@keyframes` be extended to support time based waypoints? This fits well within a standard animation timeline mental model which should make it easier for people to compose animations.

```
.box {
  animation: time-based-keyframes;
}
@keyframes time-based-keyframes {
  /* 0s 'frame' would be optional, same as `from` */
  0s { transform: rotate(0deg); }
  1s { transform: rotate(45deg); }
  2s { transform: rotate(45deg) translateY(100px); }
  /* Longest time duration = last 'frame', add pauses/delays with ranges */
  3s, 4s { transform: rotate(45deg) translateY(100px); }
}
```

This may not fit within the existing `@keyframes` model, but that would be preferable versus have a different model that could cause conflicts in the namespace.

# Duration 

`animation-duration: auto` would use the longest time declaration in the `@keyframes`. This could become the default value of `animation-duration` and would evaluate to `0s` for standard percentage based `@keyframes`.

## Scaling

The keyframe duration could be overridden by setting an exact duration, `animation-duration: 2s`, which would speed up or slow down the time-based `@keyframes` to match that duration. Much like in a video editor where you have a clip that's 10 seconds long, but you can speed it up so the duration of that video is only 6s or stretched out to 20 seconds. Doesn't change the original clip's 'length', but does change how the clip plays in the timeline.

Additionally, percent values in `animation-duration` could allow relative scaling of the keyframe defined duration.

```
/* Animation `@keyframes fade-out { 1s { opacity: 0 } }`*/
animation-duration: 200%; /* = 2s */
animation-duration: 50%; /* = 0.5s */
```

Having a standalone property for this like `animation-timescale` or `animation-playback-rate` would be useful, though expanding `animation-duration` for this "scaling" seems preferable.

# Self-Contained Animations

Having time-based keyframes would make self-contained (“composed”) animations much easier. If the default duration becomes `auto`, then adding a composed animation to an element could be as simple as `animation: my-keyframes` where the duration, timing-functions and animated properties could all be declared within the keyframes.

```
.box { animation: scale-up; }

@keyframes scale-up {
  0s { animation-timing-function: cubic-bezier(0.5, 0, 0.5, 1); }
  1s { transform: scale(2); }
}
```

This containment would make animation design systems, exporting from GUIs, and CSS animation libraries easier to implement across a codebase.

# WAAPI

Though outside of the CSSWG, it's worth considering how this could also improve WAAPI animations:

```
document.querySelector(".box").animate([
    { offset: "0s", opacity: 1 },
    { offset: "1s", opacity: 0 }
  ]); /* No duration needed */
```

# "Polyfills"

Processors like Sass and PostCSS could implement this functionality by converting times to percentages given a duration ( @mirisuzanne was kind enough to create a Sass based mockup!  
https://codepen.io/mirisuzanne/pen/jOPQdWw ) but native support would make CSS animation a lot more accessible to folks. 

There are certainly opportunities to expand on this (relative times, delays, etc.), however the current scope seems like a realistic and reasonable addition to CSS animation syntax.

CSS Animation 2 Spec for reference: https://drafts.csswg.org/css-animations-2

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4907 using your GitHub account

Received on Friday, 27 March 2020 18:59:50 UTC