Re: CSS Animations Targeting SVG attributes

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

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


>> 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:06:18 UTC