Comments on: Web Animations

By: Easy Recipes For Dinner

Easy Recipes For Dinner — Thu, 13 Jun 2013 07:13:09 +0000

Thank you for the auspicious writeup. It if truth be told was once a amusement account it.

Glance complicated to more brought agreeable from you!

However, how could we keep in touch?

By: Kevin Doughty

Kevin Doughty — Fri, 07 Jun 2013 20:24:44 +0000

You left a comment on my blog so I thought I would reciprocate, although on an old post. I swear I am not the commenter named modeless, who described exactly a problem that is solved by an animation usage pattern I use. He even used the word seamlessly. 急に鳥肌を立つ、ね。The solution, of course, is concurrent animations that are defined absolutely but behind the scenes converted to a relative from value of old minus new and to value of zero. It is for workhorse animation, for layout not movies, and the only way to respond to user events. I have been reading about SMIL and web animations but haven’t made any feature requests… yet. http://kxdx.org 皆、見て下さい！

By: hair cut

hair cut — Tue, 28 May 2013 22:19:26 +0000

Hello it’s me, I am also visiting this website regularly, this website is really good and the viewers are really sharing fastidious thoughts.

By: cars

cars — Sun, 26 May 2013 19:10:06 +0000

All large purchases are always intimidating, especially if you are uninformed about the industry.
One of the scariest purchases is buying cars. Many people fear they are getting ripped off and you surely don’t want that. Avoid buying a lemon by looking through these great tips and tricks regarding car purchases.

By: girls in sauna

girls in sauna — Thu, 23 May 2013 11:20:52 +0000

I cherished as much as you will receive carried out proper here. The caricature is tasteful, your authored subject matter stylish. nevertheless, you command get got an impatience over that you want be delivering the following. in poor health for sure come further previously once more as precisely the same nearly a lot steadily inside case you protect this hike.

By: Brian

Brian — Thu, 22 Nov 2012 05:49:32 +0000

Hi modeless,

Thanks for your comment. I’m pretty sure the feature you described is covered by the MERGE combinator in the current spec. (The link is: https://dvcs.w3.org/hg/FXTF/raw-file/tip/web-anim/index.html#the-merge-combinator but links within a page don’t seem to work in most browsers with respec).

I think what many applications really need is a notion of state. We have a proposal for that but decided to leave it until version 2. The merge behaviour is something added to support state machines.

Actually, just recently I was thinking that we should drop merge for now since I thought most applications won’t use it, but after receiving your comment I’m persuaded to leave it for now. So thanks very much for your comment!

Brian

By: modeless

modeless — Wed, 21 Nov 2012 05:48:52 +0000

What I really want in an animation API is the ability to seamlessly switch from one animation to another without stopping or messing up the current state. For example, the door opening and closing animations in the video look fine as long as they never overlap, but if you switch to the closing animation before the opening animation is done it looks terrible.

What I want is to be able to interrupt the opening animation halfway through by switching to the closing animation, and have the door smoothly transition from opening to closing. Ideally not just the position but also the velocity of the door would continuously transition to the new animation.

I’ve never seen an animation API that handles this gracefully, even though it’s extremely common in actual applications. With the current CSS animations it’s not even possible to get the current velocity of an animation without reimplementing the calculations in JavaScript yourself.

By: Brian

Brian — Thu, 01 Nov 2012 00:21:15 +0000

@ben: I wasn’t familiar with QML so I had a look. It’s pretty nice. I think we have a pretty similar feature set, even down to matching the parallel and sequence animation types.

The pause animation (i.e. spacer gif) is interesting and might be worth adding. So is the spring animation—although I think we can realise this at the API level with the proposed SmoothTimingFunc and then add some declarative syntactic sugar.

We have plans to add state in a later version. Shane Stephens already has a proposal for this written up.

The naming “Action” is interesting too. It might be more intuitive than what we’re calling an AnimFunc at the moment.

Also, it seems like this model uses an integral number of milliseconds for duration. Currently we use a real number representing seconds. I wonder if milliseconds are more intuitive since that’s what window.setTimeout uses.

I’ll add these items to the agenda for our next conference call.

By: ben

ben — Wed, 31 Oct 2012 15:53:11 +0000

Are you familiar with QML?

It is (among other things) a declarative animation framework that is much more developer friendly than SMIL.

Its development is currently tied to “offline” application UI development with Qt, but the language and declarative API itself should be easy to transpose into a web world.

By: Brian

Brian — Wed, 31 Oct 2012 12:15:06 +0000

That’s the purpose of the SVG and CSS integration documents—they map declarative features onto the API. We intend to extend the capabilities of declarative animation in both SVG and CSS at the same time.

I agree on the importance of support animation without script. One example is animated emoji in an SVG-in-OpenType font. You can’t run script there. Or cursors, backgrounds, cross-domain images etc. As someone who spent nearly 8 years implementing SMIL I’ve seen many benefits of a declarative approach. (I have a report emphasising that point.)

Ultimately, the API is not the primary goal. It’s actually something we decided on after starting the spec. The goal is a consistent and more powerful model for animation on the Web. But having a scripting API lets you inspect declaratively generated animations, manipulate them (both SVG and CSS animation APIs are quite lacking at the moment), sync them (i.e. CSS<->SVG), test interop at a lower level (CSS animations are particularly hard to test at the moment), etc. For cases where script is appropriate, the API makes writing frame-rate independent synchronizable animations easier and hardware accelerate-able.