- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Sat, 01 Feb 2025 00:01:22 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[web-animations-2] Allow Animation constructor to take an object of properties as second param`, and agreed to the following: * `RESOLVED: Add an overload to the animation constructor that takes a dictionary of animation-specific options as a second argument, like the second element.animate() argument` <details><summary>The full IRC log of that discussion</summary> <emilio> bramus: proposal is add an object param to Animation ctro<br> <emilio> ... current behavior is effect then timeline<br> <emilio> ... with scroll-animations you also have ranges etc<br> <astearns> s/ctro/constructor/<br> <emilio> ... the answer is to also attach a KeyframeAnimationOptions<br> <flackr> q+<br> <emilio> ... then authors can easily transition from `.animate()` to `new Animation()`<br> <emilio> q+<br> <emilio> flackr: I think some of the options are things that are specified by the first parameter<br> <emilio> ... in the spec an animation effect has iterationDuration, playback direction, fill mode<br> <emilio> ... so maybe we need to split off just the animation-specific props into its own dictionary<br> <emilio> bramus: would make sense<br> <emilio> ack flackr<br> <astearns> ack emilio<br> <bramus> emilio: was gonna suggest just that<br> <bramus> … and can we add 1-arg version that fixes element.animate?<br> <ydaniv> q+<br> <bramus> … than just set the target<br> <bramus> … i forget how the object model works for this<br> <bramus> flackr: dont see why we could not do that<br> <emilio> ydaniv: element.animate() already takes a second arg with the options<br> <bramus> emilio: i meant to make the animation constructore more parallel to .animate<br> <bramus> flackr: like two-arg version<br> <bramus> ydaniv: its the original proposal<br> <bramus> emilio: no, because you have like an effect<br> <bramus> flackr: its contstructing an effect<br> <bramus> ydaniv: so you mean the first arg<br> <bramus> emilio: yes, it would be differnt than just .animate<br> <emilio> s/than just/, just like<br> <bramus> flackr: and might need to add target<br> <bramus> emilio: right<br> <bramus> ydaniv: so we split ???<br> <bramus> emilio: yeah, its fine<br> <emilio> ydaniv: maybe that should be a separate issue?<br> <bramus> astearns: so what remains is?<br> <emilio> astearns: so what remains?<br> <emilio> PROPOSED: Add an overload to the animation constructor that takes animation-specific options as a second argument, like the second element.animate() argument<br> <emilio> RESOLVED: Add an overload to the animation constructor that takes a dictionary of animation-specific options as a second argument, like the second element.animate() argument<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11146#issuecomment-2628591259 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 1 February 2025 00:01:23 UTC