W3C home > Mailing lists > Public > public-fx@w3.org > January to March 2011

Re: CSS Animations Targeting SVG attributes

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 14 Mar 2011 15:05:22 -0700
Message-ID: <AANLkTimhHmCvx6_mqTw3dP2xh4FkpsQWbVOKd0oBmNe9@mail.gmail.com>
To: robert@ocallahan.org
Cc: Dean Jackson <dino@apple.com>, public-fx@w3.org
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.

Received on Monday, 14 March 2011 22:06:18 UTC

This archive was generated by hypermail 2.3.1 : Monday, 22 June 2015 03:33:45 UTC