[css-animations][css-transitions][css-gradients] Higher level CSS interpolation module

[scottkellum]

Abstract

Numerous CSS modules have interpolation as a part of them: keyframe animations, transitions, gradients, and the new color mix functions. Consolidating interpolation into a module that makes the behavior more consistent across these, while also providing a path to new features like gradient easing, would be more logical and consistent for CSS authors.

Pain points in CSS and CSS drafts

• CSS gradient easing is a much requested feature [css-images] Add easing functions to color stops #1332
• Unlike gradients, CSS keyframes require all relative units. Imagine if one could use 0.5s alongside 50% in keyframes.
• Shifting scroll-linked animations to a more appropriate scroll-linked interpolation as it’s based on length typed measurements, not time.

New possibilities for the future

• Interpolate styles based on viewport width (like interpolating breakpoints)
• Possibly new ways to interpolate variable font settings

Related issues

• Rename spec and wording to be more generic [css-timing] Rename spec and wording to be more generic #1577
• Add easing to color stops [css-images] Add easing functions to color stops #1332

[SebastianZ]

There is already the CSS Easing Functions specification which defines general interpolation functions. So, everything that can be reused between different specifications related to interpolation and generally describes different values can be transformed into each other should go there.

Having said that, I think it makes more sense to specify interpolation of units and percentages directly in the related specification, because that's where you also find the definition of what the percentages resolve against.

Sebastian

[scottkellum]

Thanks @SebastianZ,

The biggest pain point I see is not with easing functions, but with scroll-linked animations. I have also been using animations to interpolate properties across viewport and element widths (as opposed to using media queries that don’t interpolate). There is a lot of room to expand the animation spec to interpolate more than just time. I see a lot of room for new CSS around interpolation and abstracting interpolation out of animaitons seems like a great place to start.

[birtles]

Sorry, I'm also a little unclear about the benefit of another spec. As I an understand it we currently have:

