CSS Transitions - Revision history

Jonathan Watt: Update broken links

2009-03-20T14:04:23Z

Update broken links

← Older revision		Revision as of 14:04, 20 March 2009
Line 55:		Line 55:

	= Comparison with SMIL animations =		= Comparison with SMIL animations =
	It would be very nice if we could share as much code as possible between the CSS Transitions feature and SMIL animation. dholbert already has a patch to animate CSS with SMIL described at [[~~SVG~~:SMIL+CSS]]. Here I'll list a few thoughts about how SMIL animation and CSS transitions compare (disclaimer: I have only read through the SMIL animation spec quickly, so I might not have a full understanding of the details of SMIL animation)		It would be very nice if we could share as much code as possible between the CSS Transitions feature and SMIL animation. dholbert already has a patch to animate CSS with SMIL described at [[SMIL:SMIL+CSS]]. Here I'll list a few thoughts about how SMIL animation and CSS transitions compare (disclaimer: I have only read through the SMIL animation spec quickly, so I might not have a full understanding of the details of SMIL animation)

	* Animation triggers are significantly different between SMIL animation and CSS transitions		* Animation triggers are significantly different between SMIL animation and CSS transitions

Dbaron: /* Under-specified Behavior */

2008-12-22T21:00:33Z

Under-specified Behavior

