W3C home > Mailing lists > Public > public-fx@w3.org > April to June 2015

Re: [web-animations] Relative Animation is taking over the world

From: Shane Stephens <shans@google.com>
Date: Thu, 23 Apr 2015 21:54:41 +0000
Message-ID: <CAGTfzwQub4awNG56rXWdZhEGrponXo49+HBsyMh2aJ9Vm5UmXQ@mail.gmail.com>
To: Kevin Doughty <socallednonflipped@gmail.com>, public-fx@w3.org
> 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

> 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.

Received on Thursday, 23 April 2015 21:55:09 UTC

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