Re: [csswg-drafts] [css-timing] reconsider name of frames() timing function

> In the typical case where you have a transition (which effectively fills forwards and backwards) or any animation that does not repeat (in which case you normally want to fill, or effectively fill by relying on the non-animated value either side of the animation interval) then when you watch the animation, for each of the examples in the diagram above you see four values (i.e. three jumps).

You're getting lost in the simple mathematics of the system, and are forgetting the bad usability that originally prompted Rachel's request for `frames()`. There are at least two easy cases where steps() is very bad:

1. A one-shot animation not intended to fill.
2. A repeating animation that doesn't end where it started.

In both of these, you need to use N+1 steps when you intend to only show N "frames", and overshoot your goal value by 1/(N+1).  (With `frames(N)` you get the right behavior automatically.)

Another bad situation is when you're transitioning, and you want the transition to start immediately, show N intermediate steps, and end T seconds later.  To do this with `steps()`, you need to use `start`, and increase the duration by 1/(N+1).  (This wants the "exclude both start and end" thing - it's more than just gradients!)

All of these scenarios count as being "possible", but they're terrible in practice.

`steps()` is well-optimized for repeating animations where you want to end back where you started. (This makes sense, as the *entire design* of CSS animations is heavily optimized toward infinitely-looping animations.)  Then `start` vs `end` is just a matter of whether the animation begins with its starting value or the first "step". In a lot of other cases, `steps()` is very bad, *because* it focuses on jumps rather than values, which makes it match up badly with the mental models people are trying to express.

> Thanks for following up on this. I'm afraid that drop-* sounds like one or more of the endpoints are dropped, but they're not--it just appears that way when you use a fill mode of none.

Other names that better communicate "don't use the start/end value in the animation" are welcome, of course. ^_^  Or, ultimately, we can leave `steps()` to doing the "unbalanced" thing, and keep `frames()` focused on just the one scenario.  (Possibly, if we figure out a good word, letting it do the "just interior frames" thing too.)

> Maybe we should just let n continue to be the number of steps (i.e. changes in value) and add the distribute and justify keywords to describe how the steps are aligned within the interval (much like start and end do).

I am *so extremely* against this. It's the ultimate in prioritizing the math over the UX, which is the entire problem here. For all that `steps(N)` is bad, at least we have the nice, intuitive property that it divides the animation into N intervals.  (The intervals just don't have the values we want in many cases. ^_^) Having a keyword make it N-1 or N+1 intervals would be extremely confusing I think.

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1301#issuecomment-310754815 using your GitHub account

Received on Friday, 23 June 2017 19:36:07 UTC