[scroll-animations] End < Start offset can cause the ScrollTimeline to produce negative time

[majido]

The spec does not require start and end offset to have a strict ordering so it is possible to define
start offset that is larger than end offset. This combined with how the current time is computed can lead to a negative current time.

(current scroll offset - startScrollOffset) / (endScrollOffset - startScrollOffset) × effective time range

A similar concern exists for timeRange which can also be negative.

Is this intentional or should there be more constraints over these values so that currentTime is always guaranteed to be a positive values?

[birtles]

A negative current time is not a problem per se but I'm not sure if it was intentional.

[majido]

I suggest we restrict this by requiring the end be larger or equal to start otherwise the timeline would return an unresolved time.

BTW today there was a proposal to have an array of scroll offsets and not just two in which case we should sort such offsets before using them to compute the current time. This will also solve this issue.

[birtles]

Yes, sorting might make more sense. At least String.substring() does that. I'm not sure if it's a common JS pattern, however.

[ogerchikov]

Sorting solves the problem for container based offsets. If offsets are element based, the elements can be rearranged within the scroller post sorting and, as a result, produce negative time.

[flackr]

I don't think there is a problem with negative times. However, if the start offset is greater than the end offset, the common case will be that the start offset is also greater than the current scroll offset (e.g. this is the case with RTL text) and the calculation will result in a positive time.

We have chosen not to clamp time values as it allows the animation effect's fill behavior to properly dictate what the effect output should be negating the need for phases.