- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 14 Mar 2011 15:05:22 -0700
- 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. ~TJ
Received on Monday, 14 March 2011 22:06:18 UTC