← Older revision		Revision as of 21:00, 22 December 2008
Line 40:		Line 40:
	** The specification requires that the computed style should return the intermediate transitioning values, but doesn't specify what value should be returned for the element.style.foo property during a transition		** The specification requires that the computed style should return the intermediate transitioning values, but doesn't specify what value should be returned for the element.style.foo property during a transition
	** Testing on webkit reveals that this value is updated to the final value immediately, but it is masked by the animated value until the animation ends. It is not animated.		** Testing on webkit reveals that this value is updated to the final value immediately, but it is masked by the animated value until the animation ends. It is not animated.
	** (I'm not sure why this is an open question; this is the only possible choice. Transitions operate on computed values; element.style.foo, which reflects the style attribute, is only one of many possible specified values. Transitions happen whenever the computed value changes; this could be a result of a change in which selectors match or a change in the style attribute or a change in a style rule. ~~-[[User:Dbaron\|David Baron]])~~		** [[User:Dbaron\|David Baron]]: I'm not sure why this is an open question; this is the only possible choice. Transitions operate on computed values; element.style.foo, which reflects the style attribute, is only one of many possible specified values. Transitions happen whenever the computed value changes; this could be a result of a change in which selectors match or a change in the style attribute or a change in a style rule.
	* ''How do you deal with subproperties that have different numbers of values?''		* ''How do you deal with subproperties that have different numbers of values?''
	** If the sub-properties are specified separately but there are unequal values specified, they should be handled in the same way that [http://www.w3.org/TR/css3-background/#layering Multiple Backgrounds] are handled in CSS3		** If the sub-properties are specified separately but there are unequal values specified, they should be handled in the same way that [http://www.w3.org/TR/css3-background/#layering Multiple Backgrounds] are handled in CSS3
Line 49:		Line 49:
	** dholbert asked about this since it could be quite complex to deal with interactions between SVG content that had both CSS Transitions and SMIL animations defined		** dholbert asked about this since it could be quite complex to deal with interactions between SVG content that had both CSS Transitions and SMIL animations defined
	** I saw some statements that implied that they should work, but when I tested CSS transitions with some SVG content on WebKit, I couldn't get it to work. I talked with Dave Hyatt, who said that it should work. But apparently only a subset of SVG CSS properties were supported (not the ones I was testing), so he added support for a few more properties while we talked.		** I saw some statements that implied that they should work, but when I tested CSS transitions with some SVG content on WebKit, I couldn't get it to work. I talked with Dave Hyatt, who said that it should work. But apparently only a subset of SVG CSS properties were supported (not the ones I was testing), so he added support for a few more properties while we talked.
	** (We decided that CSS transitions should not be triggered by any change that is itself caused by SMIL animation. However, they should definitely apply to SVG in other situations. ~~-[[User:Dbaron\|David Baron]])~~		** [[User:Dbaron\|David Baron]]: We decided that CSS transitions should not be triggered by any change that is itself caused by SMIL animation. However, they should definitely apply to SVG in other situations.
	* webkit does not support any shorthand properties for -webkit-transition-property		* webkit does not support any shorthand properties for -webkit-transition-property
	** (This would be pretty easy to support for us. ~~-[[User:Dbaron\|David Baron]])~~		** [[User:Dbaron\|David Baron]]: This would be pretty easy to support for us.
	* When animating to or from 'auto' (e.g. for the 'width' property), webkit animates, but treats 'auto' as 0 (in other words, if you don't have a transition active for width, it would end up at a different value than if a transition ''is'' active for width. This is clearly a bug). When changing the property to a percentage (e.g. width:50%), webkit does not animate at all, it just updates the value immediately to the new value.		* When animating to or from 'auto' (e.g. for the 'width' property), webkit animates, but treats 'auto' as 0 (in other words, if you don't have a transition active for width, it would end up at a different value than if a transition ''is'' active for width. This is clearly a bug). When changing the property to a percentage (e.g. width:50%), webkit does not animate at all, it just updates the value immediately to the new value.

Dbaron: /* Notes from 2008-10-30 Meeting */

2008-12-22T20:59:27Z

Notes from 2008-10-30 Meeting

← Older revision		Revision as of 20:59, 22 December 2008
Line 103:		Line 103:
	*** SMIL's animated style needs to be inherited by its children (e.g. animating font-size on the document)		*** SMIL's animated style needs to be inherited by its children (e.g. animating font-size on the document)
	*** CSS Transitions' animated style should <b>never inherit</b>, because it's inherently a per-element animation, on changes to <b>that element's</b> computed style		*** CSS Transitions' animated style should <b>never inherit</b>, because it's inherently a per-element animation, on changes to <b>that element's</b> computed style
			**** [[User:Dbaron\|David Baron]]: I don't think this is actually true.

Dbaron: /* Under-specified Behavior */

2008-12-22T20:57:43Z

Under-specified Behavior

← Older revision		Revision as of 20:57, 22 December 2008
Line 49:		Line 49:
	** dholbert asked about this since it could be quite complex to deal with interactions between SVG content that had both CSS Transitions and SMIL animations defined		** dholbert asked about this since it could be quite complex to deal with interactions between SVG content that had both CSS Transitions and SMIL animations defined
	** I saw some statements that implied that they should work, but when I tested CSS transitions with some SVG content on WebKit, I couldn't get it to work. I talked with Dave Hyatt, who said that it should work. But apparently only a subset of SVG CSS properties were supported (not the ones I was testing), so he added support for a few more properties while we talked.		** I saw some statements that implied that they should work, but when I tested CSS transitions with some SVG content on WebKit, I couldn't get it to work. I talked with Dave Hyatt, who said that it should work. But apparently only a subset of SVG CSS properties were supported (not the ones I was testing), so he added support for a few more properties while we talked.
	** (We decided that CSS transitions should not be triggered by any change that is itself caused by SMIL animation. -[[User:Dbaron\|David Baron]])		** (We decided that CSS transitions should not be triggered by any change that is itself caused by SMIL animation. However, they should definitely apply to SVG in other situations. -[[User:Dbaron\|David Baron]])
	* webkit does not support any shorthand properties for -webkit-transition-property		* webkit does not support any shorthand properties for -webkit-transition-property
	** (This would be pretty easy to support for us. -[[User:Dbaron\|David Baron]])		** (This would be pretty easy to support for us. -[[User:Dbaron\|David Baron]])

Dbaron: /* Under-specified Behavior */ answer a few questions

2008-12-22T20:55:13Z

Under-specified Behavior: answer a few questions

← Older revision		Revision as of 20:55, 22 December 2008
Line 40:		Line 40:
	** The specification requires that the computed style should return the intermediate transitioning values, but doesn't specify what value should be returned for the element.style.foo property during a transition		** The specification requires that the computed style should return the intermediate transitioning values, but doesn't specify what value should be returned for the element.style.foo property during a transition
	** Testing on webkit reveals that this value is updated to the final value immediately, but it is masked by the animated value until the animation ends. It is not animated.		** Testing on webkit reveals that this value is updated to the final value immediately, but it is masked by the animated value until the animation ends. It is not animated.
			** (I'm not sure why this is an open question; this is the only possible choice. Transitions operate on computed values; element.style.foo, which reflects the style attribute, is only one of many possible specified values. Transitions happen whenever the computed value changes; this could be a result of a change in which selectors match or a change in the style attribute or a change in a style rule. -[[User:Dbaron\|David Baron]])
	* ''How do you deal with subproperties that have different numbers of values?''		* ''How do you deal with subproperties that have different numbers of values?''
	** If the sub-properties are specified separately but there are unequal values specified, they should be handled in the same way that [http://www.w3.org/TR/css3-background/#layering Multiple Backgrounds] are handled in CSS3		** If the sub-properties are specified separately but there are unequal values specified, they should be handled in the same way that [http://www.w3.org/TR/css3-background/#layering Multiple Backgrounds] are handled in CSS3
Line 48:		Line 49:
	** dholbert asked about this since it could be quite complex to deal with interactions between SVG content that had both CSS Transitions and SMIL animations defined		** dholbert asked about this since it could be quite complex to deal with interactions between SVG content that had both CSS Transitions and SMIL animations defined
	** I saw some statements that implied that they should work, but when I tested CSS transitions with some SVG content on WebKit, I couldn't get it to work. I talked with Dave Hyatt, who said that it should work. But apparently only a subset of SVG CSS properties were supported (not the ones I was testing), so he added support for a few more properties while we talked.		** I saw some statements that implied that they should work, but when I tested CSS transitions with some SVG content on WebKit, I couldn't get it to work. I talked with Dave Hyatt, who said that it should work. But apparently only a subset of SVG CSS properties were supported (not the ones I was testing), so he added support for a few more properties while we talked.
			** (We decided that CSS transitions should not be triggered by any change that is itself caused by SMIL animation. -[[User:Dbaron\|David Baron]])
	* webkit does not support any shorthand properties for -webkit-transition-property		* webkit does not support any shorthand properties for -webkit-transition-property
			** (This would be pretty easy to support for us. -[[User:Dbaron\|David Baron]])
	* When animating to or from 'auto' (e.g. for the 'width' property), webkit animates, but treats 'auto' as 0 (in other words, if you don't have a transition active for width, it would end up at a different value than if a transition ''is'' active for width. This is clearly a bug). When changing the property to a percentage (e.g. width:50%), webkit does not animate at all, it just updates the value immediately to the new value.		* When animating to or from 'auto' (e.g. for the 'width' property), webkit animates, but treats 'auto' as 0 (in other words, if you don't have a transition active for width, it would end up at a different value than if a transition ''is'' active for width. This is clearly a bug). When changing the property to a percentage (e.g. width:50%), webkit does not animate at all, it just updates the value immediately to the new value.

Dholbert: /* Notes from 2008-10-30 Meeting */ -- Add note about SMIL and Transitions needing to insert at different points in the cascade

2008-12-15T22:22:36Z

Notes from 2008-10-30 Meeting: -- Add note about SMIL and Transitions needing to insert at different points in the cascade

← Older revision		Revision as of 22:22, 15 December 2008
Line 92:		Line 92:
	= Notes from 2008-10-30 Meeting =		= Notes from 2008-10-30 Meeting =
	* Decisions:		* Decisions:
	** Animated style should be stored in a special per-element rule node, which will be kept up-to-date by the SMIL/animation code.		** SMIL-Animated style should be stored in a special per-element rule node, which will be kept up-to-date by the SMIL/animation code.
	** This rule node fits right in the middle of the CSS cascade (overrides other style, but not <code>!important</code> styles)		** This rule node fits right in the middle of the CSS cascade (overrides other style, but not <code>!important</code> styles)
	** We'll detect style-changes that require transitions inside of <code>DidSetStyleContext()</code>		** We'll detect style-changes that require transitions inside of <code>DidSetStyleContext()</code>
	** <code>DidSetStyleContext()</code> will need to know whether it was called due to a "real" style change, or due to a style change from a transition/animation. This will hopefully prevent transitions/animations from triggering new transitions each time they update the style. :)		** <code>DidSetStyleContext()</code> will need to know whether it was called due to a "real" style change, or due to a style change from a transition/animation. This will hopefully prevent transitions/animations from triggering new transitions each time they update the style. :)
	** Initially, we won't support transitions on pseudo-elements (e.g. "first-letter")		** Initially, we won't support transitions on pseudo-elements (e.g. "first-letter")
			** <b>UPDATE</b>: SMIL and CSS Transitions <b>need to insert at different points</b> in the cascade, because:
			*** SMIL's animated style needs to be inherited by its children (e.g. animating font-size on the document)
			*** CSS Transitions' animated style should <b>never inherit</b>, because it's inherently a per-element animation, on changes to <b>that element's</b> computed style

Jonner: /* Differences in animation specifications */

2008-12-08T16:49:09Z

Differences in animation specifications

← Older revision		Revision as of 16:49, 8 December 2008
Line 79:		Line 79:
	** This essentially requires us to convert the nsCSSValue back to a string and call nsICSSDeclaration->SetPropertyValue(propId, string), which then re-parses the string into a nsCSSValue, etc...		** This essentially requires us to convert the nsCSSValue back to a string and call nsICSSDeclaration->SetPropertyValue(propId, string), which then re-parses the string into a nsCSSValue, etc...

	On the other hand, for CSS Transitions, the animation is only initiated if the computed style of an element changes ~~and~~ the animation is between the previous computed style and the new computed style. So if ~~I was~~ to use the existing SMIL/CSS framework to do the animation, I would need some general way to convert an arbitrary property's computed style value into a string (or we could add new API that would allow me to bypass the string portion and just convert directly from computed style to nsCSSValue/nsSMILValue)		On the other hand, for CSS Transitions, the animation is only initiated if the computed style of an element changes. In this case, the animation is between the previous computed style and the new computed style. So if we were going to use the existing SMIL/CSS framework to do the animation (and I do have a prototype which does this), I would need some general way to convert an arbitrary property's computed style value into a string (or we could add new API that would allow me to bypass the string portion and just convert directly from computed style to nsCSSValue/nsSMILValue, in which case we would need a general way to convert from a computed style to a nsCSSValue), and then we would follow the same code flow as described above.
	* However, even if such a general facility existed to convert from computed style back into an nsCSSValue, it seems like we would be doing quite a bit of extra work parsing, reparsing, converting, etc.		* However, even if such a general facility existed to convert from computed style back into an nsCSSValue, it seems like we would be doing quite a bit of extra work parsing, reparsing, converting, etc.
	* in the CSS transition case, it would be nice if we could interpolate the computed styles directly and then somehow set that computed style more directly rather than going through all of the intermediate parsing / conversion		* in the CSS transition case, it would be nice if we could interpolate the computed styles directly and then somehow set that computed style more directly rather than going through all of the intermediate parsing / conversion

Jonner: /* Comparison with SMIL animations */

2008-12-08T16:45:32Z

Comparison with SMIL animations

@@ Line 66: / Line 66: @@
 ** Because of this, it's not feasible for CSS animations to be treated the same way that SMIL animations are treated (e.g. all animation definitions are added to a list of animations when a document is loaded/parsed).  If we did that for CSS transitions, we could end up with thousands of elements in the animation list, and most of them would probably never be used.
 ** The approach we'll most likely need to use for CSS transitions is to detect a change in a property that has a transition applied to it.  At that point, we can dynamically create an animation that maps to a single element and property, and add it to the animation list.  Then when the animation is finished, we should remove it from the animation list.
 = Interaction with SMIL Animations in SVG content =

Dholbert: /* Notes from 2008-10-30 Meeting */

2008-10-31T02:18:56Z

Notes from 2008-10-30 Meeting

← Older revision		Revision as of 02:18, 31 October 2008
Line 76:		Line 76:
	= Notes from 2008-10-30 Meeting =		= Notes from 2008-10-30 Meeting =
	* Decisions:		* Decisions:
	** Animated style should be stored in a special per-element rule node		** Animated style should be stored in a special per-element rule node, which will be kept up-to-date by the SMIL/animation code.
	** This rule node fits right in the middle of the CSS cascade (overrides other style, but not <code>!important</code> styles)		** This rule node fits right in the middle of the CSS cascade (overrides other style, but not <code>!important</code> styles)
	** We'll detect style-changes that require transitions inside of <code>DidSetStyleContext()</code>		** We'll detect style-changes that require transitions inside of <code>DidSetStyleContext()</code>
	** <code>DidSetStyleContext()</code> will need to know whether it was called due to a "real" style change, or due to a style change from a transition/animation. This will hopefully prevent transitions/animations from triggering new transitions each time they update the style. :)		** <code>DidSetStyleContext()</code> will need to know whether it was called due to a "real" style change, or due to a style change from a transition/animation. This will hopefully prevent transitions/animations from triggering new transitions each time they update the style. :)
	** Initially, we won't support transitions on pseudo-elements (e.g. "first-letter")		** Initially, we won't support transitions on pseudo-elements (e.g. "first-letter")