• Specific interpolation routines for different values either defined in CSS Values and Units for common types like <length>s, or in the specification that introduces the type. This was a deliberate change so that new specs can introduce new animation types without having to update another spec, and so that implementers of new properties can easily find the accompanying animation behavior that needs to be implemented.
• Easing functions defined in a separate spec so they can be re-used by animations and gradients.
• A desire to specify keyframe offsets using times ([css-animations-2] Proposal: Time-based Keyframe Animations #4907) and other animation durations using fix portions ([scroll-animations] Support progress-based animations on finite timelines #4862). Both of these should be specified by Web Animations Level 2 and then referenced by CSS animations level 2 (which builds on Web Animations).

These seem like the right places to me?

[scottkellum]

@birtles I’m excited to see this expansion in Web Animations Level 2. I was not aware of these issues and yes, they are revealing to me.

This proposal isn’t for another spec, but to abstract animations up a level into an interpolation spec to further reduce confusion as animations are being used for more and more things that aren’t time based animations. Interpolating styles across viewport and element widths is a particular feature I would like to see in CSS and this abstraction seems like a good place to start.

But again, really happy to see these changes to the keyframe spec! I remember not so eloquently trying to propose some of these changes on your initial scroll-linked animation spec.

[Bryce-MW]

EDIT: Turns out this was the wrong issue. Sorry!

[birtles]

Hi Bryce,

Which particular proposal are you referring to? The proposal to refactor specs? To define keyframe offsets using times? To define animation moment using fractions? Or something else?

[Bryce-MW]

I think I replied to the wrong issue. I was looking at a few things. I meant to reply to the one about changing the linear gradient syntax to allow something a bit like linear-gradient(red, ease-in-out, blue). Looking at this thread, this appears to be the wrong issue. I'm so sorry for that, I'll have to find the correct thread. My apologies!!

[scottkellum]

Possibly related: #581

[LeaVerou]

I thought this was mentioned in this issue, but I can't find it. Another disparity / pain point is that gradients can automatically space out color stops without a position, whereas for keyframes the author needs to do it manually, often with quite ugly, annoying to maintain results.

[css-meeting-bot]

The CSS Working Group just discussed Higher level CSS interpolation module, and agreed to the following:

• RESOLVED: This is something we want to work on, exact details TBD

The full IRC log of that discussion

<emilio> topic: Higher level CSS interpolation module
<emilio> github: https://github.com//issues/5617
<emilio> astearns: this also might be covered in-spec but not impls
<emilio> ... in addition to using calc() across various types, they want to use easing functions for ~all properties
<chris> q+
<emilio> ... haven't looked at it in a while, but perhaps we can use easing functions in all properties or is it more limited than that?
<emilio> chris: when we added animations and before with SMIL we got some feedback from animators saying that it only worked on two values
<emilio> ... so this is a thing we want any time we transition, animate or interpolate
<Rossen_> ack chris
<chris> yes, done
<emilio> astearns: and I don't think we have any of the easing editors on the call
<emilio> ... it seems they are meant to be used anywhere where a value could be set
<emilio> fantasai: wdym with that?
<fantasai> https://www.w3.org/TR/css-easing-1/#easing-functions
<emilio> ... they are meant to be used where an easing function is asked for
<lea> q+
<emilio> ... it's a function, not a value
<emilio> astearns: I believe scott's ask is for things like optical sizing to be able to use easing functions as values
<chris> seems like a reasonable ask
<emilio> ... to be able to have more subtle transition across values
<emilio> fantasai: you need a range of values for that as well
<emilio> lea: if I'm reading this correctly, easing functions is just a minor piece of that issue
<miriam> q+
<emilio> ... there are other important issues like mixing relative units
<emilio> ... you need to do ?? manually in keyframes
<chris> s/??/spacing/
<emilio> ... I didn't open this issue and scott isn't here, but I think the idea is to unify all these interpolation mechanisms
<Rossen_> ack lea
<emilio> ... so that the same features are available everywhere
<Rossen_> ack miriam
<emilio> miriam: when interpolating between breakpoints wrt media/container queries, part of the complexity is that you have to set those breakpoints and then somehow attach an animation to those breakpoints
<emilio> ... I've thought a bit to scrolling animations and animation timelines linked to container / media queries
<argyle> q=+
<argyle> q+
<emilio> ... not sure if something like that would help
<Rossen_> ack argyle
<argyle> https://shadows.brumm.af/
<emilio> argyle: I use a lot of online tools that would generate things for me like shadows (^)
<emilio> ... what I'd like to do instead of something like this is letting CSS do this with a clamp-like function
<emilio> ... so that I can get an easing shadow with a natural curve
<emilio> ... it'd be really cool to pass curves to shadows / gradients / etc rather than a bunch of percentages
<emilio> ... almost anywhere where we accept multiple values we could shorten the entire stack into one or two by specifying the range and a curve
<emilio> ... if you're looking for use cases for stuff like this I can help
<emilio> astearns: I think this is very relevant, there are lots of use cases to express stuff in terms of curves of values. not quite sure where to start though
<emilio> Rossen_: where do we go from here? Is this the most appropriate issue to capture this?
<emilio> astearns: bkardell suggests this as an expansion to web-animations-2
<astearns> s/bkardell/birtles/
<fantasai> emilio: Use cases adam mentions aren't particularly animation-like
<emilio> Rossen_: shouldn't but it's where most that stuff is defined
<Rossen_> q?
<emilio> Rossen_: sounds like enough motivation was heard. There are some overlapping efforts in the interpolation space with animations-2, and if that's not enough we need to figure out what else is needed
<emilio> ... is there anything else we can do with this issue?
<lea> +1 to work on it
<emilio> RESOLVED: This is something we want to work on, exact details TBD

[argyleink]

The author (@brumm) of a shadow easing tool has an open source function that we could emulate a CSS version after:

const values = eaze(2, {
  value: 10,
  easing: easings.linear,
})
// [ [5], [10] ]

where in CSS we could have (straw man syntax):

easeValues(3, 0px to 10px, linear)
/* 0px, 5px, 10px */

it wouldn't pacify uses case like text-shadow, box-shadow etc because those need more than lengths, they need full values like 0 0 5px black, and I don't think we could support use cases like that..?

box-shadow: easeValues(5,
  0 2.8px 2.2px rgba(0, 0, 0, 0.02) 
  to 
  0 100px 80px rgba(0, 0, 0, 0.07),
  ease-out
);`

could it? it almost starts to look like keyframes. and that also doesnt quite fulfill the use case of that shadow tool.. because it's using easing on the y, blur and color values with different easings. the above pseudo code would give all 3 the same easing, creating a different visual effect that's not as good.

just sharing my thoughts!

[mirisuzanne]

That's interesting, as a kind of repeat()-like interpolation for generating several values in one place.

As I understand the request here, another big part of this issue is thinking about new ways to control interpolation -- scrubbing seamlessly along the easing curve between values, based on… something.

• Historically transition and animation both followed a simple duration-based timeline, triggered by some event, and following through to the end
• Now an animation can also be linked to (and controlled by) a "scroll timeline" not based on duration, but on scroll-position

Currently, we can trigger duration-based interpolation with @media or @container, but we can't create new timelines based on them, the way we can with scroll-position. What would it look like to generalize out from scroll timelines, to allow even more interpolation controls?