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

@flackr (sorry for the length 🙈 ):

> > we already have all these properties
>
> They are only in an editor's draft spec and not yet implemented by any browsers. Now is the best time to change it if it makes sense to do so. We effectively do not yet have these properties because it has not been implemented.

Yes of course. I specifically responded to what you said about having multiple properties related to animation. As I understood that what you said is having properties like `animation-timeline`, `-range`, and now `-trigger` and having all of these become meaningless if there's no animation.
So I meant we already have these bunch of properties, and changing the syntax of `-trigger` won't change how all of these work, but maybe I misunderstood your point there.

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

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

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

 > > 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 ?) before resolving on this.

-- 
GitHub Notification of comment by ydaniv
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12336#issuecomment-3081094884 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 16 July 2025 21:40:10 UTC