- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 12 Apr 2023 16:26:25 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-animations-2] Proposal: Time-based Keyframe Animations`, and agreed to the following: * `RESOLVED: Draft up proposal for time-based keyframe selectors in Anim 2` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> astearns: Anyone want to propose something for this, or just continue discussing in an issue?<br> <TabAtkins> fantasai: If we want to do, we can draft. If we'r enot sure, we can figure out the scope<br> <TabAtkins> miriam: I've heard lots of requests for this<br> <fantasai> TabAtkins: prsumably would work as we just discussed<br> <emeyer> TabAtkins: I presume it work in a way similar to what we just discussed<br> <TabAtkins> fantasai: Right, I think we have to think about these two together.<br> <TabAtkins> fantasai: So if we want to do this we can resolve it and figure out the issues together<br> <TabAtkins> miriam: is 100% the final time?<br> <TabAtkins> fantasai: That question is also relevant for the previous issue.<br> <TabAtkins> TabAtkins: Like is it duration, or duration+delay?<br> <emeyer> TabAtkins: Is it the duration, or is it the duration plus the dleay? Is that the question?<br> <flackr> q+<br> <TabAtkins> miriam: Or final keyframe<br> <astearns> ack astearns<br> <astearns> ack fantasai<br> <astearns> ack flackr<br> <TabAtkins> flackr: I think this is similar to range-based keyframes<br> <TabAtkins> flackr: Where they're converted to %s of the animation<br> <TabAtkins> flackr: The precedent we set is they don't set the range of the animation itself, they can go before beginning and after end<br> <TabAtkins> flackr: I can see if you use duration:auto if picks up the greatest duration specified in keyframes<br> <emeyer> TabAtkins: That would make sense if we ever do things like spring-timing functions<br> <TabAtkins> flackr: Yeah<br> <TabAtkins> flackr: But otherwise the default model should be the span is the animation duration, time values before/after that are clipped<br> <TabAtkins> +1<br> <TabAtkins> fantasai: That's different from... well what happens when you iterate?<br> <TabAtkins> fantasai: [missed]<br> <TabAtkins> flackr: Think it's consistent with range-based keyframes<br> <TabAtkins> flackr: They convert as if you have one iteration, and you shorten<br> <TabAtkins> fantasai: We'd do that here?<br> <TabAtkins> flackr: Yeah, don't think you want subsequent iterations to be different form earlier ones<br> <TabAtkins> fantasai: Feel like something's not clicking but not sure.<br> <TabAtkins> fantasai: But if we want to see this we should resolve on it and draft it, and see how all these keyframe types work together to make sure they're consistent<br> <TabAtkins> astearns: Anyone think we shouldn't work on it?<br> <TabAtkins> astearns: So options are (1) continue to work on details in the issue, or (2) put a draft in Animations 2<br> <TabAtkins> astearns: Anyone prefer leaving it in issue?<br> <TabAtkins> astearns: Anyone object to starting work on this in Anim 2?<br> <TabAtkins> RESOLVED: Draft up proposal for time-based keyframe selectors in Anim 2<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4907#issuecomment-1505573230 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 12 April 2023 16:26:27 UTC