- From: Yehonatan Daniv via GitHub <noreply@w3.org>
- Date: Sat, 16 Aug 2025 15:48:42 +0000
- To: public-css-archive@w3.org
@flackr: > Timelines are not stateful. At a given scroll position they produce a single time value. Triggers (and intersection observer) are the things that are inherently stateful. When the timeline or position changes from one value to another they cause events. Events are also not inherently stateful though change events could be argued to be stateful. Yes, 100%. I'm specifically following the path that @fantasai and @tabatkins took [here](https://github.com/w3c/csswg-drafts/issues/12336#issuecomment-3099669179): > > 1. Currently triggers, mostly relevant to timeline triggers, contain the state of the effect they apply on the animation's playback. With separate triggers used for start/end, where does that state lives? Or perhaps this design makes them stateless? > > Yes, this makes them stateless. An animation that was started by a timeline trigger can be ended by an event trigger; etc. Each trigger's start and end criteria are defined independently of each other: a timeline trigger starts when you switch from being outside the start range to inside, and ends when you switch from being inside the continue range to outside; similar for event triggers. > The reason that I think event triggers and whatever we define for view or intersection triggering need to be different is that view triggers require a stateful memory of what their last position was and when to update that memory. Additionally, when adding a new animation even if there was no discrete change event we still want to put that animation in the correct state for where you are right now. Yes, agreed. Does that mean that _at this stage_ we want to completely avoid mixing view and event triggers completely? Meaning, we can only pair view entry/exit, and not view entry with other events? > Also, as @szager-chromium mentioned, other events while they might sound like they are always paired are not. Yes, of course. I already agreed with that a couple of times (: My examples were just to show usage with the suggested view events and with explicit usage, without resorting to "magic-pairing" of such sort. > One thing I'm not sure I understand is how we ensure that an animation plays if you're already in view to start with Like web both said above, that state needs to be maintained internally. I was thinking this internal place could still be external to the trigger itself. So if you're already in, that should still fire the event, according that internal state that tracks the timeline. > what happens if your ranges overlap, e.g. `event-trigger: --source-play viewenter(0.8), --source-flip viewleave(0.2);` We definitely want to overlap, as should default and exit ranges overlap - which I think we already resolved on? Though maybe that is trickier to assert if we separate the timeline into events? I'd think it wouldn't. > Also, this suggests that the currently active state is per animation, but then this would mean that two animations using the same animation-trigger could end up in a different state depending on when the trigger was added to each right? No, I don't think so, I think my answer above explains why it's not. Though, if we separated the elements for the start and end triggers, we could create partially, or even non, overlapping ranges. That perhaps could be problematic? > Part of the reasoning is that as we have more timeline types there are many cases where passing points on a timeline could be valuable to result in triggers. I'm worried that while we overlooked the fact that timelines are one-dimensional, which we managed to ignore so far since webpages are rarely scrolled in 2D, this won't be so easy to overlook with pointer timelines. I.e. trigger if your pointer crosses a point in Y axis, but is not really on top of an element on the X axis. So you're more likely to simply choose `pointerleave` and `pointerenter`. > TLDR, while there's some value to associating with timelines (extends to future defined timelines), the whole concept requires additional details that plain events do not around what causes them to happen, and has additional properties to control when that internal state changes, which generates the corresponding event pairs. So, do you suggest we _should_ try to start with creating a pair-like API to work around the state-related issues? -- GitHub Notification of comment by ydaniv Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12336#issuecomment-3193749413 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 16 August 2025 15:48:44 UTC