[csswg-drafts] [css-animations-2] Should skipped trigger/exit ranges affect playback? (#11599)

DavMila has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-animations-2] Should skipped trigger/exit ranges affect playback? ==
In discussing the [proposal](https://github.com/w3c/csswg-drafts/issues/8942) for `animation-trigger`, it was [pointed out](https://github.com/w3c/csswg-drafts/issues/8942#issuecomment-1720916785) that when jumping over (e.g. via scrolling to a url hash fragment) a trigger range an author might not want the animation (which would be played by entering that range) to be played in some cases and in other cases they might want it to be played. How can we accommodate both scenarios?

The current plan is that the ranges will have no effect when they are skipped over. For `repeat` and `alternate` triggers I think this makes sense. But for `once` triggers I think authors might expect that skipping over the trigger range would still have triggered the animation in some scenarios.

I can think of a few ways to accommodate this "trigger-on-skip" expectation:

1. introduce a new keyword `once-in-range` which will correspond to the current plan of having no effect if skipped over; `once` will trigger the animation even when the trigger range is skipped over.
2. introduce a new `<range-skip-behavior>` parameter to the property, which can take values `ignore` (meaning don't trigger if the range was wholly skipped) and `respond` (skipping over the range triggers the animation).

My preference would be for option 1 as it only introduces a new option to an existing parameter (`<type>`) and the behavior unique to the new option is clear. Option 2 adds a new parameter to an already somewhat verbose property and will also necessitate an `animation-trigger-range-skip-behavior` CSS property.
(Of course we can come up with better names in either path.)

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11599 using your GitHub account


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

Received on Wednesday, 29 January 2025 18:32:28 UTC