Clamping values and additive animation

[KevinDoughty]

There is no useful form of additive animation that disallows negative Keyframe values. SVG spec defers clamping for opacity:
https://www.w3.org/TR/SVG11/implnote.html#RangeClamping

CSS does not. This needs to be specified. Firefox and Chromium behavior differ on additive opacity animation. Firefox (only recently) disallows clamping, while Chromium permits useful behavior:
https://bugzilla.mozilla.org/show_bug.cgi?id=1984925

This needs to be extended to include all clamped property values, including but not necessarily limited to width, height, and the new size shorthand.
#12645

[KevinDoughty]

Related:
#3340 (comment)

[KevinDoughty]

After investigation I believe the issue with Firefox is a bug, not a feature (of under-specification). I still hope for clarity and correction by the W3C on this matter. Thanks.

[KevinDoughty]

I was right the first time. The problem is under-specification. The only useful form of additive animation has been arbitrarily restricted.

if context.for_smil_animation {
    // SMIL expects to be able to interpolate between out-of-range
    // opacity values.
    value
} else {
    value.min(1.0).max(0.0)
}

[tabatkins]

Well, it's not an arbitrary restriction, it's just that additive animations have been awkwardly hacked on top of normal style application. An additive property animation is not setting a value, it's applying a delta, and thus intrinsically is a different data type than the normal property is.

I agree it's unfortunate, for sure.

[KevinDoughty]

I’m glad you view them as deltas but I wish you would not call it a hack, because with improved support this technique could gain widespread use. Many of my proposals have been unrealistic in their demand for engineering resources, but the most gain for the least effort would come from allowing out-of-bounds keyframe values.

Una was gracious enough to explain to me over social media the reason for transition-behavior: allow-discrete was to not break existing sites who were transitioning all.

It’s not unfortunate, with the concession that if adopted, any console warnings for out-of-bounds keyframe values would simply go away in sites who neglected them and their animations would suddenly start behaving as expected.

In other words, if the W3C decided to clarify and correct this, it would not break any existing sites.

I’m not prepared to evaluate every type but incremental adoption could start with zero-to-one and length/percentage. Non-negative numbers would be nice for completeness but I can’t name a property I’d actually want to animate. It would be pointless to animate an opacity keyframe value of 10 or 100 or something, there is no use case for this. I don’t know what the answer is for such far out-of-bounds values but what harm is it if clamping is deferred?

I’m also not able to assess the performance impact of deferred clamping, other than pointing out Chromium and earlier versions of Firefox did this for opacity already.

[tabatkins]

I'm saying that the CSS spec approach of doing additive animations this way is a hack; reusing properties both as endpoints (normal property usage) and as deltas (different data type with different processing) is hacky, especially since you can't tell which mode they're being used in at keyframe definition time, only at application time. Additive animation isn't hacky in and of itself.

I think it might indeed make sense to avoid enforcing min/max constraints while parsing @Keyframes rules, because of this, and only go back and enforce them when actually applying the keyframes (as a normal animation).

Or maybe we stick with the current behavior, and add a switch to @keyframes instead that declares the rule to be specifying deltas, which relaxes the parsing rules (so they're actually deltas) and makes them only usable as an additive animation.

[KevinDoughty]

My expected use case for relative and additive is manually constructed Web-Animations, to blend on interruption and retargeting of in-progress animation, using the timing function. I’m not sure how useful @keyframes would be for web apps, if only one ever runs at the same time.

If a page author has a @keyframes fadein and @keyframes fadeout and toggles them by changing classnames, and the user presses the toggle button rapidly three or more times, it would be difficult to design the page in such a way that three or more CSS Animations run simultaneously.

On the other hand, if you do want to add a switch then instead I would recommend a subtract operation for CSS Values, CompositeOperation: blend, transition-composition: blend, and animation-composition: blend. These would automatically calculate those deltas so a page author wouldn’t have to think about animating a fade-in opacity from -1 to 0 and instead merely specify 0 to 1. In addition, CSS Animations would have to somehow “detach” so they don’t get removed until completion, allowing multiple to run at the same time.

That would be a huge undertaking, but don’t let me dissuade you. However, a @keyframes switch that does not do the conversion and detach CSS Animations might preclude them in the future.

[KevinDoughty]

Probably off topic but blend sidesteps the out-of-bounds keyframe issue entirely. It only needs discrete source and destination values, never in-between values even on interruption, which means fewer style recalculations and no risk of layout thrashing. In my proof-of-concept implementations, it magically worked with the animation pane for the developer tools when out-of-bounds keyframes would not. Detaching was somehow trivial to implement in Firefox but I never figured it out in Chromium.