[css-animations-2] Review of animation-trigger/etc text

[tabatkins]

Hey all, in a breakout session at the Paris f2f earlier this year we settled a lot of lingering questions about the proposed animation-trigger feature. However, not all impls were in that breakout, and when @fantasai showed up at the end, she had some concerns with the syntax.

I've reflected all the resolutions we took in the breakout into the Animations 2 spec now, so we can get review in a reasonable manner. (See the 'animation-trigger' property, and the new Triggers section.) You can also view the changes individually, and the associated issues they were addressing, in PR #13009.

We hope to get discussion (and hopefully approval!) of the design we've settled on here in an upcoming telcon. Briefly, the design is:

• 'animation-trigger' is added as a reset-only sub-property of the 'animation' shorthand. It lists a trigger name, and an action to take when the trigger is activated. (or two, if the trigger can activate in multiple ways)
• Triggers are defined on the triggering element - some element with visibility of the timeline you want to trigger on, or an element you want to respond to events targeting.
• Triggers are global, with a simple name-clash resolution, essentially identical to 'anchor-name'. We anticipate adding a 'trigger-scope' identical to 'anchor-scope'. (We also resolved to shift timelines to use this same global+scope model to get everything consistent, rather than the current "define for a subtree and lift it higher with scope".)

[css-meeting-bot]

The CSS Working Group just discussed [css-animations-2] Review of animation-trigger/etc text.

The full IRC log of that discussion

<fantasai> TabAtkins: Discussed animation-trigger proposals, including at summer F2F
<fantasai> TabAtkins: Discussed a bunch of API questions during breakout, but not everyone was there
<fantasai> TabAtkins: So I collected all the resolutions we made, edited them in so can reviewed, and wanted to review them here.
<fantasai> TabAtkins: If any feedback, give now, or later, but want to put it in front of the WG for review
<fantasai> TabAtkins: Animations triggers kick off a time-based animation based on some kind of non-time-based trigger
<fantasai> TabAtkins: E.g. a scroll position
<fantasai> TabAtkins: There was also an interest in event-based animation triggers
<fantasai> TabAtkins: So a lot of different things interacting in same syntax space
<fantasai> TabAtkins: Current design splits into 2 bits
<fantasai> TabAtkins: First, triggers themselves get defined on an element.
<fantasai> TabAtkins: 2 types of triggers: timeline triggers, and event triggers
<fantasai> TabAtkins: These set up all the appropriate metadata for the trigger, most importantly its name as well as other options
<fantasai> TabAtkins: e.g. for timeline triggers it looks at the range, etc.
<fantasai> TabAtkins: We settled on a concept of a trigger can be stateful. Once it is entered, it won't fire another "enter" until it is "exited".
<fantasai> TabAtkins: For timeline triggers this is natural.
<fantasai> TabAtkins: For events this is optional, can also use statelessly
<fantasai> TabAtkins: Once a trigger is defined, it is globally visible, like anchor-name
<fantasai> TabAtkins: We also resolved to change the scoping mechanism for animation-timeline to match, so that all three features follow the same naming/scoping rules
<fantasai> TabAtkins: You then use trigger elsewhere. Currently only for animations.
<fantasai> TabAtkins: animation-trigger property (new sub-property of animation) associates triggers with an animation.
<fantasai> TabAtkins: Provide a trigger name and then actions that the trigger should do when activated.
<fantasai> TabAtkins: E.g. enter a particular timeline range do X, exit timeline range do Y
<fantasai> TabAtkins: That's the overview.
<fantasai> TabAtkins: Lots of discussion about exactly what bits go on the trigger vs the animation. We think we have a good breakdown atm.
<fantasai> TabAtkins: Example, what if you have 2-d scroll triger (intersection of x and y scroll positions), that's possible to fit in. Doesn't change interaction with animation-trigger.
<fantasai> TabAtkins: The design should be easy to copy from animation-trigger to other things that needs triggered, just need to define appropriate actions there
<fantasai> TabAtkins: Open for comments, open issues, gonna send over to TAG review shortly
<ydaniv> q+
<fantasai> astearns: Ok, we'll leave issue open until sufficient review
<astearns> ack fantasai
<TabAtkins> fantasai: 1) It would help to see an example.
<TabAtkins> fantasai: 2) before requesting wider review, would be good to get WD so the review is requested on an official draft
<TabAtkins> astearns: that implies you're okay with saying it's okay to publish?
<TabAtkins> fantasai: if we want to take more time to review that's fine, but I don't think we should kick to the TAG until it's ready to publish
<astearns> ack ydaniv
<fantasai> ydaniv: Good summary. Only thing we deferred for now was some ideas about makign the API a bit nicer or simpler.
<fantasai> ydaniv: But we deferred those because some issues with trying to simplify.
<fantasai> ydaniv: What we have now works, is coherent, can improve later
<fantasai> astearns: Any specific issues open on those ideas?
<fantasai> ydaniv: Some ideas we discussed in previous issues, and we simply had to decide some different path, which is what we currently have.
<fantasai> ydaniv: I still need to read what Tab did
<fantasai> ydaniv: Also missing Web Animations API for it, but we can do at second stage.
<fantasai> TabAtkins: Yeah, I didn't do any OM work yet because that's frustrating to write and want to do it just once. ^_^
<fantasai> fantasai: I think we should give the WG an example before we sign off on this.
<TabAtkins> https://davmila.github.io/sta-demos/explore/
<TabAtkins> ScribeNick: TabAtkins

[ydaniv]

@tabatkins overall it's looking good!

I see some stuff that needs to be corrected:

1. The table of <animation-action>s is missing play-once | -- | play() | -- | -- | --.

2. I think the following line is misleading:

   the associated timeline leaving the trigger’s exit range performs an associated exit action and switches the trigger state to "untriggered".

   The "untriggered" state is the "initial" state of the table, while the animation is in its before phase. When performing the associated exit action the trigger should switch an the "inverted" state, which is unlike the initial phase.
   Perhaps this could use better wording?

3. Issue 7 is not necessary, since we already resolved on doing just that (:

[tabatkins]

1. Yup, I just straight up missed the play-once item in David's comment proposing the simple starting set of actions. Added.

2. This is a different notion of "state", just tracking whether you're paying attention to the enter or exit triggers. It has nothing to do with the animation state (initial/playing/paused/etc).

   That said, do we need to do anything about the "inverted" state? Wouldn't that be something we have to treat differently depending on the animation-action? The animation model is complex enough that it confuses me when I try to understand its full details. :(

3. Got it, removed the issue.

[ydaniv]

That said, do we need to do anything about the "inverted" state? Wouldn't that be something we have to treat differently depending on the animation-action?

OK, so IIUC, that "state" is tracking whether the trigger is "activated" or not, right? Since the trigger's initial state is "untriggered", I think this state should be "deactivated". Currently triggers have an internal did trigger flag that tracks this, and I believe we'll still need such flag when we update the model.
So I think the "inverted" state should be when the trigger is "deactivated", but I'll also need another on this from @flackr 🙏