Meeting minutes
github-bot, take up w3c/
[css-animations-2] Move scroll and event animation triggers to independent namespace
<github-bot> OK, I'll post this discussion to https://
DavidA: we have the animation-trigger feature for controlling animations
DavidA: we initially wrote the spec with timelines in mind
DavidA: so there was a timeline range you enter to do something to the animation, and a range that you could exit to do something else
DavidA: so we had trigger actions attached to those ranges
DavidA: in expanding the trigger idea to include event based, like clicking an element and having that start an animation
DavidA: conceptually, there's enough diff between these two trigger types that they'd require a different set of properties
DavidA: so should have separate property sets
DavidA: that's the main proposition from this issue
DavidA: so there is another competing model
DavidA: so with separate proeprty sets we have timeline-trigger-* and event-trigger-*
<flackr> (similar to the pattern of scroll-timeline and view-timeline)
DavidA: the other is that everything is an event. entering a timeline range is an event, exiting is as well
DavidA: the all-events model appears appealing, but we think there's some subtlely in the timeline concept that are properly reflected with just events
DavidA: so we think it's better to keep the property sets separate, to better capture different types of triggers
DavidA: it also simplifies some other aspects fo the syntax
DavidA: so proposal is to go with separate property sets
DavidA: timeline-trigger-* and event-trigger-*
TabAtkins: I discussed this a lot with fantasai
… agree that this is the model to stick with
… the seperate property sets
lea: is there more complete code snippets showing them?
DavidA: the issue is really long now, but i have an explainer
lea: [question about explainer, tab explained it a bit]
lea: are the play/pause etc predefined?
TabAtkins: yes
lea: down the line could we have other things care about the triggers?
ydaniv: yes
lea: what's the scope of these triggers?
TabAtkins: similar to view timelines, visible to element+children by default, can be lifted up with a -scope proeprty
DavidA: actually we've been thinking would be better fo rthem to be global by default, with -scope limiting them instead
flackr: we should talk more about making things consistent
ydaniv: we had some back and forth in the issue
ydaniv: there were concerns about mixing view-related triggers with others
ydaniv: assuming this is a real concern so we don't want to mix things...
ydaniv: and that's a motivation for separating timeline triggers from the rest of the events...
ydaniv: then i can accept timeline triggers being separate properties
ydaniv: and we can always invent new events like view-enter() in the future
ydaniv: but this might indeed be a safer way to start, yeah
ydaniv: i added a comment an hour ago in the issue
w3c/
ydaniv: here, i suggested how to split up the properties between the elements, the api surface
ydaniv: making event-trigger a way to declare event triggers, timeline-trigger to declare timeilne triggers, then all the animation bheaviors (the action) only on animation-trigger
ydaniv: then animation-trigger is the name of the trigger (or an anonymous functional trigger), with some controls for changing the action or behavior
ydaniv: this implies an "always" starting trigger
ydaniv: if you don't specify another one it'll reuse the starting trigger for exit, otherwise you can specify
ydaniv: also, timeline triggers have two ranges, they're not allowed in the exit trigger; if you specify them in the first they ignore what's specified for end
ydaniv: so you avoid mixing
flackr: that's not exactly the concern, i can clarify
flackr: if viewenter and viewleave are discrete events, we can't ensure you've set them up correctly so you always get a viewleave before a new viewenter
flackr: if they're coming from a single timeilne trigger, we *can* ensure you get them in pairs
ydaniv: so it's important to ahve the same timleine, but diff ranges are okay
TabAtkins: say you have a large interrange for the 1st one, enter it and dtriger, and then you have a smaller range in the middle. Would that imply you never trigger the middle?
TabAtkins: you have 2 timeline triggers, one large and one smaller nested inside it
… you have two ranges, a small one nested inside a larger one
TabAtkins: would you never trigger the inner one, since you're already in the outer?
flackr: no, those are indepdnent. the concern is that if you have a small enter range and a large exit, you could enter the enter range, leave it, then reenter before leaving the exit range, and pure events would fire a second enter; we want to avoid that
TabAtkins: makes sense
szager: my interpretation of ydaniv's proposal was the internal mechanism would have this infomration; the events were independent in the syntax but could still be linked to only fire in the correct order
szager: i think it's not correct then, to say we can't guarantee against two enters in a row. it would just be a little bit magical, maybe less intuitive to devs.
szager: would involve a bit of hidden state
szager: so my objection is this hidden bit of state would be easy to get wrong for devs, maybe confusing. better to force them to be more explicit about the ranges
flackr: dunno if i completely agree. for simple cases could just work.
flackr: but say you have an enter range on a and an exit on b, another has enter on a and exit on c...
szager: i see, so if you're mixing timelines...
flackr: there's no association fo the trigger timelines, so that's an issue
szager: so for mixed multi-timeline case, the event model can't guarantee consistency
lea: this seems great overall
lea: on this specific design, have we considered having just a single event trigger and making timelines a kind of event?
TabAtkins: that's what we were just discussing ^_^
flackr: say your animation start on a small view range, and only resets when it fully leaves the viewport
[explains this]
lea: can you have a shorthand to just set the exit range easily?
flackr: that's the default - if you don't specify an exit range, it matches the enter range automatically
szager: key thing is just that enter+exit have to be declared atomatically
*atomicly
lea: but if they're separate events, you could pass them both to the API...
szager: it's not functional that's th eproblem, it's that the enter+exit have to be tracked as a unit
lea: i could imagine using a click as a trigger to start an animation, then once it scrolls out you pause it, and when it comes back into the viewport...
ydaniv: that requires multiple triggers
ydaniv: which we're deferring
lea: what i'm concerned is we have some events that parallel some ui events, and timeline triggers that are a separate thing.
lea: are we likely to need more types of triggers? if so, do we want to add more sets of properties?
flackr: the reason for the separate namesapce is the properties for setting up the trigger depend on the type of trigger
flackr: events are simple - just give the name fo the event
flackr: for timelines, we have to supply a bunch more, like setting up an intersection observer
TabAtkins: if we're adding more things then we add them as events
… if they need special cases we add more properties
… trying to cram all of that into a single model is not great syntactically
szager: coudl we talk for a moment about something from ydaniv's comment?
szager: specifying the actions in the animation-trigger rather than in the trigger element
szager: my concern here is that you have a `start exit?` which is timline-biased
szager: not clear ot me that an action specification like this makes sense for an event trigger
szager: could just say that exit is a no-op for events, but seems a little squirrelly
szager: so curious about what the motivation for having the action on the animation element is
szager: generally, the trigger element seems like the "controller" in MVC. if you were doing this in JS, you'd specify the action *in* the click handler on the trigger element, for example
ydaniv: a few reasons
ydaniv: If we want these trigger properties to be usable for other stuff later, then adding animation-related actions to those proeprties doesn't make sense
ydaniv: a second, say you want to name a click trigger, and you want it to play one aniamtion, reverse a different one
ydaniv: you'd have to declare two nearly-identical triggers
ydaniv: so my suggestion is that this just declares a trigger, you can use it however you want. the animation decides what to do with the event
szager: what about this issue of being timeline specific, with the start+exit tirggers?
szager: if we later wanted more options for a new type of trigger, would we have to alter this syntax? enter+exit+something else?
szager: looking at the third example in your comment, the exit trigger seems timeline-specific
ydaniv: in the case of timelines, you don't need an exit trigger. it's inherent to the timeline
ydaniv: but if you have an event trigger for the animation start, and you want to reverse on every click, you can just add reverse; dont' need an exit trigger
ydaniv: but wanted one event for starting, and another event for reversing or pausing
ydaniv: so in that case, start with this trigger, do the reverse/reset with another event
szager: a little confused aobut terminology. you said "exit", that applies just to timelines for me
ydaniv: exit means "end" here, start and end
szager: i'm confused
flackr: i think he just means you can specify a different event for an end trigger
ydaniv: so you can have click on this button to play forwards, click on another button to play backwards
szager: and click on a third to reset?
flackr: that's my concern too, there's more than two actions
szager: yeah, i'm concerned it'll get hairy, cramming too much into this
DavidA: i'm also concerned abou thow this maps to the JS api, not clear what instantiates the animation trigger
DavidA: right now you just have the trigger on the source element. not enough to attach the animation to it, you have to add the action as well
DavidA: becuase if you reuse the trigger you can have a different action on a different element
TabAtkins: my concern here is that we're currently deferring the ability to add multiple triggers
… while timelines have the concept of 2 events mixed together, other events don't have them
… I think we should have just one event properly and then figure out the rest
flackr: i think you said pretty well what i wanted to say
flackr: the idea of having start+stop and making triggers independent of animations...
flackr: the only way I can see doing that is having basically a third thing that provides the link between an event name and an action
flackr: it could be that this is a functional syntax in the animation-trigger syntax
flackr: animatino-trigger: action(--foo play)
flackr: and we spec that timeline triggers generate two events, events generate all the events that are possible
flackr: taht's the way to go about it rathe rthan specializing timelines
szager: terminology point
szager: there are "events" from UI. timelines ahve "actions" (enter/exit). we have "behaviors".
szager: event is a 0-dimensional UI event, action does the thing. Timeline has two actions, enter and exit, each is linked to a behavior.
proposed resoluition: use timeline-trigger-* and event-trigger-* separate property sets
RESOLUTION: use timeline-trigger-* and event-trigger-* separate property sets
TabAtkins: do we ahve a proposed reoslution for attaching behaviors to triggers, or take it back to the issue?
DavidA: can we defer for the moemnt and see if we can land on a proposal?
flackr: yeah, think there's three ways it could potentially work
DavidA: i do recognize yehonatan's concerns making the triggers animation specific, making them less reusable
ydaniv: if we're settling now on just using a single trigger in animation-trigger, and then a behavior, we can go back to the older syntax, a keyword for the behavior and once/repeat/always/state
ydaniv: i think that's something that can work both for timelines and events
ydaniv: by default "once"
ydaniv: and if we ahve a timeline, it uses the two ranges
szager: this ocmes back to my original attempt to cast events into the timeline behaviors, we had objections to those
ydaniv: i just think, in all our proposals, the default action is to play
ydaniv: we can split things more when we add multiple triggers to an animation. but for now, you always play first, then do something else on subsequent events
TabAtkins: either need to allow multiple clicks in the action in some way or talk about multiple triggers on one animation so we can assign multiple behaviors to a given click
TabAtkins: this split of once / always state felt very confusing, defined purely about actions in the animations api rather than what the author or user saw happened
TabAtkins: it's possible it was just confusingly authored, but it seems more consideration needs to happen about what behavior of events are
TabAtkins: Lots of ways to potentially do this. The behaviors need to be TBD for a bit
szager: i need to head out, but i think this needs more discussion, yes
flackr: i think having multiple triggers isn't controversial, it's just a question of what the splitting mechanism is
flackr: we already have comma-separated list coordinating with the naimation list
flackr: we need another delimiter, then
flackr: maybe spaces is sufficient and we coudl go with that
DavidA: a nice thing about animation-trigger just being the name, that's pretty easy
flackr: right, if anmatino-trigger is a shorthand for a bunch of values, that's very hard. but if it's just trigger, or trigger+behavior, we can probably do it pretty easily
DavidA: in JS, think of TimelineTrigger object
DavidA: if it's an object, maybe you can listen to its events
DavidA: that would still be something we can map somehow to be used outside of animation context
DavidA: even if we implicitly bake the actions into these, it woudln't stop us getting the signals
flackr: I think we can consider this issue resolved, and open a new issue about exactly how we associate beahviors
github-bot, topic w3c/
[web-animations-2][css-animations-2] Should animation-trigger-exit-range be constrained to being greater than or equal to animation-trigger-range?
<github-bot> OK, I'll post this discussion to https://
DavidA: this came from our earlier discussion
DavidA: the use-cases we can think of, it's useful to have the exit range as a superset of the enter range
DavidA: it seems like it could just create unexpected beahvior if they're not matching
DavidA: so i propose we help authors by enforcing this
flackr: >= for animation ranges is hard to calculate
flackr: i proposed in the issue that once a trigger enters, it doesn't exit until it's out of both ranges
flackr: so you could specify totally separate ranges, it just wouldn't be meaningful
flackr: but it would mean we don't have to coerce the ranges so one is greater than the other
DavidA: i think my initial concern is if you were still in the entry range but now out of the exit range... that would trigger exit action
DavidA: so you have separate enter and exit ranges.
DavidA: you go into the entry range, you trigger the naimation, but then you're immediateyl outside the exit range
DavidA: but your proposal addresses that
flackr: yeah so if you're in either range, you haven't exited the range
ydaniv: one exception is, if you ahve a place where an author specified two ranges that don't overlap, you could be somewhere in the middle...
ydaniv: oh, you'd just be exited
TabAtkins: i'm fine with either a union of the ranges, or a bounding range
flackr: i just didn't want to ahve to compute the bounding range, especially in the computed style
TabAtkins: ah, i wasn't thinking of it being reflected into the style
flackr: as long as it's not reflected, i'm not opposed to using a bounding range
flackr: but i do think eitehr solves the problem
flackr: i have a slight preference for the simpler thing
TabAtkins: my problem with union is just that if the two ranges are disjoint, you effectively ignore the exit range entirely. but that's weird - in the more common case where you ranges overlap, just not perrfectly, it's indistinguishable, so that's fine.
proposed resolution: the "actual" exit range is the union of the specified enter and exit ranges
RESOLUTION: the "actual" exit range is the union of the specified enter and exit ranges
github-bot, take up w3c/
[css-animations-2] animation-trigger Name Clash Resolution
<github-bot> OK, I'll post this discussion to https://
flackr: you can specify the same name ident for event-trigger and timline-trigger
DavidA: two different elements in the same scope that define the same name for a given trigger
DavidA: and a single element defining both an event and timeline with the same name
DavidA: in the first instance, i propose we follow the precedent from anchorpos of using last in tree order
DavidA: for the same element establishing both, we consider that invalid
flackr: you get neither working?
DavidA: yes
flackr: for the first case, this goes back to the issue about having three things now that want to have some sort of tree scoping/visibility - anchorpos, timelines, triggers
flackr: ideally all would ahve the same scoping semantics
flackr: but we have different now. anchors are globally visible, timeline are scoped to defining elements
flackr: both can be given an explicit scope
flackr: they also have different behaviors if multiple elments define the same name.
flackr: anchors use the last, timelines become invalid
flackr: so i'd love to unify these
flackr: don't know what exactly the behavior is, maybe the anchor model largely
TabAtkins: do you thin kit's possible to change timeline scope at this point?
flackr: i don't think it's so widely adopted it would be a compat risk
andruud: it's that way for a reason, we coudln't define this to "go back". if an animation depends on a timeline, and the timleine doesn't appear until later in style resolution, how do you resolve that?
andruud: timeline-scope creates a "placeholder" timeline that later gets attached
andruud: anchor instead uses interleaving, with requirements about rendering order
andruud: so not sure we can change how timeline works for scroll-driven animations
flackr: when you encounter a timeline name that hasn't been define dyet, you'd walk up to th enearest timeline scope, and implicitly create a placeholder timeline
flackr: and then when we find a timeline for that name, we'd re-run the lifecycle
andruud: hm, i'd buy that
flackr: i think that creates a consistent answer for the developers
ydaniv: this is basically an implicit timeline-scope:all on the root
flackr: so do we support timeline-scope:all?
bramus: no, not yet
ydaniv: haven't specced it, just resolved to add it
flackr: okay, well timeline-scope:all basically requires all the machinery we'd need here alreayd
flackr: i suspect the compat risk is low, we can measure
proposed resolution: change timeline scoping to be global by default (like anchor names), and have triggers do the same
bramus: concern is apple is currently implementing SDA, and they're not in the room
bramus: just making sure Anders is fine with this, he was first to implement this
andruud: it's fine
andruud: do we need an equivalent "placeholder" for timeline triggers?
flackr: because the trigger... not sure, maybe
andruud: the act of the trigger appearing could cause the animation to immeidatley play and ahve an effect that frame, so we need something
flackr: yeah. i think it's doable
TabAtkins: objections to the proposed reoslution?
RESOLUTION: change timeline scoping to be global by default (like anchor names), and have triggers do the same
TabAtkins: and someone needs to be sure to let the Apple devs doing SDA know about it.
ydaniv: firefox also has it behidn a flag
TabAtkins: returning to the main issue - if multiple elements define the same trigger name, do we use the last in tree order (matching anchor) as David suggested, or make them all invalid (matching timeline)?
flackr: For anchor, was there an affirmative reason?
TabAtkins: yes, there use-cases for having multiple elments with the same anchor name, and taking the last
flackr: yeah, i think we make the timeline decision just for simplicity. use-cases for multiple anchors witht eh same name probably apply similarly here, so i'd like to match.
TabAtkins: do we want to try and change the timeline clash behavior as well, to match?
flackr: i'd like to. there's some complexity; right now we just maintain a count, and it's used if there's only one. we'd now track them all and use the last.
TabAtkins: Yeah, i see how it's technically very similar.
flackr: partial loading is an issue. if youre document is partially loading, you might start using one timeline, then have to switch to another when more of the document loads in
flackr: we alreayd have a mechanism for changing the timeline for an animation
TabAtkins: so proposed resolution from flackr is to change timeline clash resolution to use last in tree order
ydaniv: i'm okay if there's no compat issue
flackr: seems even less liekly to be a problem, since it's an error case today
RESOLUTION: change timeline clash resolution to use last in tree order
bramus: so timeline-scope changes to match anchor-scope, limiting the scope of a timeline?
flackr: yes, the cucrrent behavior no longe rmakes sense
TabAtkins: so back to the original issue, when multiple elements declare the same trigger name, david suggests using last in tree order.
TabAtkins: any objections?
RESOLUTION: When multiple elements declare clashing trigger names, the last in tree order wins (matching anchorpos and now timelines)
TabAtkins: for same element, multiple timelines or events with the same name
flackr: we already have this issue in view and scorll timelines, their names are in the same namespace.
DavidA: I think I found that scroll timelines win
TabAtkins: is this specified?
anders: yes; flackr: no
andruud: it was discussed, using scroll timelines was intentional at the time
https://
flackr: ah it is specced
"In case of a name conflict on the same element, names declared later in the naming property (scroll-timeline-name, view-timeline-name) take precedence, and scroll progress timelines take precedence over view progress timelines."
flackr: so i'm not opposed to arbitrarily defining a similar precedence order
flackr: not sure why we decided it this way, tho
DavidA: i think i just considered it invalid and wanted a simple answer
DavidA: if we ahve more triggers, we'll have to define mroe precedence
flackr: i dont' think that's hard. just want consistency
DavidA: i also dont' think we'll have more types of triggers, tbh
DavidA: so my rec in that case is to prefer timeline triggers, they feel a little more specific
flackr: i might go more arbitrary, scroll is alphabetically before view, maybe we match and have event preferred over timeline
flackr: this is an edge case, don't need a strong reason
proposed resolution: if a name is multiple in one property, last wins; if a name is defined by both event and timeline, event wins (because it's alphabetically earlier)
RESOLUTION: if a name is multiple in one property, last wins; if a name is defined by both event and timeline, event wins (because it's alphabetically earlier)
github-bot, end topic
github-bot, take up w3c/
[web-animations-2][css-animations-2] Set of actions for animation triggers
<github-bot> OK, I'll post this discussion to https://
flackr: we've set up our triggers such that a named trigger has some set of associated actions
flackr: UI events, or enter/exit for timelines
flackr: there are, i think, 3 ways to associate them with an animation behavior
flackr: 1) in trigger definition, specify this action has this behavior
flackr: 2) like ydaniv proposed, on the animating element you specify the behavior, and there's something about exit behaviors
flackr: the only way i can make this make sense is that the exit has another behavior in the animation-trigger proeprty
flackr: 3) an explicit syntax, maybe functional, in animation-trigger that links a trigger name to an animation behavior
flackr: i think third is most generic and conceptually simple
flackr: it leave sit so triggers don't mention animations
flackr: and we can do more stuff with triggers in the futre
ydaniv: in option 2 i allowed 2 triggers, was continuing the line tab and elika took
ydaniv: but if we go back to just allowing one trigger, you spec the trigger you want and the behavior
ydaniv: the old pattern of once/repeat/alternate/state
flackr: that behavior has something that happens when the action starts and the action stops, so that's a second thing just for timeline triggers
DavidA: what's maybe not great here is we have to reinterpret bheavior in the event trigger context
flackr: i know stefan has concerns about this as well. option 3 shouldn't be contentious, it's extensible. triggersa re just event sources
DavidA: we'll have to modify the JS interface, so trigger.addAnimation(), you'll also specify the behavior
flackr: yeah, we can modify idl to match once we decide on css
ydaniv: making sure i get this right
ydaniv: with event triggers, you don't ahve action of start/end
ydaniv: so for now we only allow events to play forwards
ydaniv: in option 3 we add a function that ties an event to an action, like play or reverse
animation-trigger: trigger(--trigger-name, <action name>, behavior)
ydaniv: so how do you specify clicking to start and pause or wahtever
flackr: you add two triggers, and we specify that animation-trigger can do multiple triggers
animation-trigger: trigger(--timeline-trigger, enter, play) trigger(--timeline-trigger, exit, pause)
DavidA: i was interpreting option 3 as, if you want multiple event associations, you don't need more than on even ttrigger
flackr: does this example make sense?
ydaniv: but the behavior alway sstarts with playing
flackr: we could default to that, yeah, but it' snot necessarily what you always want
DavidA: yeah, you might want alternate on clicking so it always negates the playback rate
TabAtkins: I found most useful is that the 4 actions are use most times
… we should imply a lot of things
… being able to say what a trigger does in a specific animation phase is useful
flackr: i agree. i think when we define the behavior part, we define that the behavior can depend on the current animation state
flackr: i think "play and restart" can be different from "play but do nothing if it's already playing"
flackr: similarly, "play if paused, reverse if finished"
DavidA: the "once" behavior needs to be covered too
flackr: that can also be based on animation state. "play if paused, do nothing if idle"
DavidA: doesn't this imply some state for the trigger?
flackr: no
DavidA: say you play on click, something else pauses it, then you click again. what should happen?
flackr: i think all of the state should just be animation state
TabAtkins: what would that look like?
… my idea is that we imply couple of behavior keywords the imply these behaviors, but specify a particular phase
TabAtkins: have several behavior keywords that imply behaviors in each phase, but let you also specify a single phase that you're giving a behavior to. then either the trigger() can tka emultiple phase behaviors, or multiple trigger()s can be used, one for each phase
flackr: that's most general, yeah. start with all-phase behaviors, then see if per-phase is needed?
TabAtkins: when me and david explored this, we realized a bunch of keyword variants are needed
TabAtkins: but i think it's okay to start with single keywords defining all four phase behaviors, and see if it explodes and needs per-phase keywords later
DavidA: can we return to the core issue here?
flackr: yeah, i think we've come to an agreement on animation-trigger behavior
DavidA: do we want to make sure we have syntax sapce for multiple triggers on a single animation?
TabAtkins: looks like flackr's syntax is just fine for that, trigger() functions space-seaprated in animation-trigger
flackr: bikeshedding welcome on names, but yeah
ydaniv: another concern, we mentioned timelines being "1d" versus events beign "0d"
ydaniv: do we need an issue to talk about that?
flackr: for 2d stuff, i put in the proposal for a view trigger, it's 2d by default
DavidA: i think he's saying that view-trigger is another trigger type, but pointer-trigger would be yet anohter
flackr: we can define that space, maybe we can combine views and pointers
flackr: timeline trigger is a single dimension
ydaniv: we can bake that in?
DavidA: actually, thinking about intersecting multiple timeslines to make a "2d" version. works for both view and pointer
ydaniv: and sometimes you want intersection, sometimes you want "either" timeline
flackr: for timelines, I think intersection is what matters. "either" timeline is done with multiple triggers
flackr: i'm not opposed to intersection of timelines. need a specific proposal, but seems reasonable.
proposed resolution: syntax TBD, but go with option 3, where animation-trigger takes a trigger(name, behavior) function
[discussion about event type]
flackr: for timeline, there's entering and exiting, each of those have a behavior
ydaniv: not quite. you ahve a view tiemline and two ranges. when you enter you apply one behavior. then you range changes, when you exit.... right, you ahve another behavior
flackr: for events, like trigger(--source, click play)
TabAtkins: ah, i thought event types were listed in event-trigger-*
flackr: initially, but we're moving away from that
TabAtkins: ok, makes sense then
trigger(<dashed-ident>, [<action> <behavior>]#)
ydaniv: so timeline-trigger is still a set of properties, but event-trigger is just a single longhand then
TabAtkins: do we want to resolve on this syntax precisely?
flackr: yeah. we can review later
proposed resolution: timeline-trigger-* and event-trigger just define the source element. on the animating element, `animation-trigger: trigger()#` specifies source element, action, and behavior
proposed resolution: timeline-trigger-* and event-trigger just define the source element. on the animating element, `animation-trigger: trigger()#` specifies source element, action, and behavior. (`[trigger()+ ]#` for multiple triggers on a single animation
RESOLUTION: timeline-trigger-* and event-trigger just define the source element. on the animating element, `animation-trigger: trigger()#` specifies source element, action, and behavior. (`[trigger()+ ]#` for multiple triggers on a single animation
github-bot, end topic