[scroll-animations] Should animation events fire every time active range is left / reentered?

[flackr]

web-animations 4.4.19.2 suggests that a finish event (i.e. animationend) is queued whenever the animation enters the finished play state. Similarly a cancel event (i.e. animationcancel) is queued whenever the animation enters the idle play state.

ScrollTimeline based animations would technically enter one of these states any time the user scrolls past the active range. Does this mean we should be emitting animationend / animationcancel every time you leave the active range and animationstart everytime it is reentered? It's possible developers could use this to trigger post animation range updates.

If so, what about scrolling backwards when current time <= 0 but the animation's effective playback rate is still > 0? Should this generate a finish event since effectively we were playing the animation in reverse?

[birtles]

Good questions. Regarding the finish events, I think the way the CSS Animations Level 2 event dispatch is defined would work pretty well in these cases. Since Web Animations doesn't have a start event, however, it's tricky to know what to do in the scrolling backwards case. Maybe we need to add that event.

Regarding cancel events, I also agree that we probably shouldn't be dispatching those. We probably need to tweak either the definition of the idle state or cancel event dispatch so that we get finish events instead of cancel events, probably the former. I suspect this overlaps with #2066 somewhat.

[flackr]

Since we have updated the spec such that when you play scroll linked animations they get a start time of 0 at step 7 of web-animations-1 4.4.8 Playing an animation, we shouldn't have to worry about cancel events being dispatched anymore since the animation would not be considered idle due to its defined start time.

Proposed resolutions:

1. Animation events fire for scroll linked animations as defined by [web-animations-1 4.4.18.3],(https://www.w3.org/TR/web-animations-1/#animation-playback-event-types) and css-animations-2 4.1.
2. (Optional) Introduce a new event for web-animations which is dispatched when an animation goes from the idle or before phase to active phase equivalent to the CSS animationstart event.

[css-meeting-bot]

The CSS Working Group just discussed [scroll-animations] Should animation events fire every time active range is left / reentered?, and agreed to the following:

• RESOLVED: Animation events fire for scroll linked animations as defined by web animations spec

The full IRC log of that discussion

<Rossen_> https://github.com//issues/4324#issuecomment-1325707643
<fantasai> Proposal: https://github.com//issues/4324
<fantasai> Proposal: https://github.com//issues/4324#issuecomment-1325707643
<dael> flackr: An open question we had lingering about with a scroll linked animation you can repeatedly enter before or after phase by scrolling. As defined this fires animation events. Should it?
<dael> flackr: birtles and I chatted and we think it seems reasonable to fire events as define. Prop is events fire for scroll linked animations as specified
<dael> flackr: Second part we can take up separately
<dael> Rossen_: I see some back and forth on this. Anyone want to express other opinions?
<dael> Rossen_: Taking the silence as no additional opinions
<dael> flackr: Animation events fire for scroll linked animations as defined by web animations spec
<dael> Rossen_: Objections?
<dael> RESOLVED: Animation events fire for scroll linked animations as defined by web animations spec
<dael> flackr: Second part, CSS animations have an animation start event. Web animations have a ready promise which is not quite the same. Ready would resolve once.
<dael> flackr: Would it be useful to add a start event that developers could use to trigger on same condition. Every time you go from before animation is active to when it's active
<Rossen_> q?
<dael> birtles: I think you need something if it's possible to finish and then go unfinished good for authors to detect. Don't know it's a start event b/c that would relate to the delay. Maybe just an active event. Need to define some way for authors to know it goes from finished to not finished
<bramus> q+
<dael> flackr: Sounds like something we should come up with ideas and bring back.
<dael> flackr: Let's stick with first resolution and move on
<Rossen_> ack bramus
<dael> bramus: Wondering how that would work with various phases. I'm okay if we come up with some ideas to discuss