- From: Yehonatan Daniv via GitHub <noreply@w3.org>
- Date: Mon, 01 Sep 2025 11:19:10 +0000
- To: public-css-archive@w3.org
> With any of the approaches where we specify the enter and exit range on a named view timeline and then reference those events for that timeline, we can ensure that these events are paired for that timeline. If a developer chooses not to use those paired events that is fine, but at least we have made it easy to do the right thing. Ok, I recall now, thanks (: So this isn't a hard constraint, right? More of a way to simplify using timelines? > > So if I understand this correctly, unless we solve multiple timelines' enter/leave events, we have to restrict triggers to either being a single timeline trigger > > The reason viewenter / viewleave made this difficult is if the developer specifies different ranges, viewleave could fire without ever firing viewenter, or viewenter could fire twice without firing viewleave. The intention of having a different leave range was to only get another enter effect if you fully leave the exit area. I don't think, however, that this is a problem. Theoretically this should be just fine, if that is what the author intended. These events could be used just like any events. > We decided to split these into animation-specific actions specifically because event triggers are not paired, and so breaking the inverting part of the behaviors into actions allows for doing the same things with either event triggers or timeline triggers. It's not about pairing of events, it's about the paired nature of animation triggers' behavior. At least that's how I see most usage of triggers, as having paired behaviors. I think for this feature it's much more important for authors to be able to easily perform the OOTB 80% use-cases, than to have a lower level API layer. We already have these behaviors in #12611, just under different names. > I think we've covered this previously, and as discussed at tpac, these behaviors can be achieved by having animation [play state](https://www.w3.org/TR/web-animations-1/#play-states) dependent actions: > > 1. `once` can be implemented with a play-once action that will only play the animation if it is paused. > 2. `repeat` is a play action that plays the animation if it is paused or finished, and a corresponding reset or finish action on exit to immediately finish the animation. > 3. `alternate` is a play-reversed action that will play the animation if it is in the paused state, and reverse it if it is finished. > 4. `state` is a play action on entry, and a pause action on exit. We could do that. I was more leaning towards starting out with a more simple and easy to use, less error prone, less verbose syntax. -------------- If we still consider the option 1 proposed above, there are still some valid concerns I've raised which I think are still not addressed: 1. It doesn't make sense to have to declare __2__ idents in order to bind an animation to an event trigger, as in `trigger(--foo, --bar play)`. If the action was global, as in declared via an at-rule, then it would make sense, but this is not the case, and both are scoped to same element. It should be enough to declare a name and a list of of event types, and bind that to a behavior. 2. It doesn't make sense to have to declare a specific `enter` and `exit` behavior on a `timeline-trigger`. If we we're already exposing this property as a very specific thing, it should be obvious it has an entry/exit events. This property should be as simple as specifying a name, a timeline, and ranges. And binding it on the animation with an action should just as simple as the case with events. TL;DR if we do go with option 1 I still think there are some adjustments we need to to to the proposed syntax. I have my proposal above, which is closer to option 2, but maybe we want some mixture of the two? -- GitHub Notification of comment by ydaniv Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12652#issuecomment-3241983614 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 1 September 2025 11:19:11 UTC