- From: David A via GitHub <noreply@w3.org>
- Date: Fri, 20 Jun 2025 17:18:21 +0000
- To: public-css-archive@w3.org
> What I objected to is removing the entire `animation-trigger` declaration into a separate no property, since I think that will only complicate the API and won't add any additional ability we don't currently have. I don't think having separate namespaces for timeline- and event- based triggers necessarily overcomplicates things - it's essentially keying off of the basic idea of dashed idents, which is already a familiar concept to authors e.g. anchor-position-name, view-timeline-name, counter-reset. It seems like a cleaner way to organize the properties so we don't have a longhand (animation-trigger-event or animation-trigger-timeline) which may or may not be relevant to the trigger. I'm not sure if there is precedent for setting one longhand property because another one is set, but that seems like something we should avoid if we can? Without doing that, we have to arbitrarily decide whether animation-trigger-event takes precedence over animation-trigger-timeline when both are set. There may be two issues we can separate here: - separate namespaces for timeline- and event- based triggers, - name scoping With your suggestion of `trigger-event`, I would be inclined to have a more comprehensively defined `event-trigger` which defines and names an event-based trigger that can be referred to from elsewhere than to have a more limited `trigger-event` property which is referred to by an `animation-trigger-event` property which isn't quite so.. (for lack of a better term) flush with other animation-trigger longhands. Perhaps your objection is more strongly towards the second (name scoping) than the first? Overall I'm imagining the following heirarchy of properties (whose names we can certainly improve :) ): - animation-trigger-scope - animation-trigger - animation-trigger-name - animation-trigger-behavior - timeline-trigger - timeline-trigger-name - timeline-trigger-timeline - timeline-trigger-range-start - timeline-trigger-range-end - timeline-trigger-exit-range-start - timeline-trigger-exit-range-end - event-trigger - event-trigger-name - event-trigger-type So you could have: ```CSS #scope { animation-trigger-scope: –scrolltrigger, –clicktrigger; } #scrollsubject { timeline-trigger: –scrolltrigger view() contain 0% contain 100%; } #clicksubject { event-trigger: –clicktrigger event(click); } #scrolltarget { animation: …; animation-trigger: alternate –scrolltrigger; } #clicktarget { animation: …; animation-trigger: repeat –clicktrigger; } ``` and in HTML: ```HTML <div id=“scope”> <div id=“scroller”> <div id=“scrollsubject”></div> </div> <div id=“scrolltarget”></div> … <div id=“clicksubject”></div> <div id=“clicktarget”></div> </div> ``` One point that might be worth highlighting in this scheme is how an author could write the following: ```CSS #a { view-timeline-name: --mytl; } #b { timeline-trigger: --mytr --mytl; } #c { animation-trigger: --mytr repeat; } ``` In which case, if element `b` disappears, then so does the trigger. I don't think this is much of a problem; it just doesn't seem like it would be useful. On `animation-trigger-scope`, we could probably file a separate issue on whether to have this property and scope animation-trigger-names similar to view-timelines & timeline-scope or whether the names should be implicitly global. -- GitHub Notification of comment by DavMila Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12336#issuecomment-2992321362 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 20 June 2025 17:18:23 UTC