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

The trouble is you generally don't get as many values as you specify with the start/end nomenclature. `steps(3, end)` gives you four values, and so does `steps(3, start)` (either in-effect or based on the _before flag_ behavior).

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

The most common case where you _don't_ see all four values is when you have a repeating animation and are watching one of the intermediate iterations. Maybe someone could argue that `frames()` is especially useful for repeating animations, but I don't think that's the case. It's quite useful for single iteration animations too, and, conversely, start/end is very useful for repeating animations whenever the endpoint and startpoint of the animation overlap since with `frames()` you'd end up with one frame showing for twice the time. That is, these feel like the same sort of thing to me so having a completely different name and way of counting seems unfortunate.

I guess it comes down to whether you want to count the number of values or jumps. If we were starting from scratch I think we agree we'd probably want to count the number of values, but since we've got `steps()` which counts the number of jumps (i.e. `values - 1`) I think we should stick with it. [I introduced `frames()`](http://slides.com/birtles/browser-animation-2017#/3/1) at a developer meetup here in Tokyo after the last CSS F2F and it certainly felt awkward explaining why I had to change the code from `steps(10, start)` to `frames(11)` despite the visual result being so similar.

Dropping both end points has so far only come up in the context of gradients. It could definitely be deferred but I think it's relevant when considering how to name this class of things. I'd rather not introduce yet another function for that too.

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

Received on Friday, 23 June 2017 07:51:34 UTC