You mention here and on the homepage you are the author of Framer Motion and Popmotion but in neither place are there links to those projects. I'd love to check them out so if they still exist it may be worth making that text on the homepage a link?

Ah apologises I just wanted to reduce the number of "off ramps" and as the other comment says, I am sort of assuming that people might be familiar with them but indeed they might be more fitting to your project (Popmotion if you want very low-level JS animations that just outputs values and Framer Motion if you want a high level React library that handles gestures and layout animations)

But hezags comment below has kindly provided the links.

1 - https://www.framer.com/motion/

2 - https://popmotion.io/

To be fair, Framer Motion and Popmotion are really big names in the web animation space, so it is probably safe to assume most people with even a passing interest in the past few years will have heard of them.

This looks really nice!

2 bits of feedback:

- hitting 'play' on your site's demo animations is adding pageviews to my history, which made getting back here to leave feedback unusually tough :)

- for some reason, even the basic demo animations on your site have BIG delays/stutter -- every one of them, every time I play them. For context, I'm running Chrome 93.0.4577.63 (Official Build) (x86_64) on macOS Mojave 10.14.6 on a 2018 MBP, and have ~60 tabs open.

1. Thanks for pointing out the play button bug - I'll look into how I can stop that.

2. That is really odd. I'm on a similar machine with no problems. Are these the same demos with the iframe or do you also have problems with the homepage?

oh interesting! I didn't realize they are iframes -- the homepage ones (e.g. the hero animation, the scale animation, the hardware-accel one) all seem fine, even right after pageload. It's the iframe demos that have the stutter/jump issues.

I also just noticed my mac is a bit slow across the board right now, so it may be my own issue, a bad case of "uptime-itis" that can only be solved by a restart.

Just pushed a fix to the browser history bug, thanks again for pointing it out.

What's the difference between this and something like Framer Motion?

Framer Motion is very high level, declarative API. It works out when to fire animations based on state and gesture changes. It also has a very advanced layout animations engine.

This is more of a classic JS library like Greensock or Popmotion where you say when you want to fire animations. I do want to move into declarative animations too but this is just the first release.

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

Hi Guidii!

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.

I'm confused about what this does above & beyond css animations/transitions.

Imperative JS libraries are more convenient to schedule and dynamically generate animations, but above and beyond that this offers timeline sequencing for long animation orchestration, independent transform animations, and will soon offer spring animations.

Edit: And that CSS Tricks article covers more stuff well.

Nice website.

My primary measure of interest in animation libraries is demonstrations/showcases of the library in action.

I could see nothing like this on the front page so I closed it.

I'd love to see what this library can do so I'll come back to it when there's demonstrations.