- From: Boris Chiou via GitHub <sysbot+gh@w3.org>
- Date: Tue, 05 Jul 2022 23:47:24 +0000
- To: public-css-archive@w3.org
BorisChiou has just created a new issue for https://github.com/w3c/csswg-drafts: == [web-animations-2] The handle of unresolved current time in at-progress-timeline-boundary == Based on the step 3 of [at-progress-timeline-boundary in [web-animations-2]](at-progress-timeline-boundary), > Let effective timeline time be [animation](https://drafts.csswg.org/web-animations-1/#animation)’s [current time](https://drafts.csswg.org/web-animations-1/#current-time) / animation’s playback rate + effective start time we calculate the effective timeline time by animation's current time, playback rate, and the effective start time. However, this spec doesn't mention what should we do for unresolved current time. So perhaps It'd be better to specify what happens when the animation's current time is unresolved. In Chromium, it uses zero if it is unresolved ([code](https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/animation/animation.cc;l=2236-2238;drc=970e9eac87551b0de2d5e5f263be44c9dd0e4a46)), so for now, Gecko would like to implement this by setting zero for unresolved current time as well. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7458 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 5 July 2022 23:47:26 UTC