[css-animations-2] Specify the animation-trigger property

[ydaniv]

Adding initial draft for Animation Triggers and the animation-trigger property as resolved in https://github.com/w3c/csswg-drafts/issues/8942#issuecomment-1854342340.

I cleared all the issues and fleshed out the gist of it.

cc @flackr @birtles @dbaron

[birtles]

@ydaniv Thanks for doing this. I started going through it today but I was a little confused about the hierarchy of components from the Web Animations API point-of-view. It sounds like we have the following parts:

• Animation trigger timeline (currently a DocumentTimeline but possibly scroll-driven timelines too)
• Animation trigger
• Animation trigger effect
• Animation

What is the relationship between them? Do the Animation trigger and Animation share an effect? Is the Animation trigger connected directory to the Animation trigger effect or only via the Animation? Is the Animation attached to the Animation trigger timeline or just the Animation trigger?

Sorry, I'm probably being really daft here but I couldn't grasp how the pieces fit together.

Defining some of these primitives as Web Animations constructs like @flackr suggested might help clarify how they fit together.

[ydaniv]

@birtles thanks for reviewing!

The intention of the hierarchy was mostly to simplify the spec, by having triggers follow animations as in: For animations: timeline -> animation -> effect For triggers: timeline -> trigger -> effect And since effects are attached to attachment ranges, have trigger follow the same mechanism.

The idea was that they don't share anything, just follow the same structure, and the trigger simply affects the animation's playback according to its properties and state.

But, as @flackr mentioned, it's still too confusing and too complex, so I'll try and rewrite this without the effect part, and only with a trigger attached to a timeline and a range.

I've tried defining the constructs first in the initial draft. I'll move those into the Web Animations spec as suggested, and try to organize them together again in a simpler way.

[birtles]

The intention of the hierarchy was mostly to simplify the spec, by having triggers follow animations as in: For animations: timeline -> animation -> effect For triggers: timeline -> trigger -> effect And since effects are attached to attachment ranges, have trigger follow the same mechanism.

The idea was that they don't share anything, just follow the same structure, and the trigger simply affects the animation's playback according to its properties and state.

Makes sense!

But, as @flackr mentioned, it's still too confusing and too complex, so I'll try and rewrite this without the effect part, and only with a trigger attached to a timeline and a range.

Ok, I'll look forward to seeing what you come up with!

[ydaniv]

@flackr @birtles I've just pushed changes, I think I've covered all the comments, thanks!

[ydaniv]

kind ping @birtles @flackr, ready for another review.

[birtles]

kind ping @birtles flackr, ready for another review.

@ydaniv Sorry for the delay--currently on parental leave. Just a few meta points:

