- From: Yehonatan Daniv via GitHub <noreply@w3.org>
- Date: Sun, 17 Aug 2025 09:06:51 +0000
- To: public-css-archive@w3.org
@tabatkins: > I definitely see the draw in making everything consistent in a single "everything is an event" model, but I think there's value in keeping common things simpler, and I think the view/scroll timelines having a somewhat specialized syntax is worthwhile. The vast majority of the time when you're using a view/scroll timeline, you want it to play/stop based on entering/exitting a chunk of the timeline. Yes, definitely! I think the view use-case is super important to get right and easy to use. > If we put all the "configuration" options on the element defining the trigger (rather than the one running the animation), then it works out nicely to have timeline and events using a different set of properties. Ideally we authors shouldn't need to declare the trigger separately on an element, or otherwise, if the timeline is anonymous on the element defining the trigger. > (I don't disagree that it might make sense to expose viewenter/viewleave as events as well, but in the common case I think we shouldn't force authors to have to think about the event model just to play an animation while an element is on screen.) Sure, I'm just also concerned with the fact that timeline is 1D and enter/leave triggering is 2D in nature. -- GitHub Notification of comment by ydaniv Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12336#issuecomment-3194246281 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Sunday, 17 August 2025 09:06:52 UTC