[scroll-animations-1] [web-animations-2] Clarifying behavior of getCurrentTime(rangeName)

[kevers-google]

A few questions regarding getCurrnetTime(rangeName) in AnimationTimeline.

Why does the progress need to be constrained between 0 and 100%. If in the 'contain' range and asking for the currentTime of the 'enter' range, should we not return a value greater than 100%?

What if the range is zero? If I recall correctly, a zero 'cover' range should result in an inactive timeline, which is handled in the algorithm, but what if the enter / exit range is zero due to having a target element of height zero (axis: vertical) and then querying one of those ranges? Perhaps this is deserving of a "returns null". This example may seem contrived, but it is doable. How about the case when the target exceeds the viewport size and fetching the 'contain' progress? As we transition from the 'enter' to the 'exit' range, the cover range has a height or width of zero.

[flackr]

A few questions regarding getCurrnetTime(rangeName) in AnimationTimeline.

Why does the progress need to be constrained between 0 and 100%. If in the 'contain' range and asking for the currentTime of the 'enter' range, should we not return a value greater than 100%?

I suspect so. This matches the time used by an animation over that range.

What if the range is zero? If I recall correctly, a zero 'cover' range should result in an inactive timeline, which is handled in the algorithm, but what if the enter / exit range is zero due to having a target element of height zero (axis: vertical) and then querying one of those ranges? Perhaps this is deserving of a "returns null". This example may seem contrived, but it is doable. How about the case when the target exceeds the viewport size and fetching the 'contain' progress? As we transition from the 'enter' to the 'exit' range, the cover range has a height or width of zero.

Zero range does not necessarily mean inactive. See #7778 (comment) for details. We should follow the calculation we define there. Though interestingly, for 0 range as long as you can scroll before or after the 0 range it probably makes sense to have the progress by -infinity and +infinity so that if your effect fills it applies the fill effect based on which side you're on.

[css-meeting-bot]

The CSS Working Group just discussed [scroll-animations-1] [web-animations-2] Clarifying behavior of getCurrentTime(rangeName), and agreed to the following:

• RESOLVED: `getCurrentTime` should just match the internal calculation for the time value which is unclamped

The full IRC log of that discussion

<argyle> flackr: the behavior of get current time
<argyle> flackr: the behavior of `getCurrentTime`
<argyle> flackr: kevin want to introducer the issue?
<argyle> flackr: kevin raised the issue that in the spec getCurrentTime produced values between 0 and 100%, but it does produce times outside of it
<argyle> flackr: proposal is `getCurrentTime` should just match the internal calculation for the time value
<argyle> kevin: we're talking about removing the clamping
<argyle> flackr: we already resolved in a different issue that the current time is not clamped, this updates the spec to be consistent with that
<argyle> fantasai: and then it seems like if that range is 0, and if youre' outside of it you return infinity
<argyle> flackr: if you used getCurrentTime and then set this time on anoather animation, returning plus or minus infinity would give you the same effect that that timeline wouuld produce, because you're forcing it into it's before or after phase. so i thought it'd be a good thing to do
<argyle> fantasai: so we have to return something, and plus or minus infinity for a 0 range is the only reasonable option
<argyle> flackr: yeah, just to sayyou're before or after that range
<argyle> astearns: alright, any concerns or comments on this proposal?
<argyle> RESOLVED: `getCurrentTime` should just match the internal calculation for the time value which is unclamped

[fantasai]

@flackr @kevers-google I updated the definition to remove the clamping. For the case of zero-size ranges, I specced the following:

If the start and end points of the named timeline range coincide, return negative infinity for time values before it, positive infinity for time values after it, and zero for time values coinciding with that point.

Let me know if that seems appropriate or if you want something different.

[kevers-google]

CSSUnitValue is specced to have the value as double (https://drafts.css-houdini.org/css-typed-om/#simple-numeric) and not unrestricted double, which would include +/-infinity. Returning +/-Inifinity% could be problematic assuming we wish to use TypedOM as the canonical form for the return value.

[kevers-google]

We could make the return type for getCurrentTime (unrestricted double? or CSSNumericValue) and simply drop the unit in the +/-Infinity case. Would like to keep the unit otherwise.

Do we really gain much indicating that we are before or after the named range?