https://motion.dev/guides/waapi-improvements#durations-as-seconds https://motion.dev/guides/waapi-improvements#durations-as-se...: I did a double take on seeing

https://motion.dev/guides/waapi-improvements#durations-as-seconds https://motion.dev/guides/waapi-improvements#durations-as-se...: I did a double take on seeing .currentTime as milliseconds in the Web Animations API, because HTMLMediaElement.currentTime (that is, on <audio> and <video>) is defined in seconds! But what really struck me as curious on reflection is that if I hadn’t been presented with currentTime, I think I would have expect times to be in milliseconds, because that’s what things like setTimeout and Date.now use, and they’re the sorts of things you’d use before the Web Animations API was a thing (well, except that requestAnimationFrame supplanted setTimeout years ago). So from the perspective of the web platform that WAAPI was building on, I think milliseconds made sense. CSS doesn’t have this issue: times require a unit, so you can say 1s or 1000ms as you desire. Unfortunately you can’t really do united quantities in JavaScript; the ergonomics would be terrible for arithmetic and such, and so just using numbers and declaring them to be either seconds or milliseconds is the only sane option. Unfortunately, some things work in seconds and others in milliseconds. In the end, people are sure to make mistakes in one direction or the other, but the factor of a thousand is big enough that it should normally be noticed promptly and fixed.