-
Notifications
You must be signed in to change notification settings - Fork 641
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-animations-2] Specify the animation-trigger property #10128
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for getting this started! I think some of the low level details of how an animation trigger affects the animation probably belong in web-animations-1 with the css-animations spec setting properties by which you set up those triggers declaratively. You should also of course be able to set the same properties from the web-animations api.
css-animations-2/Overview.bs
Outdated
An <dfn export>animation trigger</dfn> is used to control the playback | ||
of its associated [=animation=] for time-driven animations. | ||
[=Animation triggers=] follow the same [[web-animations-1#hierarchical|hierarchy]] | ||
as animations and are associated with a [=timeline=] and an [=animation trigger effect|effect=]. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes it sound like animation triggers are separate things from animations, but I suspect we should say that as a part of updating the current time of animations we evaluate whether a trigger condition has been reached and apply a stateful change to the animation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good. I'll work on that
css-animations-2/Overview.bs
Outdated
[=Animation triggers=] follow the same [[web-animations-1#hierarchical|hierarchy]] | ||
as animations and are associated with a [=timeline=] and an [=animation trigger effect|effect=]. | ||
|
||
Issue: Should there be any effect of triggers on scroll-driven animations? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suspect triggers on scroll-driven animations should "just work". E.g. they could play / stop the animation when the trigger condition occurs / finishes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does each type
affects a scroll-driven animation?
Furthermore, what could be the actual use-case for this? Perhaps one that I can think of now is if we have a hover-timeline
in the future and we want to enable/disable it on different scroll positions. Is that what you mean?
css-animations-2/Overview.bs
Outdated
:: | ||
|
||
<dl class=switch> | ||
: If |effect| is inside its [=active interval=], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think defining a trigger in terms of an internal animation effect's time might be overkill. E.g. I think we could define this simply in terms of the animation timeline's time with respect to the specified range
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I struggled with that quite a bit. Eventually it worked out once I defined the same hierarchy as animations', and defined a special state for the effect
. I'll try simplifying this further.
css-animations-2/Overview.bs
Outdated
|
||
Issue: Should there be any effect of triggers on scroll-driven animations? | ||
|
||
## Animation Trigger Effects ## {#trigger-effects} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the internal control of how triggers work probably belongs in web-animations where we define things like how an updated time updates corresponding animations: https://drafts.csswg.org/web-animations-1/#update-animations-and-send-events
We should also be able to set up animation triggers from javascript.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, sure. We didn't discuss the WAAPI part of triggers in the issue, should I try fleshing that too in this PR? Or you're just stating this as a reason for this change?
@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:
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. |
@birtles thanks for reviewing! The intention of the hierarchy was mostly to simplify the spec, by having triggers follow animations as in: 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. |
Makes sense!
Ok, I'll look forward to seeing what you come up with! |
Removed dfn of animation trigger effect
web-animations-1/Overview.bs
Outdated
The [=animation effect=] associated with |trigger| remains in | ||
its [=animation effect/before phase=] and stays at zero [=animation/start time=]. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still don't quite get the hierarchy here. This suggests an animation effect is associated with a trigger but previous we said a trigger is associated with an animation. Which is it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, the relation here should be indirect via the animation. The trigger is associated to the animation. The required behavior of the animation is to "hold its effect in a 'just before playing' state". I'll try to fix that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, I think it's better now.
@ydaniv Sorry for the delay--currently on parental leave. Just a few meta points:
|
Thanks @birtles!
Congrats ^_^!
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.
You mean the DOM interfaces, as in here?
I've added this text to that section:
Shouldn't this cover it? I think basically comes down to checking triggers state on timeline's current time update. |
Thanks!
Yeah, that would be good to know. My understanding is it should be level 2 but maybe @flackr has some ideas about that.
I was thinking about the Web Animations DOM interfaces. Just like we have the 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
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:
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. |
I opened an issue with a rough proposal here.
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?
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.
Agreed. I tried simplifying it on the last change. |
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the delay on the review. Thanks for putting this together!
Canonical order: per grammar | ||
</pre> | ||
|
||
<span class=prod><dfn><single-animation-trigger-type></dfn> = once | repeat | alternate | state</span> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add a description of what each property value means. Also we probably need a none value on this property to represent the default case right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was pondering all the none
/normal
/auto
options, and I think we currently don't need them, since the initial value is once
, with a timeline value of auto
, which I think is exactly what we have today.
We could also add an issue on that, in case it needs an approval from the group.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The definition of the values is done here.
Should I add here another description? More user/less implementor facing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was pondering all the none/normal/auto options, and I think we currently don't need them, since the initial value is once, with a timeline value of auto, which I think is exactly what we have today.
Yeah, I like having the default values basically explain the triggering behavior we get today and adding the ability to modify it. It makes it feel like less of an added on property and more just part of the standard animation infrastructure.
We could also add an issue on that, in case it needs an approval from the group.
I think this can be part of the general review when it's all written up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add a description of what each property value means.
Done
Animation Type: not animatable | ||
</pre> | ||
|
||
Issue: Probably a trigger with timeline "none" is under-specified here. Need to clarify what it means. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if the default timeline is the document timeline set up in a way such that the "trigger" is always active explaining the normal behavior of animations? You could imagine then using this as a way to coordinate starting an animation after some length of time, e.g. animation-trigger-range: 10s
. Admittedly this has some overlap with animation-delay, but unlike animation delay could use absolute times since page load or other events I suppose?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, I remember we considered this in a previous issue specifically on syncing animations, but we said there that this will be the stuff that will eventually be done via GroupEffects. That said, if you see some way of changing the definition here and keeping this more open for later extensions I'm all for it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but unlike animation delay could use absolute times since page load or other events I suppose?
I feel like we'll still the pseudo-selector you suggested in #8175, for example, to defer until DOM and assets are loaded. This is pretty common.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should remove the none state, I'm not sure what it even means and the initial value is auto so it's not clear what you'd use none for. With the initial value auto, as you've said it has the same meaning as values of animation-timeline and as such would map to the document timeline. I think we should try to go with this model as it explains the existing behavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, but none
here is part of the single-animation-timeline
syntax. Should we remove it just here? Or entirely?
form a [=coordinating list property group=] | ||
with 'animation-name' as the [=coordinating list base property=] | ||
and each item in the [=coordinated value list=] | ||
defining the properties of a single animation trigger. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this spec doesn't explain how they work but only mentions the relevant properties, it should point to the section in the web-animations-2 spec which explains what animation triggers are and how they work. E.g. this could be as simple as having "animation triggers" link to the section in web animations, similar to how the animation composition property points to the web-animations definition of what a composite operation is.
That said, it's not uncommon to have a plain English explanation for what it means with the details and algorithms left to web-animations. E.g. to take a random property the definition of animation-fill-mode explains what it does without going into the specific algorithmic details that are in the web-animations spec.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like both. I guess I'll refactor the text a bit and add a link.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
web-animations-1/Overview.bs
Outdated
@@ -772,6 +772,9 @@ Animation Frames {#animation-frame-loop} | |||
* Updating the [=animation/current time=] of any [=animations=] | |||
[=associated with a timeline|associated with=] the timeline. | |||
|
|||
* Updating the [=animation trigger state=] of any [=animation trigger=] | |||
[=associated with a timeline|associated with=] the timeline. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can move to web-animations-2 right? Also I think this needs to happen before updating the times of animations so that we can set their start time and know to make their effects active if they've been triggered.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well the animation-frame-loop
definition exists only here, and I had to only add this one bullet. So what would be the proper way to add it to web-animations-2? Should I add just this delta somehow? Another way?
Regarding order, yes, I'll pull it up to happen before updating animations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, we'd add a delta for this section to the ewb-animations-2 spec.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
<dl class=switch> | ||
: If |trigger|’s [=local time=] is [=unresolved=], | ||
:: | ||
Then |state| is ''animation trigger state/idle'', and |did trigger| is set to false. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't setting did trigger
to false this reset once
triggers anytime the timeline goes idle (e.g. anytime a ScrollTimeline's scroller becomes large enough that it doesn't scroll)? I think this is probably unexpected.
Note, it doesn't look like these links, e.g. ''animation trigger state/idle''
have linked to the definitions correctly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting! I'm not sure whether this is unexpected. I guess we should open another issue for that.
Regarding the links, I'll check and fix.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't setting did trigger to false this reset once triggers anytime the timeline goes idle (e.g. anytime a ScrollTimeline's scroller becomes large enough that it doesn't scroll)? I think this is probably unexpected.
Gave this another thought. I think this should be expected, but definitely worth opening an issue and discuss this explicitly.
Note, it doesn't look like these links, e.g. ''animation trigger state/idle'' have linked to the definitions correctly.
Right, appears as though these aren't linked correctly, but I used the suggested syntax, so not sure what to do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On re-reading this, I realized the did trigger
flag actually says nothing about whether it will retrigger once
animations, and the text the definition for once
says:
The animation is triggered and played once and only once.
Which implies that once animations are not retriggered by this, which I think addresses my primary concern.
I was thinking about whether resizing the scroller / browser such that the area is no longer scrollable should be treated differently than exiting the exit range? My thinking is it shouldn't be any different. You by definition can't be in the exit range. With this in mind I'm not exactly sure what did trigger is trying to accomplish other than perhaps giving different behavior to being outside the active range to start, and going inactive. If this is the case, I think we should just consider the previous state rather than introduce this did trigger variable. E.g. if you're outside the active range and you have no previous state or your previous state was idle, you're still idle.
|
||
### Animation Trigger Ranges ### {#trigger-ranges} | ||
|
||
An [=animation trigger=] has at least one [=animation attachment range|range=], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should define a new term for the trigger interval's active range, as the combination of the two ranges would probably be worth eventually having a diagram to illustrate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good, I'll try adding that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
|
||
The ''inverse'' behavior is [=reverse an animation|reversing=] the associated animation. | ||
|
||
<dt><dfn>state</dfn> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if something like play-pause would be clearer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's another option. The idea behind state
was a reference to play-state
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, I could see play-state as an alternative. State feels too strange, I didn't have any idea what this meant until I read the description :-).
Moved the delta of animation-frame-loop from web-animations-1 to web-animations-2
@flackr finished addressing all comments from last review |
@flackr kind ping, in case you missed this, I think it's ready for another round 🙏 |
Animation Type: not animatable | ||
</pre> | ||
|
||
Issue: Probably a trigger with timeline "none" is under-specified here. Need to clarify what it means. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should remove the none state, I'm not sure what it even means and the initial value is auto so it's not clear what you'd use none for. With the initial value auto, as you've said it has the same meaning as values of animation-timeline and as such would map to the document timeline. I think we should try to go with this model as it explains the existing behavior.
<h3 id="animation-frame-loop">Animation frames</h3> | ||
|
||
This section extends the definition of the [=update animations and send events=] | ||
procedure to include the following extra step: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not quite clear from this exactly what is the extra step. I think what you are proposing is that the note associated with the first step has the additional implication?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think so. The intent is to add the additional task to this step as the first task.
How can I improve the text? Is there an example I can follow?
|
||
The [=animation trigger state=] |state| of an [=animation trigger=] |trigger| | ||
is controlled by the [=animation attachment range|attachment range=] it is attached to, | ||
given a flag |did trigger|, as follows: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you need to say something about how when the current time of the trigger timeline is changed, we run the following steps. We also need to say how did trigger is stored, it's probably state associated with the animation trigger? E.g. if i assign a new trigger to an animation i probably want to reset the animation trigger.
<dl class=switch> | ||
: If |trigger|’s [=local time=] is [=unresolved=], | ||
:: | ||
Then |state| is ''animation trigger state/idle'', and |did trigger| is set to false. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On re-reading this, I realized the did trigger
flag actually says nothing about whether it will retrigger once
animations, and the text the definition for once
says:
The animation is triggered and played once and only once.
Which implies that once animations are not retriggered by this, which I think addresses my primary concern.
I was thinking about whether resizing the scroller / browser such that the area is no longer scrollable should be treated differently than exiting the exit range? My thinking is it shouldn't be any different. You by definition can't be in the exit range. With this in mind I'm not exactly sure what did trigger is trying to accomplish other than perhaps giving different behavior to being outside the active range to start, and going inactive. If this is the case, I think we should just consider the previous state rather than introduce this did trigger variable. E.g. if you're outside the active range and you have no previous state or your previous state was idle, you're still idle.
|
||
<dt><dfn>state</dfn> | ||
<dd> | ||
The ''primary'' behavior is [=play an animation|triggering or resuming=] the associated animation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be more consistent if state only changes the animation play state, i.e. the animation would be started in a paused state until the active trigger range is entered.
|
||
<dt><dfn>primary</dfn> | ||
<dd> | ||
The ''primary'' effect defined by |type| is applied to |animation|. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a bit of a mismatch between this and the text in css-animations-2 where the text for single-animation-trigger-type specifies when the effect is applied. The text above implies that the effect is applied continually while in the state, but the text in single-animation-trigger-type implies that the effect is applied at a discrete moment in time. If all of the effects are discrete then I think it would be simpler to have the effect explicitly only invoked when the trigger's state changes.
the [=animation trigger/active interval|active interval=] of an [=animation trigger=] |trigger| as follows: | ||
|
||
<dl class=switch> | ||
: If |trigger| is inside its [=animation trigger/active interval|active interval=], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be based on the trigger state I think. Otherwise if you're in the exit range but not in the default range then this condition would be false.
[=Animation triggers=] define an <dfn for="animation trigger">active interval</dfn>, | ||
which is the period of time during which the trigger is scheduled to produce its effect | ||
on its associated [=animation=]’s playback. | ||
Each [=animation trigger=] has only one such interval, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is super confusing, having one interval and then referring to two ranges. I think we should say that the active interval is determined by its most recent state.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I've rephrased the text to be more elaborate and explicit regarding dependency on state
<dl dfn-type=value dfn-for='animation trigger type'> | ||
<dt><dfn>once</dfn> | ||
<dd> | ||
The ''primary'' behavior is [=play an animation|triggering=] the associated animation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this needs to define how the behavior is only applied once. E.g. the suggested triggered state associated with an animation, initially false
Adding initial draft for Animation Triggers and the
animation-trigger
property as resolved in #8942 (comment).I cleared all the issues and fleshed out the gist of it.
cc @flackr @birtles @dbaron