[css-animations-2] frames() as a more intuitive steps()

[tabatkins]

As was discussed in the past, and most recently championed by Rachel Nabors, steps() is defined in a nonintuitive way. Depending on whether you use "start" or "end", you never actually see the starting/ending value. If you do want to see both the starting and ending values, and have a stepped transition between them, you need to do some math and overshoot the desired end-point instead. This is extremely common; for example, the default "discrete" method that we use for things without a better interpolation method is exactly this! This also shows the weakness of the hack - for non-interpolable values, you can't "overshoot" either.

It was suggested that we add a new function that handles things more intuitively, so that saying you want "2 steps" creates a timing function that spends half the time on the starting value and half on the ending value, "3 steps" spend a third of time at the start, a third in the middle, and a third at the end, etc.

The name frames() was suggested for this and proved popular in Rachel's group of authors, by analogy with animation frames. It takes a single <integer> which must be >= 2.

[birtles]

I'm planning to spec this in Web Animations: https://w3c.github.io/web-animations/#issue-fc1dd2fc

[katzlbt]

If you do want to see both the starting and ending values, and have a stepped transition between them, you need to do some math and overshoot the desired end-point instead.

I do not agree with this. In the case of animating a sprite-sheet with finite iterations (background-position) it is impossible to overshoot due to the limitations of the underlying background-image. I think that possible parametrizations to animate all frames correctly with fill-mode forwards only exist for 1 and infinite iterations. Run the example here: http://stackoverflow.com/questions/38809527/css-spritesheet-animation-fill-mode-forwards-with-steps-ends-on-wrong-position

Should this be a separate issue?
I think this is not an issue of intuitiveness. It appears to be uncharted territory in the specs, if not a specs-bug.
Is there a link to a draft for the proposed frames() timing-function?

[tabatkins]

Resolved now (we're using steps(), but adding a keyword with the behavior described here). Closing in favor of #1680 to track remaining naming issue.