[csswg-drafts] [scroll-animations-1] Time being overall scroll proportion on ViewTimeline leads to complicated architecture (#7312)

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

== [scroll-animations-1] Time being overall scroll proportion on ViewTimeline leads to complicated architecture ==
The [ViewTimeline interface](https://drafts.csswg.org/scroll-animations-1/rewrite#viewtimeline-interface) defines accessors for [startTime](https://drafts.csswg.org/scroll-animations-1/rewrite#dom-viewtimeline-starttime) and [endTime](https://drafts.csswg.org/scroll-animations-1/rewrite#dom-viewtimeline-endtime). The definition of these accessors and [currentTime](https://drafts.csswg.org/web-animations-1/#dom-animationtimeline-currenttime) says that they give the proportion of the overall scroll.

However, in order for the relative view position to map to animation progress, we would have to constantly adjust the startTime and duration of the animation to match the startTime and duration of the timeline. I think this would be very confusing for developers if the animation timing changed constantly based on layout, and would likely result in any specified timing getting out of sync with the view timeline range. I think we should be using percentages such that the start of a view timeline is always 0% and the end is always 100%.

We could still have accessors such as startScrollOffset and endScrollOffset which return offets in pixels, I would just propose that we don't have the output time offset and duration be affected by the layout.



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


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

Received on Wednesday, 25 May 2022 20:18:22 UTC