Re: CSS Animations Targeting SVG attributes

On Mon, Mar 14, 2011 at 3:19 PM, Dean Jackson <dino@apple.com> wrote:
> Maybe it is the example you gave, but I'd like to point out that in my mind a button has an infinite number of states. You mentioned four, but those four are the states internal to the button. The actual document could have any number of states which include the button as a child.
>
> For example
>
> body.state-one button { }
>
> body.state-two button { }
>
> body.state-two button:hover { }
>
> body.state-two div.container.state-three button:active { }
>
> etc (obviously the classes would have more useful names in the real world)
>
> This is one of the reasons we designed transitions to be as simple as possible. It might be possible to custom-design the transitions between a few states, but rich documents quickly make this unwieldy.

I definitely agree.  I just like using the "interaction" state axis as
a very simple and immediately-graspable example that is still complex
enough to exercise the weaknesses of current Transitions and
Animations.

An element can have many state axises, defined explicitly or
implicitly by combinations of selectors.


>> Briefly, imagine a button.  There are four basic states a button can
>> be in, which I'll call "normal", "over", "down", and "out", defined by
>> the four combinations of :hover and :active that can apply at any
>> given time.  When animating the button, there are seven distinct state
>> transitions you may want to animate separately: both ways between
>> "normal" and "over, both ways between "over" and "down", both ways
>> between "down" and "out", and from "out" to "normal".
>>
>> You *cannot* create all 7 of these as animations.  It's impossible,
>> because animations are not designed to fire on transitions.  Instead,
>> CSS animations are a way of permanently (well, as long as a selector
>> matches) running a set of keyframes on an element - in other words,
>> Animations run *while* an element is in a particular state, not when
>> an element transitions between states.
>>
>> Transitions are designed (very well) to do the latter.  Their only
>> problem is that they're too weak right now - they can't accept
>> arbitrary keyframes, only the trivial one that animates the single
>> property from its start to end state,
>
> Recent builds of webkit automatically fill in missing 0% and 100% keyframes with the current style. This doesn't solve the problem, but it is handy in some cases. It allows you to use animations in more places.

Interesting.


>> and they apply this keyframe to
>> *all* state transitions along the particular state axis defined by a
>> property.  If you want different keyframes along different edges in
>> the state graph, you have to hack it in by swapping *all* the edges
>> while the element is in a particular state (for example, by setting a
>> different transition rule when the element matches :hover).
>>
>> These are all fixable problems, but they're most easily fixable within
>> the framework of Transitions, not Animations.
>
> I'll wait for your proposal, but I am worried about anything that makes transitions more complex. They don't do everything, but their simplicity is their best feature. I think they are close as enhanced as they need to be.

I agree that Transitions are well-optimized for doing what they
currently do.  I wouldn't suggest complexifying the 'transition'
property.  My proposal builds on the general model of Transitions, but
doesn't change the 'transition' property at all. (The 'transition'
property just maps into the extended syntax in a trivial way.)

~TJ

Received on Monday, 14 March 2011 22:41:54 UTC