Related: #1332

I love that we're trying to be flexible with formats! One concern: I worry that we might be abstracting too much. Yes, in the future people might want to use these terminologies for gradients or heck even font interpolation! But... we run the risk of making these terminologies so obscure and awkward as to be unintelligible to the folks using them for those purposes.

How about merging them into CSS Transitions instead of renaming it? After all, those functions describe a transition from one value to another.

Sebastian

This was split out of CSS transitions because it it used by CSS animations, CSS transitions, and Web Animations. CSS transitions should depend on Web Animations, not the other way around, and we might want to use this from non-animation related specs so I don't think CSS transitions is a good home for this.

In terms of naming, I like "CSS Easing". It's short and memorable. It might not be completely accurate as some might argue that a step timing function is not really "easing" in the narrow sense of the word but my experience is that a simple and memorable name is preferable to a longer or less memorable but academically accurate one (hence why we named the corresponding property in the Web Animations API easing instead of timingFunction—and why we never should have renamed the CSS Motion Path module 😉).

I’m ok with easing, but why not progression? If anything, progression is an everyday word, whereas easing is unknown outside animation circles.

I'm ok with progression too, although, like offset, it does feel a little abstract to me. To me easing gives more of a sense of rate of change over time/distance. That is, gradient-easing makes more sense to me than gradient-progression since I'd expect the latter to take keywords like reverse and alternate, i.e. what direction does it progress in, as opposed to the rate at which it progresses.

Then again provided it never shows up in any property or attribute name, maybe it doesn't really matter what we name this module.

I prefer "easing function", too. It is a widely used term in animation, but is not explicitly limited to animation.

"Interpolation function" is more generic, and also widely used, but "easing" has the benefit of being shorter.

I'd recommend against inventing new names (like "progression function") for existing concepts. "Transition function" would be nice if we didn't already have a specific concept of CSS Transitions; but as is, I agree that it is useful to keep the concepts distinct.

For the spec name, I'd prefer CSS Easing Functions compared to CSS Easings Module (but css-easing for short).

Easing, though, and is a cross-industry standard term from motion design to studio animation, used wherever rates of visual change over time need describing. People using JS animation libraries use this term. I don't see why we should confuse them with yet another word for something they grok already. I'd keep "timing functions" over adopting "progression" or such.

The point of generalizing the name is that the functions are expected to be available outside of animation contexts in the future. Keeping the name for those contexts is confusing.

"Interpolation function" is more generic, and also widely used, but "easing" has the benefit of being shorter.

"Interpolation" sounds really good to me, but I could live with "easing" as well.

Sebastian

Interpolation is generally what we use to describe how to calculate an intermediate style value (e.g. the value 50% of the way between translate(100px) and rotate(90deg)). The output of the easing calculation becomes one of the inputs to the interpolation procedure (the 50% in the previous example). I think it would be most confusing to also refer to that as interpolation.

The CSS Working Group just discussed CSS Timing, and agreed to the following resolutions:

• RESOLVED: Rename css-timing-functions to css-easing-functions, shortname: css-easing

Done, and published at https://www.w3.org/TR/css-easing-1/

Can css-timing URLs be redirected to css-easing (and css-timing-1 to css-easing-1), so any links out there don't run into a 404?

Sebastian

redirects in place on drafts.csswg.org. /TR still needs a redirect for https://www.w3.org/TR/css-sizing-1/

@plinss css-sizing-1 has never existed and isn't relevant to this spec at all? https://www.w3.org/TR/css-timing-1/ redirects as expected.

sorry, brain fart, I meant timing. Agree /TR is good.