You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
birtles
changed the title
End < Start offset can cause the ScrollTimeline to produce negative time
[scroll-animations] End < Start offset can cause the ScrollTimeline to produce negative time
Oct 7, 2019
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.
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.
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.
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.
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?
The text was updated successfully, but these errors were encountered: