mastodon.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
The original server operated by the Mastodon gGmbH non-profit

Administered by:

Server stats:

323K
active users

Ana Tudor 🐯

Scroll-driven animations are still behind a flag in Firefox and I'm already filing bugs 🪲 bugzilla.mozilla.org/show_bug.

@anatudor That's what flagged experimental features are for! Testing them out & finding bugs before wide release.

Although, now I'm curious: does the spec even define how transitions work on scroll-animated properties? Should they wait until scrolling stops before triggering the start of the transition?

@AmeliaBR I'd expect after scroll and that's what Chrome seems to do. But Firefox doesn't trigger any transition at all.

@anatudor OK, now you got me digging...

No mention of transitions in the Scroll-driven Animations spec.

I know the cascade says transitions take top priority over any other change in value, while animations can easily be overridden. But do animations trigger transitions? They can't, right?

No mention of it in the CSS Animations spec.

Finally, I find this in the CSS Transitions spec, but I'm not sure how to interpret that in general, let alone for scroll timelines:
drafts.csswg.org/css-transitio

drafts.csswg.orgCSS Transitions Level 1

@anatudor If an animation is active, there is no additional current value from the transition. But the transition is still running from perspective of start/end events? How can the transition end if the animation is ongoing? Or, are we only talking about transitions triggered by changes in the base value, and then the animation overrides the base value & therefore the transition's effect???

If it's the second, then Firefox would be correct. The Chrome is more waiting for the animation to pause.

@anatudor Anyway, probably worth a spec bug, IMO. Definitely on scroll-driven animations, we've got inconsistent implementations & no clear spec.

The spec for animations/transitions interaction in general can probably be improved, too, although I assume we've at least got interoperable browsers there.

Edit: Already an issue filed:

github.com/w3c/csswg-drafts/is

Edit 2: OK, no, that's not really the same thing, that's about delaying the scroll-animated effect, not triggering a separate transition.

GitHub[scroll-animations-1] Transition delays in scroll-linked animations · Issue #7059 · w3c/csswg-draftsBy fantasai

@AmeliaBR And going from link to link, I got to something about the scroll snap syntax...

... which I started using with scroll-driven animations and things moving on the screen in different directions on vertical scroll and... ended up being very frustrated about the current one, which uses element positions rather than explicit offsets as it was the case in the old one. This makes me create N empty, invisible elements with aria-hidden='true' just to be able to scroll to certain positions.

@anatudor Yeah, the spec isn't really designed for the usecase of scrolling an empty background element as a UI for controlling another animation in the foreground.

@AmeliaBR @anatudor The rules that prevent animations from starting transitions are in w3.org/TR/css-transitions-1/#s , particularly the exact definition of before-change style. It's horribly complicated as a result of multiple layers of backwards compatibility, big fixes, and adjustments to deal with new features.

www.w3.orgCSS Transitions

@dbaron @anatudor Oh, that's a lot of text. (But thanks for finding it.)

If I understand it, the idea is that there's no noticeable transition on an animated value because (edit: better understanding it now...) you add the animation onto both the before & after values for the transition.

I guess in practice, it's no transitions on animated properties except that if the animation gets removed or finishes before the transition would, there might still be a running transition in effect.

@dbaron @anatudor I have to say: without other guidance in the scroll-linked animations spec, I think the Firefox implementation is correct. If there's a scroll-linked animation on a property, then there's always an active animation on it. Stopping scrolling shouldn't be any different than pausing a keyframes animation.

Any other behavior would need to be clearly spec'd.

But to keep things consistent, it might be easier to just spec a delay/offset property, as was suggested in that issue.

@AmeliaBR @dbaron But that just doesn't feel right. Okay, the animation isn't over until scrolling to the end of the page, but the scrollend event *is* triggered when you stop scrolling, even if you didn't get to the bottom.

Using the value of the custom property at that point, when scrollend is triggered, as a value for another property to transition to is the only way we can have scroll-triggered transitions. That is, transitions that get triggered once we scrolled to a certain point.

@AmeliaBR @dbaron It's no different from using that custom property that gets changed with scroll in a style query and triggering something from there.

And to clarify, in case this got lost somewhere: I am *not* transitioning the custom property that gets animated on scroll. I am transitioning *another* custom property to its value once scrollend gets triggered.

@anatudor @dbaron Yes, there are two questions to clarify:

1) Is a scroll-driven animation always active, only paused, or does the new value represent a change in state like a pseudoclass?

2) If a custom property is being animated, are transitions suppressed on all properties referencing it via var()?

