Re: CSS Animations Targeting SVG attributes

On 15/03/2011, at 9:05 AM, Tab Atkins Jr. wrote:

> On Mon, Mar 14, 2011 at 2:05 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
>> On Tue, Mar 15, 2011 at 9:56 AM, Tab Atkins Jr. <jackalmage@gmail.com>
>> wrote:
>>> 
>>> Animations are *not* designed to handle state transitions from one
>>> value to another, and trying to use them as such is an invitation to
>>> infinite pain once you step beyond the most trivial cases.
>> 
>> Can you explain that in more detail?
> 
> Yes, though this may be best saved for my upcoming email to www-style
> about a proposal for enhanced Transitions. ^_^

Looking forward to it.

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.

> 
> 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.

> 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.

Dean

> 
> 
>>> This must
>>> be usable in Transitions as well, so we can build extensions to
>>> Transitions to make them sufficiently powerful.
>> 
>> OK, that implies a hard requirement that arbitrary CSS rules be able to
>> override any SVG attribute value. Whatever syntax you choose, that means
>> effectively minting a lot of new properties. Someone should make a list of
>> all the new properties that will be needed.
> 
> Correct, that's a hard requirement.  Cameron pointed out such a list.
> 
> 
>>> Since they only apply to SVG elements, presumably implementations can
>>> specialize and only add the necessary data structures to SVG elements,
>>> not HTML elements and similar.
>> 
>> It doesn't work like that because SVG properties can inherit through non-SVG
>> elements. Likewise you can call getComputedStyle on a non-SVG element and
>> observe non-initial values.
> 
> Darn, you're right.
> 
> ~TJ

Received on Monday, 14 March 2011 22:20:30 UTC