Hi Rob, >> I have to admit that I'm not that familiar with SMIL. I just glanced at >> the spec and it seems overly complicated. Maybe it's better to extend the >> CSS animation spec to allow for true keyframe animation. >> > > We don't need or want the whole spec. Webkit, Gecko and Opera focus on the > SVG Animation subset: > http://www.w3.org/TR/SVG11/animate.html > (Brian Birtles has some proposals to simplify that subset too.) > > I looked over the simplified SMIL spec and for the most part, the spec lets you do similar stuff to CSS animations. SMIL has the ability to trigger synchronize animations with syncbase-value ( http://www.w3.org/TR/SVG11/animate.html#TimingAttributes) which is different and useful. I have posted another example of my original problem statement here: http://mobiletest.host.adobe.com/w3c/sign.html (again, webkit only) This is a case of frame-by-frame animation which is something that designers do all the time. The animation simulates a bending sign. It takes 6s and uses 120 individual elements. Originally, we tried to implement this by using the animation-delay keyword but this caused severe slowdowns and rendering issues in the browser. We settled on a solution where the different animations are daisychained together so the end of child 1 will trigger the start of child 2. This simulates SMIL's syncbase-value but suffers from the asynchronous event issue. However, an additional problem is what happens if your device can't keep up (ie a slow mobile device). In order to keep things in sync, you might have to skip or fast-forward. We currently try to implement this in JavaScript but there seems to be no way to so so in SMIL. The new CSS syntax would describe my example of the sign andthe browser could detect when the keyframes start falling behind and do the fast-forwarding for me. If we want to turn browser in true animation engines, this needs to be a requirement... Rik
Received on Friday, 1 April 2011 20:19:29 UTC