1. I think this should be part of Web Animations level 2. Level 1 is basically done except for fixing existing issues (most notably the commitStyles changes we agreed to but I've yet to edit in).
2. I think we need to define the API parts for triggers?
3. We probably need to review all the descriptions about timelines and animations to make sure it accounts for triggers. (e.g. the sentence "Updating the current time of any animations associated with the timeline." should probably refer to triggers too?)

[ydaniv]

Thanks @birtles!

currently on parental leave

Congrats ^_^!

1. I think this should be part of Web Animations level 2.

Ok, I also wondered about that, but @flackr wrote Web Animations 1, and some things I needed to update were actually there, so not sure whether this was intentional or not.

2. I think we need to define the API parts for triggers?

You mean the DOM interfaces, as in here?

3. We probably need to review all the descriptions about timelines and animations to make sure it accounts for triggers. (e.g. the sentence "Updating the current time of any animations associated with the timeline." should probably refer to triggers too?)

I've added this text to that section:

• Updating the [=animation trigger state=] of any [=animation trigger=] [=associated with a timeline|associated with=] the timeline.

Shouldn't this cover it? I think basically comes down to checking triggers state on timeline's current time update.

[birtles]

currently on parental leave

Congrats ^_^!

Thanks!

1. I think this should be part of Web Animations level 2.

Ok, I also wondered about that, but @flackr wrote Web Animations 1, and some things I needed to update were actually there, so not sure whether this was intentional or not.

Yeah, that would be good to know. My understanding is it should be level 2 but maybe @flackr has some ideas about that.

2. I think we need to define the API parts for triggers?

You mean the DOM interfaces, as in here?

I was thinking about the Web Animations DOM interfaces. Just like we have the Animation interface I assume we'll have an AnimationTrigger interface?

That also makes me wonder how authors would expect to be able to inspect these from script. Is there some way to fetch the triggers in a document? Or the trigger driving a particular Animation?

3. We probably need to review all the descriptions about timelines and animations to make sure it accounts for triggers. (e.g. the sentence "Updating the current time of any animations associated with the timeline." should probably refer to triggers too?)

I've added this text to that section:

• Updating the [=animation trigger state=] of any [=animation trigger=] [=associated with a timeline|associated with=] the timeline.

Shouldn't this cover it? I think basically comes down to checking triggers state on timeline's current time update.

Yeah, I was thinking that we need to review the whole section to check for other references that need to be updated like the sentence I mentioned and other definitions like this one:

An animation effect, effect, is associated with a timeline, timeline, if effect is associated with an animation which, in turn, is associated with timeline.

Presumably that needs to be updated to include triggers too?

This is a pretty fundamental change to the whole timing hierarchy so we need to be careful about it. I wonder if it would be better to introduce an abstract concept that covers both animations and animation triggers like "timeline subscribers" or somesuch.

[ydaniv]

I was thinking about the Web Animations DOM interfaces. Just like we have the Animation interface I assume we'll have an AnimationTrigger interface?

I opened an issue with a rough proposal here. I could add that in already, as an initial proposal for API. I thought to wait with that for a later PR, since we only resolved on adding an initial draft and going with it back to the group for approval.

That also makes me wonder how authors would expect to be able to inspect these from script. Is there some way to fetch the triggers in a document? Or the trigger driving a particular Animation?

I missed that part, I guess I could add that in. Regarding additional APIs, like getting all triggers from document, I guess we could always add these later on demand?

Yeah, I was thinking that we need to review the whole section to check for other references that need to be updated like the sentence I mentioned and other definitions like this one:

An animation effect, effect, is associated with a timeline, timeline, if effect is associated with an animation which, in turn, is associated with timeline.

Presumably that needs to be updated to include triggers too?

I checked everything and didn't find anything else. I think since triggers only affect playback state and are associated with a timeline, it should be enough to check/update their state according to the timeline, since the trigger's spec describes what to do on state change.

This is a pretty fundamental change to the whole timing hierarchy so we need to be careful about it. I wonder if it would be better to introduce an abstract concept that covers both animations and animation triggers like "timeline subscribers" or somesuch.

Agreed. I tried simplifying it on the last change.

[flackr]

Ok, I also wondered about that, but @flackr wrote Web Animations 1, and some things I needed to update were actually there, so not sure whether this was intentional or not.

Yeah, that would be good to know. My understanding is it should be level 2 but maybe @flackr has some ideas about that.

Sorry if I created some confusion here. I was mostly getting at that the concepts that need updating are in the web-animations-1 spec, but of course additions to the spec should go in web-animations-2.

[ydaniv]

@flackr finished addressing all comments from last review

[ydaniv]

@flackr kind ping, in case you missed this, I think it's ready for another round 🙏

[flackr]

I think this also needs to add the animation trigger to The Animation interface.

[ydaniv]

@flackr I've added the definitions for the AnimationTrigger interface. I've added a Setting the timeline of an Animation Trigger algorithm which should make the extra step in update animations and send events redundant and instead updating timelines' current time should take care of triggers as well. I've also made some more fixes. I think it's ready for another round, thanks!

[ydaniv]

@flackr kind ping, should be ready for another review, thanks!

[ydaniv]

@flackr any chance we could make some progress here to present something at TPAC?

[ydaniv]

@flackr I think all last comments are addressed, thanks!

[ydaniv]

@flackr there was a missing definition for the Animation/trigger attribute. Added it now.

[ydaniv]

@flackr kind ping, I think this is ready for review.

[ydaniv]

@flackr just pushed fixes for the last round of reviews, I think it's ready for another check.