- From: L. David Baron <dbaron@dbaron.org>
- Date: Sun, 29 Jan 2012 02:19:33 +0100
- To: Jon Rimmer <jon.rimmer@gmail.com>
- Cc: Sylvain Galineau <sylvaing@microsoft.com>, "www-style@w3.org" <www-style@w3.org>
[ In the future, when you change the subject of a thread, please change the Subject: header of your message. I've done that. ] [ Also, writing this on board an airplane, so apologies if the discussion has already covered this by the time I land. ] On Friday 2012-01-20 17:06 +0000, Jon Rimmer wrote: > For both animations and transitions, at any instant, we have a base > property value, a target property value, and an interpolation function > that produces an intermediate value based on the duration and the > easing. All we need is a simple pipeline, where the instantaneous, > intermediate value from the animation is fed as the base value into > the interpolation function of the transition. I think this doesn't make sense with transitions as they are today because of the mechanism with which transitions start: they start in response to changes in computed values. If there's another animation running (a moving target), the computed value is constantly changing. If transitions, initiated today via 'transition-property', started in response to changes in computed value caused by other animations it would only serve to damp those animations in bizarre ways. And since the model of transitions that happen based on 'transition-property' is based on computed values, it's not clear how a change in the value "underneath" the animation would start an animation since that change would not be reflected in the computed value. However, if we had an API to initiate a one-off transition (which I think would probably be a good idea), I think the concept you're talking about might make more sense. -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla http://www.mozilla.org/ 𝄂
Received on Sunday, 29 January 2012 13:00:56 UTC