- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 20 Jul 2011 07:48:18 -0700
- To: Rik Cabanier <cabanier@gmail.com>
- Cc: Sylvain Galineau <sylvaing@microsoft.com>, "www-style@w3.org" <www-style@w3.org>
On Tue, Jul 19, 2011 at 9:34 PM, Rik Cabanier <cabanier@gmail.com> wrote: > The biggest advantage would be performance since the CSS is interpreted > directly by native code in the browser. There would be no performance difference; the JS API, being designed into the browser, would hook into the same mechanics that CSS animations do. I'm not talking about doing JS-based animations where you fire some callback every delta of time and adjust a value a little bit manually; I'm talking about creating or retrieving Animation objects in JS (which are backed by the same data structures created by CSS animations) and then manipulating them. > Another advantage is editability. Users and design applications would be > able to read the animation CSS back in and modify it. This would be > impossible if animation is done through JS. > For instance animations that are generated by swiffy or smokescreen can not > be read in by any other programs. That's because they're doing the animations manually. There isn't actually an animation there, just a bunch of code that's run regularly. If you use actual Animation objects, you can potentially query them from other tools. > Why is it not worthwhile? > Do you believe that the browser implementation will get too complex? Yes. I believe that the range of things that authors want to do with regards to timing and synchronizing animations is too wide to be easily done in a declarative syntax, particularly one that still looks like CSS. > The current spec is only good for very simple content. I believe that it > will be much more powerful with a couple of small changes. I don't disagree. What I disagree with is the assertion that we'll only want "a couple" of changes. ~TJ
Received on Wednesday, 20 July 2011 14:49:12 UTC