- From: Robert Flack via GitHub <sysbot+gh@w3.org>
- Date: Sat, 24 Jun 2023 01:42:53 +0000
- To: public-css-archive@w3.org
> Yes, these 2 options sound option 2 I mentioned above. My apologies, I missed that this was the behavior you proposed for it. I still worry this isn't well described by the paused `animation-play-state` as it suggests option 1 based on what changing play state to paused usually does. Also when you haven't triggered the animation yet I think it should be in the before phase (as if you had a delay you haven't hit yet), rather than paused at the start and should probably hold the after phase after it finishes. This lets the developer decide whether it should fill or not. > 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"? If you think of this as similar to animation-delay, the animation is just "running" the whole time but it's in the before phase until triggered (i.e. only producing an effect if you have `fill: backwards`). If you set it to paused the animation would I suppose start paused when the trigger is passed holding the first keyframe until you unpause it. > I'm not sure we need the a point on a timeline. The time-based one is simply a delay, right? When given a document timeline yes. I was thinking in the long run you might pass it a point on a (yet to be defined) video timeline or other such time-based triggers which are not simple delays. > 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? There are a few ways that a single point could be interpreted. - Whenever you go from one side of the given point to the other you trigger the animation. - Whenever you have a "time" >= the trigger point, trigger the animation. - Whenever you pass the trigger point in a particular direction, trigger the animation. We could imply all of these options from the proposed `once | repeat | alternate`. E.g. alternate implies the animation happens every time you cross in the direction you crossed in, and maybe the other two can decide which direction they care about - or maybe they care about the direction determined by the `animation-direction`? It sounds like you're suggesting though that you might want an upper limit, such as trigger a particular animation anytime you scroll between 500px and 1000px (such that a particular element is intersecting the viewport). I think in order to avoid timing issues you'd probably want to trigger even if the user scrolled past the range without ever entering it just so that you'd be in a consistent state regardless of scroll speed. I'm a bit worried this could get into an arbitrarily complex syntax space for multiple triggers, repeating triggers etc, however maybe a range based trigger always plays forward when you enter the range and plays backwards when you leave it and if you don't want one of the directional trigger points it is conceptually infinite / the start or end of the range. -- GitHub Notification of comment by flackr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8942#issuecomment-1605228351 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 24 June 2023 01:42:58 UTC