W3C home > Mailing lists > Public > public-fx@w3.org > July to September 2012

Re: [web-anim] automatically discarding animations

From: François REMY <fremycompany_pub@yahoo.fr>
Date: Wed, 8 Aug 2012 09:43:19 +0200
Message-ID: <B01F16362FB34A79B7434EE82AF37996@FREMYD2>
To: "Brian Birtles" <birtles@gmail.com>
Cc: <public-fx@w3.org>
|  I re-read your previous mail about (non-)seekable groups. I think the
|  hasSeekableParent property actually needs to look right up the tree.

Yes, true. If a child animation is seekable, you can't drop the parent 
animation once if finishes since the child can still be seeked. However, you 
can drop the other (non-seekable) children.

|  One alternative is to prevent all seeking of the effects timeline and
|  its descendants and re-work reverse to spawn a new animation. That would
|  let implementations optimise fill: forwards by replacing such animations
|  with a single value.

This is basicly what I propose, indeed. This model is the most optimizable 
model and should therefore be the default one.

However, you can reach this without using an "effect" timeline at all. If 
animations and animations groups are non-seekable by default and you need to 
specify a parameter (or change a property value, or call a method or...) to 
mark them as seekable, you can achieve the exact same behavior using one 
root timeline only. A single timeline could contain both optimizable and 
non-optimizable animations, that's it. I don't see the point of creating two 
timelines and creating special rules for each one of them while we could 
merge that in a single concept.

|  There will be APIs in the CSS integration spec for
|  querying the animation objects in the timeline or corresponding to
|  specific CSS rules. On the mouseout event, you can fetch the appropriate
|  animation object, call reverse, and immediately drop the reference to
|  the object.

Nice. My concern goes away, then.

BTW, I found an important reason to keep templating: if we can use 
templates, we can save memory by storing the property values once. However, 
we can get rid of the AnimInstance entirely if we use a model where 
animations can have a sequence<Element> instead of an Element as target.

    let anim = new Anim(...);

    let anim2 = anim.makeIndependent(

    anim.targets == #a, a:not(.external)
    anim2.targets == a.external

|  Yes, I agree. Shane has a proposal for this which we want to incorporate
|  in the future.[1]

I like his proposal! Using CSS Custom Properties to specify the state 
changes is very clever! Syntax could be reworked but globally I feel the 
idea is right. I didn't really understand the @node(...) proposal but I 
guess it's a bit like my "when(...)" concept.

Since transitions are an important use case of animations, I think 
incorporating this proposal is important as well. At least, we need to make 
sure its incorporation will not require additionnal concepts. 
Received on Wednesday, 8 August 2012 07:43:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:42 UTC