[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?

[tabatkins]

CSSUnitValue is specced to have the value as double (drafts.css-houdini.org/css-typed-om/#simple-numeric) and not unrestricted double

Hm, that's actually just because I forgot to think about it. I think it would be fine make it an unrestricted double (since CSS can represent infinite and NaN values now).

[flackr]

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.

If range-start = range-end, the animation isn't active so I'm not sure if 0 makes sense or if it should be -infinity since we seem to be in the before phase:

https://jsfiddle.net/flackr/z2ghe9qx/8/

@kevers-google are you good with the +/- infinity values given that we can add them and so that if you copy the progress to another animation you get the same effect?

[kevers-google]

I'm good with +/- infinity

[fantasai]

(Filed w3c/css-houdini-drafts#1089 as the OM issue; let's keep this one open to track it since that's in a different repo.)

It looks like we need a follow-up resolution here for what happens when start=end? I think we basically have these two options for when the start and end points of a named timeline range coincide:

• Return negative infinity for time values before the range, positive infinity for time values after it, and zero for time values coinciding with that point.
• Return positive infinity for time values after the range, and negative infinity for times coinciding with and before.

[flackr]

It looks like we need a follow-up resolution here for what happens when start=end? I think we basically have these two options for when the start and end points of a named timeline range coincide:

• Return negative infinity for time values before the range, positive infinity for time values after it, and zero for time values coinciding with that point.
• Return positive infinity for time values after the range, and negative infinity for times coinciding with and before.

I recommend the latter for the same reason I recommended the infinity values. If a developer applies this to another animation it will clearly put the effect into the before phase rather than active as it would be on a real animation.

[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: Return positive infinity for time values after the range, and negative infinity for times coinciding with and before

The full IRC log of that discussion

<dael> astearns: Follow up about what happens when start = end
<dael> flackr: I believe fantasai added to agenda. Clarification is how to handle start time = end time
<dael> flackr: I've prop never return 0 for current time with assumption dev is plugging this into an animation and if they plug - or + infinity they guar. the animation is before or after phase and that's not same as the effect they're copying time of
<astearns> ack fantasai
<dael> fantasai: I don't have much of an opinion. If it's not 0, then what is it? Can we resolve on what we want it to be?
<dael> flackr: It's what you said in your second option.
<dael> flackr: [reads]
<astearns> Return positive infinity for time values after the range, and negative infinity for times coinciding with and before.
<dael> fantasai: So negative infinity for coinciding? I don't know I thought through this.
<dael> flackr: Yes, that is correct
<dael> fantasai: I know I suggested negative infinity, but I don't remember why
<fantasai> and maybe I got it backwards when typing
<dael> astearns: Only difference between your options is what we do with time values coinciding with a single point in the range
<dael> fantasai: Right, if you land on that point should it be before or after start
<dael> flackr: I believe I compared this to a running animation with 0 duration. Recollection is your statement matched the animation behavior
<dael> fantasai: If you think it's right, I'm fine. I just want to make sure
<dael> astearns: My question- is this just an edge case we're filling a rational answer in for or is this something devs are expected to handle?
<dael> flackr: My opinion this is a bit of an edge case and we're trying to fill in value that would give the same effect as an animation with that range
<dael> astearns: Other comments on this?
<dael> astearns: Prop: Return positive infinity for time values after the range, and negative infinity for times coinciding with and before
<dael> astearns: Objections?
<dael> RESOLVED: Return positive infinity for time values after the range, and negative infinity for times coinciding with and before
<dael> astearns: As fantasai said, seems a bit weird but this is a good...
<dael> flackr: I did paste a demo on March 10 demonstrating. So I'm not misremembering
<dael> astearns: If you have time fantasai or anyone else please take a bit of time considering implications in case we want to revisit
<dael> github-bot topic, https://github.com//issues/8542#issuecomment-1515216159

[flackr]

I just put together a quick test of a time based animation of 0 duration time based animation:
https://jsbin.com/qarogay/edit?html,css,output

And it behaves more like I expected, being in the after phase. So perhaps times coinciding with the empty range should be positive infinity. This also aligns with what I expected would be the case.