- 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