| Hi there Matt - this looks like an amazing library - thanks for posting. I’m part of the Blink Animations team that work on WAAPI (along with a bunch of folks from other browsers), and wanted to touch base on a few of the issues you raised. First, I agree that fill behavior[1] is messy, and should probably be considered to be a spec bug. Moving web specifications forward often involves “compromises” to ensure that new functionality works alongside existing work, and this is a good example of that. There’s a discussion on this at github.com/w3c/csswg-drafts/issues/5394. You raise a few issues with the current implementation/compliance/interop. Getting compliant and consistent implementations of the spec is critically important, so appreciate your feedback on this. I’m seeing two items that (might) relate to chromium here:
individual transforms[2] - agree that this is important - currently working on it - see crbug.com/696374. Note: You can already get some of this working using composite:add.
.finished Promise[3] - mostly working in chromium AFAIK, with one minor glitch - crbug.com/1141935
If there are other chromium issues we’d love for you to file them (use Blink>Animation component so they land on our triage). Other browsers look for feedback as well - there’s a good guide/walkthrough at https://web.dev/how-to-file-a-good-bug/ On the topic of browser compliance, you cited caniuse.com, which is a good starting point. More detailed tracking can be found at https://wpt.fyi/results/web-animations - might be more detailed than you’re looking for, but this is what our team measures against. Some of your suggestions relate to the spec. Durations as seconds[4], and Simplifying cubic bezier definitions seem fairly straightforward, while others like cancelling and interrupting might be a little more complicated. In any case you can file issues against the spec if you want to move those forward - https://github.com/w3c/csswg-drafts/issues, tag with [web-animations-2]. To reduce the challenges of adopting the new API, there’s a published polyfill that you seem to be using already. You noted that there’s some inconsistency with keyframing across browsers - perhaps you could file an issue against the polyfill? Cheers! [1] https://www.w3.org/TR/web-animations-1/#fill-behavior
[2] https://motion.dev/guides/waapi-improvements#individual-tran...
[3] https://motion.dev/guides/waapi-improvements#finished-promis...
[4] https://motion.dev/guides/waapi-improvements#durations-as-se... - this might already be addressed through CSSOM?
[5] https://github.com/web-animations/web-animations-js
[6] https://github.com/web-animations/web-animations-js/issues |
I think it's fair enough that there's "spec bugs" and understand the constraints you/they were working in trying to cover both CSS transitions/animations. I prefer browser APIs low level enough to build opinionated libraries around!
Individual transforms for me doesn't go far enough, I haven't been involved in spec discussions but I'm surprised they stopped at transforms and not axes. Think throwing an element - x/y would want different animations based on the gesture velocity. I'm not sure composite works well with transform as its order-dependent, the behaviour is itself not well supported cross browser, though maybe composite+individual transform offers promise in the future.
On the state of implementation in general, I am using this project to file bugs to help get some eyes on WAAPI and so far I've opened 4 in Webkit and none in Blink so there's no worries there :)
Thanks for wpt.fyi - I have bumped into it but I should use it to pre-empt some of these bugs.
The polyfill is just for running tests in Jest. It's actually a little beaten up in terms of implementation and this has worked quite nicely as Chrome even in modern phones seems to not support finished so its helped my polyfill(er)s target those bits too.
Thanks for reaching out, I appreciate it.