- From: Tab Atkins Jr. via GitHub <noreply@w3.org>
- Date: Mon, 28 Jul 2025 22:20:58 +0000
- To: public-css-archive@w3.org
Me and @DavMila chatted about this privately. I'll answer a few bits based on that conversation. > Could you give a brief example of this? It would help me better understand, thanks. It looks like this was a miscommunication. We (Elika and I) thought that *y'all* were saying there was a necessary statefulness in the API, such that every start trigger had to be accompanied with its paired end trigger for the actions to make sense, and vice versa. It seems like this wasn't the case, it was just both of us talking past each other. @szager-chromium's comment seems to support this as well; the only "statefulness" is that the Animation object tracks some state and the trigger *actions* interact with that, but the *triggers* don't care about that and are stateless. (Especially if we do end up requiring/enforcing that the "continue range" is a superset of the "start range" for a timeline/view trigger.) This is great, it makes a lot of things a lot simpler to deal with, then. > [suggestions for tweaks to the start/end actions] In our discussion David suggested making these even more granular and specific, which I think is generally a good idea, so the names don't require quite as much explanation to understand. Like, `play-forwards`, `play-reverse`, `play-alternate`, `pause`, `reset`, etc. This'll still require some careful design to make sure the keywords satisfy good use-cases, but I think it's the right approach. The big complication, I think, is that animations can be in four states (never played, playing, paused, or done playing), and the behaviors need to be well-defined for all four states. Dunno how much control this needs. In any case, tho, I think it's good design to define them with a table of their behaviors in each of the four states. Here's some suggestions for the matrix, based on David's ideas and expanded a little <table> <thead><th>Keyword<th>Initial<th>Playing<th>Paused<th>Finished</thead> <tr><th>`play-forwards`<td>Set playback rate positive, play()<td>Set playback rate positive<td>(same as initial)<td>(same as initial) <tr><th>`play-backwards`<td>Set playback rate negative, play()<td>Set playback rate negative<td>(same as initial)<td>(same as initial) <tr><th>`play-alternate`<td>play()<td>Negates playback rate<td>play()<td>Negates playback rate, play() <tr><th>`pause`<td>Nothing<td>pause()<td>nothing?<td>nothing <tr><th>`play-pause`<td>play()<td>pause()<td>play()<td>play() <tr><th>`reset`<td>nothing<td>set progress to 0<td>(same as playing)<td>(same as playing) <tr><th>`restart`<td>play()<td>set progress to 0<td>set progress to 0, play()<td>set progress to 0, play() </table> Another possibility is that we let these four behaviors be set individually in some way. Maybe not all of them; maybe it's just playing/paused behavior that we need to separate out? But I'd like to avoid that if possible, just for understandability. I suspect we can do fine with a good set of keywords that package up useful behaviors, like above. Any others we might need? Any use-cases not covered by the above, or alternately do some of the suggested keywords above give behavior we *don't* think is useful to support? -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12336#issuecomment-3130028269 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 28 July 2025 22:20:58 UTC