Re: [css3-animations] Override of animation rule by !important

On Jan 25, 2012, at 10:47 AM, Jon Rimmer wrote:

> On 24 January 2012 04:13, Sylvain Galineau <sylvaing@microsoft.com> wrote:
>> 
>> First, what are the use-cases that would make this useful? How do authors get
>> concurrent inter-dependent animations tuned to produce the desired result? Are
>> there desirable effects that can't be otherwise achieved? (It could be that color
>> is not the right scenario to demonstrate the usefulness of this). The technical
>> possibility of it does not concern me as much as its usability and usefulness (yet).
>> 
>> Second, your script assumes that what happens when :hover matches is:
>> foreach-transition-step(
>>        1. Compute color as if :hover didn't match
>>        2. Then use output of #1 to figure out current transition step state based on duration+timing-function
>> }
>> 
>> I'm not sure where we get #1 from; it's as if color keeps two computed values all along. Never mind that we
>> Currently specify that declarative animations do not trigger transitions...but they can change their start
>> value? And recall that there is no hard definition of when browsers compute values.
>> 
>> It's certainly easy to express in an imperative manner. Achieving an interoperable result in a declarative
>> manner is a different problem. But first we should answer what this is for and then discuss how...
>> 
> 
> Well, I wasn't trying to demonstrate that it was necessarily _useful_
> to transition between moving values, just that it wasn't difficult to
> implement, at least not within the context of a simple prototype.
> Anyway, since then, I've had a bit more time to think about this, and
> this is what I've come up with:
> 
> Firstly, I think transitions should definitely apply on top of
> animations. I think there plenty of cases where an author would want
> to create declarative animations and then have user-trigger
> transitions override them. For example:
> 
> - A group of buttons whose background color slowly pulses and a
> highlight that applies when the user mouses over one of them.
> 
> - A group of icons in a dock-like control. I might have an animation
> to bounce one of them up and down to attract the user's attention.
> When the user mouses over, I might want a transition to override the
> bounce and to move the icon upwards slightly.

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.

-----
~Chris
cmarrin@apple.com