Re: [csswg-drafts] [css-animations] Extend animation-play-state for triggering animations when an element is in viewport (#8942)

@flackr 

> We should think about whether there are any ways we could set this up for transitions as well. E.g. maybe for transitions we could do something similar to @starting-style but associate it with a particular trigger point. Then to composite the transition this style information and the trigger would be passed along to the compositor.

Transitions, unlike animations, can't use the trigger in a property/value since they are triggered by the cascade itself. Having excluded the option for having a trigger as a selector, I think the only option still being discussed now is using state queries for that in #6402. I think that direction may also prove useful for the more advanced use-case for animations, when you want to separate the triggering element from the animated element.

> I don't think it's a good idea to re-use animation-play-state for this as you don't want the animation to pause if you scroll past the trigger point and then back before it. Instead you want one of two behaviors:
>
> - Play to completion, or
> - If the animation would trigger in reverse at this scroll threshold, start reversing the animation.

Yes, these 2 options sound option 2 I mentioned above.

The main problem I see with introducing a new property and not extending `animation-play-state` is how will they interact with each other? What does having a trigger _and_ having a play-state of either `running` or `paused` mean?
Will `paused` mean "ignore the trigger and stay paused"? And `running` is "play when defined or when triggered"?

>  trigger could be a point on an animation timeline which could be time-based or could be scroll based

I'm not sure we need the a point on a timeline. The time-based one is simply a delay, right? And the scroll-based one may be confusing, because what you probably want is a simply intersection, no matter which direction or point on the view-timeline the element is at. E.g: what happens with `view(), entry 100%` if the page was navigated to in mid-scroll and then user scrolled to reveal the element from the scrollport's start edge? Does it really matter?

I guess if we add something like `view(), in 100%` and `view(), out 100%` we could cover all cases.

> ```<once | repeat | alternate>```

I really like this part! Kind of binds together all the use-cases (: 

-- 
GitHub Notification of comment by ydaniv
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8942#issuecomment-1605080484 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 23 June 2023 22:48:45 UTC