Re: [csswg-drafts] [css-animations-2] Move scroll and event animation triggers to independent namespace (#12336)

> > 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.
> 

I understand the motivation behind saying that triggers are not directly associated with elements, but I think that might not really be true as a consequence of our [decision](https://github.com/w3c/csswg-drafts/issues/12119#issuecomment-2985057242) that triggers are a separate entity from animations. I think triggers actually have their identity more closely linked with the element providing the timeline (or events in the case of event-based triggers) than with the animation they happen to be attached to at any point in time. A trigger with a different underlying element  is simply not the same trigger. The same trigger may be attached to a different animation. The same trigger may be attached to multiple animations (though we haven't settled on [what to call that method](https://github.com/w3c/csswg-drafts/issues/12397)). Without independent namespaces, I don't think you can do this is in CSS, even though you can do it in JS, which speaks to a concern you had about divergent JS and CSS capabilities on the issue about multiple triggers per animation.


... which brings me to the other thing about our proposal: even though we might not spec having multiple triggers per-animation for the moment, independent namespaces gives us an easy and natural way to do that in the future, ie space-separated lists of named triggers, e.g:

```
.content1 {
  timeline-trigger: --trigger1 view() alternate;
}
.content2 {
  timeline-trigger: --trigger2 view() alternate;
}
.animatable {
  animation: glow;
  animation-trigger: --trigger1 --trigger2;
}
```

> > > but still there's an option we want to have timeline used on specific elements, give it a name, you still have to use yet another element
> > 
> > 
> > For event timelines it is also useful to have a distinct associated element. When you don't need this an anonymous trigger might do, similar to view or scroll timelines, e.g. animation-trigger: timeline(once view())
> 
> Yeah sure, we can use functional notations, and that may improve the syntax for most cases. I meant there that if an author does need to declare a timeline, they will still need yet another property in the middle, though your suggestion here is to mitigate that with another function could help with that like: `animation-trigger: timeline(once --my-view-tl)`, correct?
> 
> > > still need another element inbetween for another property to reference that name
> > 
> > 
> > Can you explain this? You can set up and use a trigger on the same element easily, and also use it for multiple animations in the coordinated animation list if needed.
> 
> I think this question is still on the same issue, so my concern is with this case:
> 
> .timeline {
>   view-timeline: --tl;
> }
> 
> .trigger {
>   trigger-timeline: --trigger alternate --tl contain / cover;
> }
> 
> .time {
>   animation: anim 1s;
>   animation-trigger: --trigger;
> }
> 
> .scroll {
>   animation: parallax auto linear both;
>   animation-timeline: --tl;
> }
> You can see the user chose to declare the timeline for reuse, but then had to still use that element-in-the-middle. And again, that element has no purpose in this scene, other than allowing to declare the trigger. I hope this explains it.
> 

But the author wouldn't *have* to use the element-in-the-middle. I would change your example by eliminating the `.trigger ` class and modifying the `.time` class:

```
.time {
  animation: anim 1s;
  animation-trigger: --trigger;
  timeline-trigger: --trigger alternate --tl contain /cover;
}
```
alternatively, you could declare the `timeline-trigger` on the `.timeline` class - so there are multiple ways to do it without introducing an intermediate element, so that doesn't seem like much of a concern to me.

> > > still need this extra property
> > 
> > 
> > Does having an anonymous trigger construction not alleviate this?
> 
> Well, when you propose now an anonymous trigger construction that may as well alleviate the issue you can avoid the element in the middle, and either use the reusable timeline declaration, or make the trigger declaration reusable, using an anonymous timeline. I can compromise on that. I can see how that solves the duality issue with `animation-trigger` while keeping the API spread on 2 elements for most of the cases. Though I'd appreciate another opinion ([@fantasai](https://github.com/fantasai) ?) before resolving on this.

I showed above that you don't even need an anonymous timeline to avoid the element in the middle so I think that concern is pretty much addressed?


-- 
GitHub Notification of comment by DavMila
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12336#issuecomment-3083885110 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:29:30 UTC