[csswg-drafts] [css-transitions][css-variables] Impact of animation-tainted variables on transitions is undefined (#11102)

AmeliaBR has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-transitions][css-variables] Impact of animation-tainted variables on transitions is undefined ==
As currently defined in the detailed algorithms of the [CSS Transitions spec](https://www.w3.org/TR/css-transitions-1/#starting), properties that are affected by a CSS animation on a given element, whether directly or by inheritance, will not have an observable transition. If the property value before animation changes in response to something else, a transition will start in the background, but it will be ignored when calculating the current animated value. And no transitions will be triggered by the actual animated change in value.

However, that spec currently does not consider an animation on a different custom property that is referenced (directly or indirectly) by the property with the transition defined. Neither are transitions mentioned in the limitations on [animation-tainted properties, in the CSS Custom Properties spec](https://www.w3.org/TR/css-variables-1/#animation-tainted).

I would assume that animation tainting would also suppress transitions, for consistency. Whoever did the relevant Firefox implementations must have made the same assumption. But whoever did the Chromium implementations did not. (I don't have results for WebKit.)

This creates a cross-browser inconsistency when applying a transition to a property whose value is a `var()` reference to an animated property; see this [Codepen demo](https://codepen.io/t_afif/pen/OJKQNZY/467093a3f8c0b35d96eef427844e2261?editors=1100)
In Firefox, the transition is suppressed & the two variables animate simultaneously. In Chromium browsers, the variable with the transition (used to set the size of the orange region) lags behind the other one (used to set the purple region).

That demo by Temani Afif is a simplified version of a scroll-driven animation demo created by Ana Tudor (see [code snippets in the Firefox bug she filed](https://bugzilla.mozilla.org/show_bug.cgi?id=1927325)). Ana was intentionally using a transition on a second property to create a delayed / debounced scroll animation (that is, one that waits until scrolling stops & then takes a moment to catch up), as had been proposed in #7059.  (In other words: if this discrepancy doesn't get sorted soon, people will be making content that depends on the Chrome behavior!!!)

See more discussion in response to [Ana's Mastodon post](https://mastodon.social/@anatudor/113379406050103422).  In particular, Ana brings up an interesting point by comparison to container queries, which as currently specified do update in response to animated property changes, and so could be used to trigger transitions, although only at specific breakpoints.

My personal opinion is that (1) a feature for supporting delayed scroll-driven animations should be specified directly, and (2) that the Custom Properties & Transitions specs should be clarified to match the Firefox behavior, by including animation-tainted variables as one of the types of declarative animations that need to be excluded from transition calculations. (I have no idea how best to say that in the current detailed transitions algorithm, but someone wrote that text & hopefully remembers the reasons behind all of its steps!)

But as always, I mostly care that the behavior is clearly specified, tested, and implemented for cross-browser consistency!


Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11102 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 28 October 2024 22:06:52 UTC