[web-animations-1] commitStyles would be more useful / performant if it committed when animation was replaced / finished.

[flackr]

In web-animations-1, commitStyles commits the current effect values to the targets' inline styles, however as a result this means that commitStyles cannot be used as a replacement for fill: forwards, e.g. see crbug.com/1120718 or this tweet by @jakearchibald. Instead you have to fill: forwards and then cancel the animation after calling commitStyles.

If it's not too late, I propose that commitStyles should commit the effect value when the effect is removed (whether by replacement, finishing, or canceling). This serves the original purpose for adding commitStyles to ensure that developers can persist animation styles of replaced animations, but also functions as a useful replacement for fill: forwards animations as well as making it so commitStyles does not need to immediately freshen style.

This would of course be a breaking change but the usage of commitStyles is extremely low and it would still work in the original context for which it was recommended (i.e. when called on replacement).

@birtles @graouts WDYT?

[flackr]

Other less breaking options to solve the use case would be

• have commitStyles commit the last animation value (e.g. the final position before the animation finished).
• Add a "commit" fill mode which implicitly commits the animation on completion.

[birtles]

I think this might be a dupe of #5394 ?

If it's not too late, I propose that commitStyles should commit the effect value when the effect is removed (whether by replacement, finishing, or canceling).

I think that's not what we want? When the fill mode is empty, if the animation finishes, the value of the effect is empty?

• have commitStyles commit the last animation value (e.g. the final position before the animation finished).

I also think that's not what we want since, if I understand the suggestion correctly, it would end up being frame-rate dependent.

• Add a "commit" fill mode which implicitly commits the animation on completion.

That's an interesting idea, although I'm a little wary of extending fill modes since they're already problematic enough. It also does feel like a bit of a layering violation. Fill modes just affect the output of the timing model, they shouldn't affect the behavior of the animation (especially once you have nested effects).

An alternative from #5394 is to add a flag to commitStyles() that applies the appropriate fill mode.

[flackr]

I think this might be a dupe of #5394 ?

Thanks, I think this is a duplicate. I should have checked more carefully.

If it's not too late, I propose that commitStyles should commit the effect value when the effect is removed (whether by replacement, finishing, or canceling).

I think that's not what we want? When the fill mode is empty, if the animation finishes, the value of the effect is empty?

My intention was that conceptually value just before the animation was finished is the one that would be committed, such that the effect would not be empty.

• have commitStyles commit the last animation value (e.g. the final position before the animation finished).

I also think that's not what we want since, if I understand the suggestion correctly, it would end up being frame-rate dependent.

The intent is that it would not be frame rate dependent but rather if you assume an infinitely precise timeline it would be the value on that timeline when the effect finished. This would be equivalent to the fill value were it to have a fill.

• Add a "commit" fill mode which implicitly commits the animation on completion.

That's an interesting idea, although I'm a little wary of extending fill modes since they're already problematic enough. It also does feel like a bit of a layering violation. Fill modes just affect the output of the timing model, they shouldn't affect the behavior of the animation (especially once you have nested effects).

An alternative from #5394 is to add a flag to commitStyles() that applies the appropriate fill mode.

Adding a flag to commitStyles seems reasonable, though I have concerns with that specific approach which I will leave in a comment over there.

[flackr]

Duplicate of #5394