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

Fwd: [web-animations] Simplifying timing groups

From: Mike Lawther <mikelawther@chromium.org>
Date: Fri, 9 Aug 2013 09:50:46 +1000
Message-ID: <CAC7btF4pyxBnPHbq7Rwz1VrVNmDatFga1u_v9JNh_FDAMpv1zw@mail.gmail.com>
To: public-fx@w3.org
[apologies if threading doesn't work in this reply, sending from right
account this time]

Rik points out that Flash doesn't support this and yet somehow Flash
> authors have managed pretty well.

Case in point for Flash:
In particular the bit about modifying the animation of the wheels so it
matches with the timing function of the car - "You can adjust the value to
match the ease used for the car (100) [...] Save time by copying the motion
settings for the front wheel and applying them to the back wheel."

The authors *want* to be able to apply the same (non-linear) timing
function to a group of objects, but are stuck manually adjusting and
copying and pasting them. Note this isn't an entire timeline - but
manipulating the time of group of objects so they behave as a cohesive

> Last year in October when we demoed Web Animations we actually used this
> feature to ease both a door and its creaking sound.

So there's definitely use cases for doing this - and it only took a few
minutes to find the one from Adobe I mentioned above.

> There are two things
> to note about this use case:
> a) It could easily be done by applying the timing function to the two
> child animations independently.

While I take the point in a) that it's *possible*, having read the above
tutorial, I'd say 'laboriously' instead of 'easily'. Imagine that car was a
tractor with a larger rear wheel. Yuck. Motion graphics designers I've
spoken to spend a lot of time tweaking timing functions - it's how they
make their magic. After Effects even allows you to write script to control
animation timing.

> b) It could *also* be done by allowing a restricted set of timing
> functions on groups.
> I'm open to the possibility of adding restricted easing behaviour on
> groups like SMIL3 offers. I'd prefer to add that later but would be ok
> with adding it sooner if there is sufficient demand. I think that would
> address a number of the uses you outlined above without introducing many
> of the undesirable qualities of allowing arbitrary timing functions.

> I just feel that introducing features that (a) introduce considerable
> complexity, (b) are provided by no other animation platform we've found
> yet, and (c) for which we have yet to find concrete use cases that can't
> be solved by other means, seems like over-engineering for a first
> version of a spec. I think we can add this later if needed.

This is a concern about developer ergonomics - if there are clear use cases
and it would make developer's lives better, it's the developers we should

Received on Thursday, 8 August 2013 23:51:33 UTC

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