[scroll-animations-1][web-animations-2] getCurrentTime is self-inconsistent wrt representing time

In order to represent time in relation to named timeline ranges, we have two options:

• Represent as absolute progress from the start of the range, in units consistent with the overall timeline (i.e. equivalent to currentTime).
• Represent as percentage progress between the start and end of the range.

If we consider its default behavior as returning the time with respect to a timeline range that encompasses the entire timeline, the current definition for getCurrentTime() switches between the two modes depending on whether you specify a range name or not. (!)

This doesn't feel unnatural to scroll timelines, because their “absolute timeline units” are percentages of the timeline (which itself has a finite range)... We would probably have noticed the discrepency sooner if they used length-based time. :/

But it runs into problems if we extend the named timeline concept to other types of timelines, such as time-based timelines. These bring in (potentially) two differences:

• Their absolute time is not a percentage, but an absolute unit.
• They might possibly not be finite?

I think we might want to rethink this API. Some possible options:

• Restrict (and define) it as returning percentage progress through a range, rather than also being able to return the global currentTime, and name it accordingly as @birtles suggests in #8201.
• Define two APIs, one that returns percentage progress and one that returns absolute progress (i.e. units compatible with currentTime) in relation to a named range.
• Define a single API that can return either percentage progress or absolute progress depending on its arguments.

I'm not sure which direction we want to go... @bramus, thoughts?

Start with the linked named-range getCurrentTime() definition in the Scroll Animations specification and compare its behavior with currentTime for named and default ranges. Read the alternatives in this issue and related issue #8201; done means the Working Group has chosen and specified a consistent API direction.