As the specs are currently written, if there is an animation on a given property & element, including an inherited animation/transition, then a transition on the same property is suppressed.

@anatudor @dbaron I hadn't thought about how this creates a different model than style queries, which yes, are currently spec'd to respond to animated properties, the same way that size container queries respond to animated properties:
w3.org/TR/css-contain-3/#anima

I guess the difference is that the query model forces it into discrete change thresholds instead of continuous ones.

From a performance perspective it seems fine to use scrollend to make discrete changes. It's just not spec'd that way.

www.w3.orgCSS Containment Module Level 3

@anatudor @dbaron But that said, for implementing delayed / de-bounced transitions on scroll (which is a feature that is pretty common in JS-triggered scroll animations), I'd still rather see that spec'd directly, rather than trying to shake it out as result of rules for passing animated values through var() references.

I think maybe the intent was to add that in a future spec. There's a brief note here about "scroll-triggered" animations vs "scroll-driven" ones.
drafts.csswg.org/scroll-animat

drafts.csswg.orgScroll-driven Animations

@AmeliaBR @anatudor Still haven't dug in to all the comments here... but I did dig into the spec history, and there's a large set of pending changes to the spec text about starting animations that have NOT yet landed in the spec. The goal of those changes is to integrate better with container queries. I believe those changes are implemented in Chrome, but not sure about other engines. See:
github.com/w3c/csswg-drafts/is
github.com/w3c/csswg-drafts/pu

We should really try to get those changes landed...

GitHub[css-animations][css-transitions] Isolate animation side-effects? · Issue #6398 · w3c/csswg-draftsBy andruud

@AmeliaBR @anatudor So I think the summary of the changes to work better with container queries is that the mechanism used to prevent other types of animations from starting transitions is changing from "update the old style to having current animations and compare to current style" to "compare old style-without-animations to new style-without-animations".

The basic idea is still that (a) animations don't start transitions and (b) transitions override animations.

@AmeliaBR @anatudor But I haven't thought much about how scroll-linked animations fit into this. I think the basic model wasn't really designed with them in mind -- it was considering "other time-based animations". That said, we probably don't want a value that's animating continuously in a scroll-linked animation to trigger any transitions, and for simplicity it's probably worth extending that to things animating discretely too.

@AmeliaBR @anatudor For scroll-triggered animations, though, I could see making different decisions for things that change discretely. (Is scroll-linked versus scroll-triggered still the right terminology?) But I haven't been following the scroll-linked and scroll-triggered animations work very much.

@AmeliaBR @anatudor As far as Ana's original testcase goes... I think a transition on --prg definitely shouldn't work, but that's not the question. The question is whether a transition on --lag should work, and I'm less sure about that. I'd probably lean towards the Firefox behavior of not working, but I'd want to hear from the folks who implemented in both engines whether what they did was intentional and why...

@anatudor @AmeliaBR

I noticed that FF is having issues animating CSS variables in general.

The same example without scroll animation gives a different result from chrome as well: codepen.io/t_afif/pen/OJKQNZY/

codepen.ioUntitled...

@css @anatudor Hmmm, OK, so that's something else that isn't spec'd well: how does the interaction of transition/animations propagate through variables referencing each other. Again, not really sure which browser should be deemed correct here.

That massive algorithm that @dbaron linked only really considered regular inheritance to a single property, not var() references.

@AmeliaBR @css @dbaron But they don't reference *each other*. --prg never references --lag, it's not something reciprocal.

@anatudor @AmeliaBR @css One other thought about browser differences here is that there were major changes (mostly by Anders) to that algorithm so container queries would work... I should check if they made it into the spec.

@dbaron @anatudor @css OK, I went ahead and made a spec issue for the question of whether transitions should apply to properties that reference other animated properties, using Temani's simplified demo but mentioning Ana's scroll demo as a reasonable use case.

github.com/w3c/csswg-drafts/is

(Spec issue # 11,102, my goodness! From that perspective, the 3.4K open CSS issues aren't that bad.)

GitHub[css-transitions][css-variables] Impact of animation-tainted variables on transitions is undefined · Issue #11102 · w3c/csswg-draftsBy AmeliaBR

@anatudor I am personally waiting for the feature being developed a bit more there before reporting issues, as many of its features are still not there (basically, nothing from my experiments work there, mostly due to the absent range support). When it covers most of the current spec, only then I'll go and check how my stuff behaves there.

@kizu This isn't using range, only animation-timeline: scroll(). And the bug is not directly related to the scroll-driven animation part, which works fine, but to the transition on a property that depends on the one animated on scroll (which, again, works fine).