- From: David Vest <davve@opera.com>
- Date: Thu, 03 Nov 2011 13:07:11 +0100
- To: www-style@w3.org
- Cc: rune@opera.com, oyvinds@opera.com
- Message-ID: <87fwi5pfyo.fsf@dyn101.gothenburg.osa>
Hi! There may be a need to clarify how transitions and animations interact when they are both active at the same time. In a message[1] from 2009 to www-style, Dean Jackson states that "animations trump transitions". We think we should add this information to the spec. One could argue that it is already there, since there's a diagram[3] that indicates that animations contribute to computed style. Since transitions operate on computed style one could interpret that as animations shadowing what transitions see. In other words, if animations behave as override style[2], which is what seems to be the intention, it means that what is referred to as intrinsic style in [3] is not computed style, but specified style, so the transition detection will not see computed style changes before animations are applied. (Implementation note: Firefox seems to let transitions trump animations. See first attached example. Is this deliberate for some reason?) One related issue is whether animations and transitions can exist in parallel. If a property change triggers a transition during an active animation of said property, a couple of things could happen: I. The transition take over II. The transition is run in the background and become evident when the animation is finished (granted that the transition outlives the animation) III. The transition is skipped entirely, the change is reflected after the animation has finished. (See second attached example, changing end position during the animation/transitions) Since transitions are triggered by computed style changes, and animated property values are part of computed style according to [3], transitions would not start for a property value that changes because of a change in intrinsic style when there is an animation running for that property because of what is said about declarative animations in [4]. Case: There is an ongoing transition for a property A from 0 to 1, and the transition is at 0.5 when an animation of A apply. Then, the animation will change the computed style value, but [4] says a declarative animation shouldn't start a transition. The computed style for A changes, so as far as transitions are concerned, starting a transition needs to be considered. Also, if transitions should continue to run in the background, it means you would have to have two sets of computed styles, since the transition-detection would otherwise not know what the current computed value would have been without the animated value when intrinsic style changes. Suggestions: 1. Specify that properties in CSS Animations behave as if they were set through getOverrideStyle(). 2. A transition in progress should be stopped when the computed value for the transitioned property changes because an animation apply. (Stopped in the same sense as a transition in progress from 100px to 200px would be stopped if the new computed value were not transitionable to/from pixel lengths (like auto)). 3. A transition should not trigger (or even run in the background) for a property whose value is currently being animated by an applied animation. 4. A transition should not trigger when the computed value of a property changes because an animation no longer applies. David Vest (with great help of Rune Lillesveen) [1] http://lists.w3.org/Archives/Public/www-style/2009Mar/0016.html [2] http://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-DocumentCSS [3] http://dev.w3.org/csswg/css3-animations/#animations [4] http://dev.w3.org/csswg/css3-transitions/#starting
Attachments
- text/html attachment: mail-01.html
- text/html attachment: mail-02.html
Received on Thursday, 3 November 2011 12:10:18 UTC