- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 07 Jun 2023 23:13:27 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[scroll-animations-1][web-animations-2] getCurrentTime is self-inconsistent wrt representing time`, and agreed to the following: * `RESOLVED: Defer on getCurrentTime for L1` <details><summary>The full IRC log of that discussion</summary> <dael> flackr: We've had a bunch of debate about best way getCurrentTime on a timeline should work, if needed, what are use cases. Resolve dto add progress to animation to handle common use case<br> <dael> flackr: With that, think we should remove getCurrentTime from the APIa nd re-add when we have clearer sense of use cases<br> <dael> fantasai: I'm fine with deferring. It means there is no real way to figure out where you are in a timeline range. So you don't know when unless you make an animation and measure progress. We don't have API to say how ranges relate to rest of timeline<br> <dael> fantasai: But I'm fine with deferring. Not a problem<br> <dael> Rossen_: Anyone else?<br> <dael> Rossen_: Objections to defer on getCurrentTime<br> <dael> RESOLVED: Defer on getCurrentTime for L1<br> <dael> Rossen_: I'm assuming bramus is on same page as you? I don't see us doing a disservice for any commentor<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8765#issuecomment-1581632010 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 7 June 2023 23:13:29 UTC