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.

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.

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

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.

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.

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.

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.

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.

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.

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?

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.

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.

The CSS Working Group just discussed reconsider name of frames() timing function.

I don't strongly object to frames(), but it seems like a variant of steps(), so maybe it should steps(n, <something>). Maybe <something> is a word that implies "inclusive"?

@smfr See the above comments (#1301 (comment) in particular) for why re-using steps() is discouraged.

Given issue #1371, I'm now more inclined towards extending steps(). I know we've had that conversation before, but since then two things have changed:

• There is interest in re-using this for gradient stops where frames() seems like a less suitable name
• There is interest in a fourth variation on this theme where neither of the endpoints are included

In a sense, frames() ensures both endpoints get their fair portion of showtime, while issue #1371 seeks the opposite effect: neither endpoint gets a showing.

These are really all variations on a theme so I feel like a common function name (or at least similar function names) makes sense.

Unfortunately steps(n, start) means that the start value does not get a showing, otherwise I'd suggest the four keywords are: start, end, both, and none and they represent which endpoints are included (and we just accept the fact that the n is interpreted differently for 'both' and 'none').

If we accept that the keyword represents where the vertical steps lie, then perhaps the keywords could be: start, end, inside, outside?

Adding agenda+ since we need to resolve this issue soon. This feature has reached Firefox beta and will ship on the release channel in early August. I expect Chrome is not far behind. Beyond that point it will be much harder to change this naming.

To summarize the issue:

• We initially decided to use frames() since:
  • It has slightly different behavior to steps(), namely values of n less than 2 are invalid.
  • There was strong community support for this name (the proposal itself came from Martin Pitt via the Animation at Work slack). That this naming makes sense to many people has been been subsequently confirmed by Rachel's informal twitter poll.
• Since then the TAG raised concern about semantic overlap with animation frames (requestAnimationFrame) and keyframes (@keyframes etc.).
• Subsequent to that interest has been expressed in using timing functions for gradients where frames() is a less suitable name ([css-images] Add easing functions to color stops #1332).
• Furthermore, there appears to be interest in coining a fourth variation on step timing functions where neither of the endpoints are included ([css-timing] Extending frames() or steps() or adding a third option #1371).

Since I will not be able to attend telcon this week (I can only attend the APAC-friendly telcons), I'll leave my take on the issue here:

• Given the last two points in particular, I think we should rename this by simply extending steps() somehow.
  • Having frames() and possibly yet another timing function which are only subtly different to steps() but have completely different names feels like a unnecessary platform wart that will make learning this syntax harder for authors (when you realize that steps(2, start) doesn't do what you want, it's much more natural to reach for something that looks similar) and that we will regret later.
  • Sticking frames() in a gradient also seems odd.
• Strawman 1:
  • Recognize that the existing start and end refer to where the step happens and not which endpoints are included. So in keeping with that precedent:
  • steps(n, start) — n ≥ 1
  • steps(n, end) — n ≥ 1
  • steps(n, inside) — n ≥ 2 (= frames(n), i.e. the steps are inside the interval)
    • See next comment where Amelia suggests inclusive for this.
  • steps(n, outside) — n ≥ 1 (neither endpoint is included)
    • Alternatively exclusive (see next comment).
• Strawman 2:
  • Forget trying to be consistent with start and end and try something that might be less mathematically consistent but is more intuitive.
  • steps(n, start) — n ≥ 1
  • steps(n, end) — n ≥ 1
  • steps(n, distribute) — n ≥ 2 (= frames(n), i.e. "distribute the steps evenly within the interval")
    • Alternatively, space (space apart)? equal (equally distributed)?
  • steps(n, clip) — n ≥ 1 (neither endpoint is included, i.e. clip off the endpoints)
    • Alternatively, trim (trim the gap between the steps and interval ends)? align (align steps with ends of interval)
• Strawman 3:
  • As with the previous two examples but using a separate function name. Using a separate function name might be appropriate since the range of n is different for the frames() case but I'd still prefer a name that is obviously related to steps(). Also there is a subtle difference in how frames() works at the at boundaries that might suggest a separate function name.
  • 3a. steps-inside(n) with n ≥ 2, steps-outside(n) with n ≥ 1
  • 3b. steps-inclusive(n) with n ≥ 2, steps-exclusive(n) with n ≥ 1
  • 3c. steps-distribute(n) with n ≥ 2, steps-clip(n) with n ≥ 1
  • etc.

Maybe inclusive and exclusive instead of inside and outside? They are more academic terms, but are how you would actually describe a range that may or may not include the endpoints.

E.g., for a transition from 0 to 10, steps(5, inclusive) divides the transition into five equal-sized steps between 0 and 10, inclusive. While steps(5, exclusive) divides the transition into five equal-sized steps, exclusive of the initial and final values.

It doesn't help solve the naming confusion with start and end & people thinking that means "including the start/end value" instead of "making the switch at the start/end of the time interval". But I don't think it makes it much worse, either.

PS,
Whatever you call it, the outside/exclusive/clip option should only be restricted to n ≥ 1. I would expect that steps(1, exclusive) for a transition from 0 to 10 would mean that the value would be 5 for the length of the transition.

PS,
Whatever you call it, the outside/exclusive/clip option should only be restricted to n ≥ 1. I would expect that steps(1, exclusive) for a transition from 0 to 10 would mean that the value would be 5 for the length of the transition.

Oh, good point. I'll update my previous message to reflect that.

I'm theoretically okay with changing the name away from frames(), to make something that works better with #1371, but I'm still strongly against reusing steps(). The behavior is substantially different, and if you try align your mental model of the behaviors, then the interpretation of the numbers and keywords vary in confusing ways. (The aforementioned confusion with "start" not meaning "include the start value".)

I feel like the most intuitive model, for me, is something that creates N steps, and has a keyword that controls each combination of whether the start/end values are included. Keeping the "frames" name for a moment just for the sake of argument, I'm thinking of something like:

frames( <integer>, [ drop-start | drop-end | drop-both ]? )

(Alternately, [ drop-start || drop-end ]?)

We might be able to merge this into steps(), if we (a) come up with a good keyword for "keep both", and (b) are okay with steps(n) continuing to mean drop-end for legacy reasons. Using a new function lets us start with "keep both" as the default, so we don't need to come up with a new keyword. I don't have a good name for this tho; I'm still generally okay with frames() for gradients too. ^_^

I'm strongly opposed to trying to "harmonize" this with the content-distribution keywords. It's extremely non-intuitive in practice, imo, particularly since it means you're distributing the jumps, not the values; the entire point of frames() is that it's more intuitive in some cases to think of the values. (And steps() can be interpreted as N specifying the number of jumps or values, both in its name and its operation)

Basically I don't think talking about jumps is ever the intuitive thing to do. At least in my mind, it's never what I'm considering when dealing with transitions, except possibly in the simplest cases (like, I might think "I want this to transition in one jump", and then decide whether I want the jump to happen at the start, middle, or end; but as soon as I'm talking about more than that, I want to think in terms of how many values I see in the animation).

It's extremely non-intuitive in practice, imo, particularly since it means you're distributing the jumps, not the values

That sounds like renaming it to values() would help. Or restrict the keywords to the ones that don't cause this mental conflict.

Sebastian

My 2 cents:

Indeed, frames() is much more intuitive than steps(), both in terms of naming and functionality. I don’t see any issue with collisions with requestAnimationFrame or @keyframes, by that logic requestAnimationFrame collides with the <frame> tag!

However, we can't rename steps(), and having two very similar functions seems worse from a usability pov. So I would vote for extending the second parameter of steps() to cover the current definition of frames(). No strong opinions about the name of that parameter, but justify made the most sense to me. It's unfortunate we cannot make this the default. 😢

frames() is also a very animation-centric name, which could prove a problem down the road. In fact, I've suggested that the entire spec needs to be renamed and reworded to be more about generic interpolation and less animation-specific.

That sounds like renaming it to values() would help.

I can get behind that! And it works well for gradients as well, avoiding @LeaVerou's concern.

values() feels like it causes even more namespace concerns than frames() to me. Can we get any more obscure? How do I explain values(5) to a student? "Instead of a steady distribution of change, it creates 5 equally spaced values..." Hrm. Can someone phrase it better?

Yeah, that's precisely how I'd phrase it. What's wrong with it?

Well, remember many spec folks didn't have a problem with steps() to begin with ;) What sounds right in our ears might not sound right to folks working with CSS every day or getting into it from a non-spec-oriented space. Thinking back to my younger days, the concept of "values" of properties was a bit nebulous for me, in terms of change over time. And trying to think about how that fits with cubic-bezier curves and complex timing functions explanations...

I'll ask the folks on the Slack how they feel about it, regardless :)

My two cents: values is a very vague/ambiguous term. Which, I understand the appeal for using it outside of just animations, but still, in isolation (without context) I have no idea what its purpose/goal is.

Also, values does not convey the notion of "evenly distributed" - values, by the nature of the word, can be heterogeneous.

Some other bikeshedding ideas:

• partitions
• fragments
• segments

Option for keeping steps() while being more explicit about what is happening:

steps( <integer>, [ trim-start | trim-end | trim-both | no-trim ]

or

steps( <integer>, [ drop-first | drop-last | drop-ends | drop-none ]

Riffing on an earlier comment by Tab :)

As I mentioned before, I'm not keen on the drop-* terminology because most of the time you do actually see those endpoints either in the fill or the effective fill. As an example, consider the visual result if you apply those timing functions to a transition.

A continuation of @davidkpiano's suggestion of names, but parts(n) is generic, but might provide more context than values(). It is not animation specific, and I think it is self descriptive.

Ok, since we're bikeshedding names now, what about discrete()?

That sounds like renaming it to values() would help.

I can get behind that! And it works well for gradients as well, avoiding @LeaVerou's concern.

While I proposed it, I agree with the others that it's a pretty vague name. I'm still for extending the steps() function somehow. parts(), partitions(), fragments(), and segments() are similarly good, but none of them fits perfectly to all examples outlined by Brian.

Sebastian

This is almost certainly a dumb question, but why are all these special cases needed? Why can't the correct behaviour be deduced in the animation logic?

For example:

• if the final and initial states of the animation would look the same to the user;
• if the animation is going to repeat;
• if the user asks for frames(N);
• then divide into N+1 frames and display the first N for that run of the loop.

Do something similar looking at the final state (accounting for fill) on the the last run.

And automatically drop the first frame, on the first run, if it it resembles the state before the animation started.

Make frames() do the right thing out the box. If necessary, steps() can be extended for those rare cases when the right thing is wrong.

@fuchsia Automatically changing the behavior of a timing function based on the values of other properties is unlikely to be less confusing - it means you can't predict from looking at it how long each frame is! In particular, your suggested code would make the first/last iteration either have frames of different length than the rest of the animation, or have an iteration of different length from the rest of the animation. Both of these have a high chance of being bad due to things becoming unmatched.

Both Firefox and Chrome have decided to delay shipping frames() for the time being to allow this discussion to play out without being constrained by shipping implementations.

@tabatkins I think I thought user were being forced to make those decisions explicitly, with the bonus cognitive load of having to grok the issues in the first place. But I probably haven't understood it properly myself, so I'll stop digging (unless you want to use me to rubber duck debug the API.)

The CSS Working Group just discussed Name for frames() function., and agreed to the following resolutions:

• RESOLVED: Renames frames to steps, argument name TBD.

Talking with @fantasai during the break, I like center , stretch (spread?). @fantasai likes space-evenly, space-between and is concerned that if we were to go with center, stretch and later decided we wanted a version that behaves like space-around we will wish we used the space-* naming to begin with.

The CSS Working Group just discussed step function parameter names, and agreed to the following resolutions:

• RESOLVED: Use steps() function with the <integer> being number of visible frames during the animation duration

New issue for the keywords: #1680