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

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.

If we accept that it's desirable to have transitions override
animations, the question is how they interact. I think there are some
key things from an author's perspective:

Firstly, the transition-in should begin from whatever the element's
actual value is at the moment when the transition begins, not the
underlying value. I notice that Simon Fraser has said the opposite
later in this thread. I'm sorry, but that just seems completely wrong
and counter to what authors would want.

If I had some buttons whose background color pulsed between say #000
and #444, and a hover transition to make them #666, there's no way I
would want the transition to begin from #000 when the current animated
color was #444! It would look bad. Similarly, if I had an animation to
move an element between two points, and a hover to move it somewhere
else, I wouldn't want it to jump back to its starting point when the
transition began! I'd want it to transition from its intermediate
position, whatever that was.

Secondly, when the transition concludes, the animation should continue
exactly as it would have had if the transition had never happened.
This is very important when there are multiple, synchronized
animations on a page, as otherwise a transition could knock them out
of sync.

Let's look at an example scenario, where an animation and a hover
transition apply to the background-color property of an element.

Consider the following timeline (monospaced font required):

Time (seconds)       0       0.5      1        1.5      2         2.5
                     |       |        |        |        |         |
Animation:           o--------------------------------------------o
Transition in:               o--------o
Transition applying:                  o--------o
Transition out:                                o--------o

The property has an underlying value of #000. The animation takes 2.5s
and changes the value from #000 to #EEE. The transition takes 0.5s and
changes the value to #FFF. The user hovers the mouse over the element
at 0.5s then removes it at 1.5s.

For the animation, we have a "from" value, a "to" value, some number
of keyframes, and a timing-function (some of these might be not be
declared, but the spec defines how to deal with that). Using these, we
can determine the exact intermediate value for the property at any
point, in the same way as the browser would determine it when
rendering a frame of the animation.

When the transition-in begins at 0.5s, it overrides the animation and
begins to change the value towards a value of #FFF. The transition-in
works similarly to the animation, in that it has a "from" value, a
declared "to" value, and a timing function. The tricky part is what
the "from" value should be. I see three possibilities:

1. Simon's suggestion of using the underlying element's value as if
the animation were not applying, e.g. the value at 0s.
2. Static target: Take the intermediate value from the animation when
the transition-in begins at 0.5s, and use this for the duration.
3. Moving target: Continuously update the "from" value using the
intermediate value from the animation throughout the transition-in.

The transition-out is similar, except the "from" value is declared,
and the "to" value is not. This adds an additional wrinkle for
approach 2. For the transition-in, we could sample the animation's
intermediate value at 0.5s, which would have to be available for
rendering, and keep hold of it. However, the static "to" value for the
transition-out would need to be the animation's value at 2s, and would
have be to be calculated ahead of time at 1.5s, when the
transition-out started. This isn't impossible, but adds a little
complexity to the implementation compared to the moving-target
approach, where the "to" value would always be the current
intermediate value from the animation.

I detailed my objections to approach no. 1 above. If this is the only
possible implementation, I would say it's better not to allow
transitions to override animations at all, as the results are not
likely to match author's requirements or expectations.

Of the remaining two, I am undecided about which would be better. I
suspect in practice there wouldn't usually be much noticeable
difference. Unless the changes applied by the animation were really
dramatic, the difference between the intermediate value at the
beginning and end of the in/out transitions probably wouldn't be that
great.

I think no. 2 would be the safest option, and the best looking in
general, but that there might be cases where 3 resulted in a slightly
better "blend" between the transition and the animation. It would be
worth experimenting with animating and transitioning different types
of property using both approaches to see what works best. Possibly the
author could be given the ability to chose between the two?

Thanks,

Jon

Received on Wednesday, 25 January 2012 18:48:21 UTC