- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Sat, 28 Jan 2012 09:55:34 -0800
- To: Jon Rimmer <jon.rimmer@gmail.com>
- Cc: Chris Marrin <cmarrin@apple.com>, Sylvain Galineau <sylvaing@microsoft.com>, "www-style@w3.org" <www-style@w3.org>
On Jan 28, 2012, at 3:24 AM, Jon Rimmer <jon.rimmer@gmail.com> wrote: > On 27 January 2012 15:33, Chris Marrin <cmarrin@apple.com> wrote: >> >> I definitely think we should not apply transitions on top of animations. >> You're really talking about additive animations which we have discussed >> several times. We've talked about it in context of multiple animations, but >> I think it applies to transition + animation as well. I believe the reason >> the previous discussions have not led to any additions to the spec is that >> the syntax and semantics are difficult to define, it's unclear what the best >> behavior is, and there are other alternatives that work today. >> >> The alternative is to nest elements. That works in most cases and the >> semantics are well defined. It solves your second example, and by using some >> opacity trickery (make unhighlighted buttons half opaque and increasing the >> opacity to full on mouse over) you can do an effective implementation of >> your first example. >> >> So I think we can get all the interesting combination effects we need >> without resorting to simultaneous transitions and animations. >> >> Someday I can imagine the case for additive animations becoming strong >> enough to revisit them. When that happens I think we should also allow >> simultaneous transitions and animations. But I don't think we need it right >> now. >> > > I disagree, this is not the same as a additive animations. Having > multiple animations applying simultaneous, equally weighted changes to > element properties is indeed a very difficult thing to specify, but > here there is a very clear weighting: transitions would always "win", > and the changes they applied would _override_ those applied by the > animation, not add to them. I described a few approaches for doing > this in my previous post. Do you have any more specific reasons for > believing an of them would be very difficult to implement or specify? > > Because this is a question of overriding animations, not adding to > them, your suggestion of nesting would not be adequate in most cases. > In the second example, the requirement is to stop the bouncing > animation when the user hovers the mouse over the element. Applying a > transition to a parent/child element would allow you to shift the > icon, but wouldn't stop the bouncing animation from continuing. > > Similarly, if I had an animation that pulsed a thick border around an > element, and a transition to shrink the border and change its color, > how would I achieve that using nesting? Or an animation that shifted > the offsets of a box-shadow, to simulate a moving light source, and I > wanted a transition to override the offsets and increase the > blur-radius? I could come up with more examples, but the key thing is > that any approach that allows the animation to continue applying > visible changes to the element, even when the transition is fully in > effect, is not solving the use case. I agree with Jon, that the type of use cases he presented are important, and should be solved in ways similar to the options he described.
Received on Saturday, 28 January 2012 17:56:09 UTC