Dholbert: Add a section with notes from today's meeting

2008-10-31T02:15:37Z

Add a section with notes from today's meeting

← Older revision		Revision as of 02:15, 31 October 2008
Line 73:		Line 73:
	** "Each additive animation adds its effect to the result of all sandwich layers below. A non-additive animation simply overrides the result of all lower sandwich layers."		** "Each additive animation adds its effect to the result of all sandwich layers below. A non-additive animation simply overrides the result of all lower sandwich layers."
	** "The animation first begun has lowest priority and the most recently begun animation has highest priority. When two animations start at the same moment in time, the activation order is resolved as follows: [...]")		** "The animation first begun has lowest priority and the most recently begun animation has highest priority. When two animations start at the same moment in time, the activation order is resolved as follows: [...]")

			= Notes from 2008-10-30 Meeting =
			* Decisions:
			** Animated style should be stored in a special per-element rule node
			** This rule node fits right in the middle of the CSS cascade (overrides other style, but not <code>!important</code> styles)
			** We'll detect style-changes that require transitions inside of <code>DidSetStyleContext()</code>
			** <code>DidSetStyleContext()</code> will need to know whether it was called due to a "real" style change, or due to a style change from a transition/animation. This will hopefully prevent transitions/animations from triggering new transitions each time they update the style. :)
			** Initially, we won't support transitions on pseudo-elements (e.g. "first-letter")