- From: David A via GitHub <noreply@w3.org>
- Date: Thu, 17 Jul 2025 12:46:11 +0000
- To: public-css-archive@w3.org
> > > even if we do this, animation-trigger still remains > > > > > > animation-trigger is analogous to animation-timeline. When set it sets the associated trigger of the respective coordinated animation. I think that all of the arguments against doing this could also have been made of scroll and view timelines. We could have added animation-timeline-range-start, animation-timeline-range-end, animation-timeline-axis, animation-timeline-inset etc. However, we decided to set up timelines separately. > > This was in regarded to my point above, that moving the sub-properties of `animation-trigger` still leaves us with that property. Regarding the analogy to `animation-timeline`, there are some distinctions to be made between the two. Firstly, timelines are directly associated to elements, unlike triggers. It's true, we could have made `-range` a longhand of `-timeline`, I actually tried writing that myself by mistake once 😵💫 . And that's because defining a timeline and ranges for an animation are done per animation, on the target, unlike `-inset` and `-axis` which are properties of the timeline, and are defined on the timeline's subject. So we should keep that distinction clear in triggers' case as well. > Regarding the comparison to `-inset` and `-axis` being properties of the timeline and not the animation or target. The trigger's properties are also simply that: properties of the trigger and not the animation/target, highlighting again that the trigger's identity is defined more by the underlying element than by which animation it may be attached to. -- GitHub Notification of comment by DavMila Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12336#issuecomment-3083940420 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 17 July 2025 12:46:12 UTC