[css-timing] reconsider name of frames() timing function

[dbaron]

From w3ctag/design-reviews#161 (comment), it would be good to reconsider the name of the frames() timing function.

[shans]

Firefox and Chrome have already shipped the frame() timing function. I'm sympathetic to the reasons for the change of name but I'm not keen on both those browsers having to maintain legacy aliasing support.

[birtles]

Yeah, we've also implemented it in Servo too. But to be fair, it hasn't reached release yet so we could change it without having to alias it, I think. I'll ask people on the animation slack to contribute here if they have any useful suggestions for names.

[Martin-Pitt]

Hi from the slack.

When I came up with the name frames(), one of the major use cases for this timing function was spritesheet animations, which were hacky or required modifying the spritesheet or animation in a specific way (I think Rachel Nabors was having tricky time trying to use the steps function for this).

Root issue with the steps function is that when animating, the first & last step only appear in half the duration that the steps in the middle have, creating an inconsistent animation. This is especially noticeable with looping when passing the short last step and the short first step in succession.

If I remember correctly, older suggestions we had at the time were: equal, distributed, divided and various other synonyms. Also variations with step(s) as suffix or prefix as an alternate form.

shshaw from slack suggested equal-step

[rachelnabors]

None of these other names make much sense to the everyday frontend dev or designer. ('Steps' barely makes sense since people aren't graphing the timing function visually and will most likely never see it graphed!).

Frames made the most sense to me for my sprite animation use case, but let's consider an equally likely background color animation. Perhaps "jumps" or event "cuts" would make more sense. Let me ask the Twitters for inspiration.

[AmeliaBR]

Rachel's tweet, if anyone wants to re-tweet for wider reach:

CSS animations folks, if we could call steps() something else, what would you suggest?

She carefully didn't use the word frames in her question. Yet 3 of 4 replies right now are recommending it.

[birtles]

I'm quite happy with frames() but if others aren't and we assume steps() is here to stay (and there are use cases for it) one other alternative might be steps-even to indicate that the step values are evenly distributed between the start and end?

e.g. steps-even(5) or perhaps steps(5, even) (with the caveat that steps(1, end) is valid but steps(1, even) is not). frames() and steps() are only subtly different so having a similar name makes sense to me since when you discover that steps() doesn't quite do what you want you'll naturally grab the next thing that sounds similar.

[rachelnabors]

I like adding onto the steps() syntax, personally. Use what is already there.

(Although, steps() is still a horrible name for the timing function! Explaining it to students always elicits confusion. jumps() may have made more sense, but alas. The dye is cast!)

In that light, "even" might not make sense to folks who may not even fully understand start and end.

[AmeliaBR]

What about steps(2, equal) ? I think "two equal steps" is a fairly easy-to-understand description of what this timing function achieves. It doesn't help clarify how its different from steps(2, start), though. Maybe steps(2, full) ?

But, my vote is still on keeping frames(), especially since it has already shipped! That helps avoid confusion between the different ways of counting: steps() counts the number of times the value changes, frames() counts the number of different values.

The terminology could be reinforced with a new figure in the spec, showing the keyframes, the frames, and the steps as different parts of the timing function graph.

[tabatkins]

We had the "should we just reuse steps()?" discussion earlier, and decided not to do so, for precisely the reason Amelia gives - the two versions interpret the numeric argument substantially differently. Using a brand new name reduces the confusion factor.

I'd like to stick with frames() here, as it invokes all the right intuitions - if you're animating a sprite sheet, it literally means frames, and even in the general animation case, instead of a smooth animation it's divided into N static frames.

While there is a little bit of semantic overlaap with rAF(), I don't think the two are close enough to be worried about.

[birtles]

The other new piece of information that has just come up is people wanting to re-use timing functions for gradient easing. In that case frames() seems less suitable? Should we care?

[tabatkins]

It seems okay to me?

Like, I agree that steps() would have been better for this in the first place, but we done goofed that one up real bad.

[birtles]

Not sure if I follow, but we still need the steps() behavior too. For example, when you rotate an object 1 turn infinitely and you want to stagger the progress (e.g. a segmented spinner), you don't want frames() because you'll end up spending one portion of time at 0 degrees, and another portion of time at 360 degrees so you'll spending twice as long at that one position.

[rachelnabors]

This is true!