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

The CSS Working Group just discussed `[css-animations-2] Move scroll and event animation triggers to independent namespace`.

<details><summary>The full IRC log of that discussion</summary>
&lt;kbabbitt> DavidA: on the topic of animation triggers<br>
&lt;kbabbitt> ... as mentioned for scroll based triggers we have a list of properties that authors can use to specify conditions<br>
&lt;kbabbitt> ... under which triggering happens<br>
&lt;kbabbitt> ... some work is also being done on different kind of triggers<br>
&lt;kbabbitt> ... based on events<br>
&lt;kbabbitt> ... we're considering that not all properties that apply to scroll based triggers apply to event based triggers and vice-versa<br>
&lt;kbabbitt> ... we're considering change to format of properties we have in spec currently<br>
&lt;kbabbitt> ... currently we have one animation-trigger shorthand<br>
&lt;kbabbitt> ... that specifies set of additional longhands<br>
&lt;kbabbitt> ... they're all done targeting scroll based triggersd<br>
&lt;kbabbitt> ... now that we're considering different type of triggers, we should have a different format where animation trigger property specifies name of trigger<br>
&lt;kbabbitt> ... then different property, in case of scroll based trigger, or timeline trigger<br>
&lt;flackr> q+<br>
&lt;kbabbitt> ... add name for that trigger and animation-trigger property can refer to that dashed ident<br>
&lt;ydaniv> q+<br>
&lt;kbabbitt> ... similar construction for event based triggers<br>
&lt;kbabbitt> ... where event property could be event-trigger or something<br>
&lt;kbabbitt> ... specify event that should trigger the animation<br>
&lt;kbabbitt> ... and a name<br>
&lt;kbabbitt> ... then animation-trigger property can refer to that dashed-ident name<br>
&lt;kbabbitt> ... proposal is to have different namespaces for different types of triggerrs<br>
&lt;Rossen9> q?<br>
&lt;kbabbitt> flackr: this follows the pattern we have for scroll timeline and view timeline where options for those timelines are not animation-* properties<br>
&lt;kbabbitt> ... you set up timeline separately and attach to animation<br>
&lt;kbabbitt> ... this nicely lets us have different sets of properties for different types of triggers<br>
&lt;Rossen9> ack flackr<br>
&lt;Rossen9> ack ydaniv<br>
&lt;kbabbitt> ydaniv: have a strong concern here<br>
&lt;kbabbitt> ... main one is that triggers are not directly associated with elements<br>
&lt;kbabbitt> ... triggers are just objects that contain state<br>
&lt;kbabbitt> ... information about behavior<br>
&lt;kbabbitt> ... then they form a link between animation and another timeline<br>
&lt;kbabbitt> ... link to an element or an event<br>
&lt;kbabbitt> ... themselves they're not directly related to an element<br>
&lt;kbabbitt> ... I think this design is problematic and adds another namespace<br>
&lt;flackr> q+<br>
&lt;kbabbitt> ... for example if you have one element specify animation, another specify timeline<br>
&lt;kbabbitt> ... another specify trigger<br>
&lt;kbabbitt> ... but it's not necessarily the ? element<br>
&lt;Rossen9> ack flackr<br>
&lt;kbabbitt> flackr: like scroll and view timelines<br>
&lt;kbabbitt> ... we can add an element ? trigger construction<br>
&lt;kbabbitt> ... where we use a simple set of parameters<br>
&lt;kbabbitt> ... I think that scoping some named things commonly done in a lot of locations<br>
&lt;kbabbitt> ... even if it's not strictly associated with element<br>
&lt;kbabbitt> ... but also by having the trigger be able to be defined on a different element<br>
&lt;kbabbitt> ... there's more situations where you wouldn't ? timeline for that trigger<br>
&lt;kbabbitt> ... [missed]<br>
&lt;kbabbitt> ... have strong concerns about not doing this<br>
&lt;kbabbitt> ... more situation where you wouldn't need a named scroll timeline or view timeline<br>
&lt;kbabbitt> ... because you could set up trigger on the element<br>
&lt;kbabbitt> ... that you would normally have put the timeline on<br>
&lt;kbabbitt> ... we would be introducing a bunch of animation associated properties<br>
&lt;kbabbitt> ... for things which most of the time would have no meaning<br>
&lt;ydaniv> q+<br>
&lt;kbabbitt> ... for that animation unless you happen to have specific type of trigger to which those properties apply<br>
&lt;Rossen9> ack fantasai<br>
&lt;kbabbitt> fantasai: having a hard time follolwing this conversation because I'm missing context of overall proposal<br>
&lt;kbabbitt> ... not here or in spec<br>
&lt;kbabbitt> ... can we link to spec and get it properly published?<br>
&lt;kbabbitt> ... don't know where change is happening<br>
&lt;kbabbitt> ... because it's not in ED<br>
&lt;kbabbitt> fantasai: is there no draft spec?<br>
&lt;kbabbitt> flackr: this is animations 2<br>
&lt;kbabbitt> flackr: ED of animations-2<br>
&lt;kbabbitt> fantasai: ok<br>
&lt;Rossen9> q?<br>
&lt;flackr> https://drafts.csswg.org/css-animations-2/#animation-triggers<br>
&lt;Rossen9> ack ydaniv<br>
&lt;kbabbitt> ydaniv: re: flackr - regarding concerns, we already have all these properties<br>
&lt;kbabbitt> ... even if we do this, animation-trigger still remains<br>
&lt;kbabbitt> ... will also contain list of properties<br>
&lt;kbabbitt> ... thing also that flackr said, people can use anonymous timeline<br>
&lt;kbabbitt> ... that's true, could simplify most cases<br>
&lt;kbabbitt> ... 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<br>
&lt;kbabbitt> ... which is I think, creates more complex API<br>
&lt;kbabbitt> ... for the author<br>
&lt;flackr> animation-trigger: timeline-trigger(view()) could work for example<br>
&lt;kbabbitt> DavidA: don't have to use another element<br>
&lt;kbabbitt> ydaniv: second point was that, if we do want to put view-timeline property and give it a name on an element<br>
&lt;kbabbitt> ... still need another element inbetween for another property to reference that name<br>
&lt;kbabbitt> ... and make it a reference to declaration of trigger<br>
&lt;kbabbitt> ... still need this extra property<br>
&lt;kbabbitt> ... this makes the API a bit cumbersome<br>
&lt;kbabbitt> ... that's my concern<br>
&lt;kbabbitt> Rossen9: with the number of concerns you're raising here, clarity needed for others, to move this forward I think we need to move this back to github issue<br>
&lt;kbabbitt> ydaniv: I think if more people could chime in and give opinions ... could be just design issue<br>
&lt;kbabbitt> Rossen9: design of feature is most important part<br>
&lt;kbabbitt> ... let's move topic and discussion back to github<br>
&lt;kbabbitt> ... when you're ready for resolution, put it back on agenda<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12336#issuecomment-3079492005 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 17:05:17 UTC