Re: [web-anim] automatically discarding animations

|  Oh, I was thinking the other way around. If an ancestor is seekable you
|  can't drop any of the children since they could become re-activated if
|  you seek the ancestor.

This is also true, but this case was already covered by my initial prose.




|  Ok, I understand a bit better what you're saying. I think we felt that
|  the uses of animations is so different to warrant separation. For
|  example, if you have an app with both cartoons (seekable) and UI effects
|  (not-seekable). You probably want to be able to pause all the cartoons
|  but not the UI effects. Of course, you can do that by adding top-level
|  groups, but it seems like such a common paradigm that it should be
|  available by default.
|
|  Bear in mind that CSS Transitions would default to a non-seekable
|  timeline, but SVG Animations would default to a seekable timeline (for
|  backwards compatibility). In a model where objects are only optimisable
|  if all ancestors are non-seekable then we probably need some means for
|  getting SVG animations out of their default group to benefit from
|  optimisation. That was also part of the thinking behind the effects
|  timeline.

CSS Transitions and SVG animations could define in their mapping their own 
"local root group" as a child of the root timeline, as authors would 
probably do; as such, they can define for themselves the properties of their 
own animation group.

However, I'm not against prefilling the root timeline with two groups (one 
seekable called 'animations' and one non-seekable called 'effects') to make 
author's life easier. I just don't like the fact that the specification 
could say things like "if the root timeline is effects, then ... orelse ..." 
because it's not needed and not very future proof.




|  I'm not sure templates are necessary for efficient storage (even if we
|  were to go with a cloning model, the clone can just point to its source
|  for its values and use copy-on-write for changes), but I think I'm still
|  in favour of keeping them.
|
|  The difficulty with making Anim objects refer to multiple targets is you
|  often want the targets to have different timing, particularly different
|  start times and pause states. For example, the animations generated by a
|  CSS Animation declaration have different start times. CSS Transitions
|  reverse independently of one another.

True. To accomodate my proposal, targets could have their own 
AnimationTarget interface storing both the target and target-specific 
properties but, as you said, the cloning model where you keep a reference to 
your source is not bad, too.





|  I think Shane also had some reservations about the
|  @node(...) part. As soon as we can settle on a good base model, we can
|  work on layering this on top.

I'm going to open a thread with Shane on the subject someday to work on this 
sub-specification. This is outside this thread's scope ;-)

Received on Thursday, 9 August 2012 08:53:19 UTC