- From: Shane Stephens <shans@google.com>
- Date: Thu, 23 Apr 2015 21:54:41 +0000
- To: Kevin Doughty <socallednonflipped@gmail.com>, public-fx@w3.org
- Message-ID: <CAGTfzwQub4awNG56rXWdZhEGrponXo49+HBsyMh2aJ9Vm5UmXQ@mail.gmail.com>
>
>
> 2. Animations are actually groups:
>
<Terminology bikeshed snip>
> The truth is I don’t really understand all of the issues raised by Brian
> and Shane in this thread:
>
> https://lists.w3.org/Archives/Public/public-fx/2015JanMar/0106.html
>
>
> But I really, REALLY, want a simple, high performance, single property
> keyframe effect that can be easily copied and applied to different
> elements, and it does not look like Web-Animations delivers.
>
In the latest ED (http://w3c.github.io/web-animations/), there's a concept
of a SharedKeyframeList. This pretty much gives you what you want - you'll
need to apply the restrictions (single property) yourself.
The performance considerations don't align exactly with your assumptions,
though. Multiple keyframes aren't slow, but parsing keyframe strings are.
> 3. Duration in milliseconds:
>
>
> Please have duration go back to seconds. Milliseconds is almost like a
> fake implementation detail, a performance ideal perhaps, from long ago. It
> is outdated and counter-intuitive.
>
That was a requirement imposed by the TAG - you'll need to take it up with
them.
> 4. Subtraction:
>
>
> I propose the spec require a definition of subtraction for properties in
> 4.1.2. Procedures for animating properties. I also propose the spec require
> the definition of zero for properties. This is of course for the Relative
> Animation pattern. Take for example these minor extensions to permit
> additive animation of mesh transforms (in Obj-C):
>
>
> https://github.com/KevinDoughty/BCMeshTransformView/blob/master/Demo/BCMeshTransformViewDemo/BCMutableMeshTransform%2BRelative.m
>
>
> If there ever is a mesh type for the web, figuring out how to “FLIP” it
> (as Paul Lewis now calls it) will be impossible.
>
Subtraction is addition of the additive inverse of a value. From the code
you've linked, it looks like the additive inverse of a mesh type is
trivially calculable (it's just the additive inverse of each component).
We have a concept of a "neutral value" which is a universal zero in some
sense. I'm interested in exploring how this behaves differently to an
explicit, per-property zero. The neutral value is exposed as a neutral
keyframe - currently we can't make these explicitly but it might be worth
exploring their inclusion.
Cheers,
-Shane
Received on Thursday, 23 April 2015 21:55:09 UTC