Re: [csswg-drafts] [scroll-animations-1] What's the point of animation-range? (#7901)

So to summarize, think there's roughly 3 options to keep these properties cleanly separated:

Option 1: (hinted at by my previous comment)
1. `animation-delay` accepts `<animation-delay-start> <animation-delay-end>` but not `<timeline-range-name>`. As currently specified, if only start is specified end is treated as 0 (time delay) / 100%.
2. `animation-range` accepts only `<timeline-range-name>`, expanding it to `animation-delay: <timeline-range-name> 0% <timeline-range-name> 100%`
Each property has a specific unique use case, and we maintain the backwards compatibility with the current `animation-delay` being only `animation-delay-start`. There would be no shorthand for animating from the start of one range to the end of another. We would continue to have the slight awkwardness where ranges don't feel like delays.

Option 2.a: (proposed above by @fantasai)
1. `animation-delay` is equivalent to `animation-range-start` for compatibility.
2. `animation-range` is roughly [as specified](https://www.w3.org/TR/scroll-animations-1/#named-range-animation-declaration) except expanding to `[<animation-range-start> <animation-range-end> | <timeline-range-name>]#`. Specifying 
Animation-delay is effectively a legacy property name. As a new property we could have symmetry with both a time value or range name implicitly applying to both range-start and range-end. `animation-range-end` with a time value is somewhat confusing (if mapped directly to end delay) as it not the time at which the animation ends but the delay after the end of the effect to the end of the animation.

Option 2.b:
* Option 2, but treat `animation-range-end` as an absolute time value from the beginning. This doesn't map cleanly to `endDelay` in [web-animations-1](https://www.w3.org/TR/web-animations-1/#the-effecttiming-dictionaries) and we would  probably have to convert this to `duration` (if duration was auto) and the relative `endDelay` (if duration was non-auto)
This would likely be closer to what developers would think of animation-range-end as meaning - i.e. the particular time or location at which the animation ends, but has additional conversion complexity and wouldn't map cleanly to the JS API - i.e. we may need more OptionalEffectTiming dictionary values to specify this.

In order I think I prefer 1, 2a, 2b, however there are good reasons for each.

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


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

Received on Wednesday, 23 November 2022 19:07:26 UTC