- From: fantasai via GitHub <sysbot+gh@w3.org>
- Date: Mon, 24 Apr 2023 21:57:53 +0000
- To: public-css-archive@w3.org
fantasai has just created a new issue for https://github.com/w3c/csswg-drafts: == [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 the default behavior as returning the time with respect to a timeline range that encompasses the entire timeline, `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, its 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? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8765 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 24 April 2023 21:57:54 UTC