[scroll-animations-1] Time being overall scroll proportion on ViewTimeline leads to complicated architecture

[flackr]

The ViewTimeline interface defines accessors for startTime and endTime. The definition of these accessors and 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.

[flackr]

In particular, I'd suggest

• rename startTime and endTime to startScrollOffset and endScrollOffset accessors which return pixel offsets.
• update currentTime to be the proportion or progress from startScrollOffset to endScrollOffset rather than the overall scroll progress within the scroll container. i.e. currentTime = (scrollOffset - startScrollOffset) / (endScrollOffset - startScrollOffset)

[mattgperry]

I agree that the only visible output of Scroll and View APIs should be 0-1 progress/percent and the resolved pixel offsets. If this API was being constructed in isolation there wouldn't be any discussion of time - it's just an unfortunate legacy.

I'm currently working on a scroll "timeline" API and indeed the mapping from scroll to animation is animation.currentTime = animation.duration * scroll.progress.

[fantasai]

OK, I've updated the spec to define startOffset and endOffset members on ViewTimeline. I have a few questions:

• Are these the names we want?
• Is the offset in downwards/rightwards coords from the scroll origin (0,0), matching the values of scrollLeft and scrollTop (which go negative in RTL documents afaict?) or do we want something that's always positive from the origin or...?

[bramus]

Looking at @flackr’s calculation for currentTime (*) above, it would use the scrollX values indeed.

(*) This should be named currentProgress as it yields a percentage-ish value. To get currentTime, multiply it by the duration set on the animation. Also see @mattgperry’s calculation above.

[flackr]

The names look good to me. I think matching the values of scrollLeft / scrollTop is simplest - and still yields correct results in currentTime since we the negative signs would cancel out in the calculation.

[flackr]

@fantasai shall we remove the in-spec issue 2093954#diff-2b774a580b0c0b0670d6bc747bbe3cab6afa91832f3381a0a890a1d4fdbd3a90R394 and call this closed?

[fantasai]

@flackr In theory, yes, but I think we need to tighten up the wording so that the implications in that issue are clearer. :) I'll file a new issue on that, though.