Confirmed users, Bureaucrats and Sysops emeriti
969
edits
CSS Transitions: Difference between revisions
Update broken links
(Update broken links) |
|||
| (5 intermediate revisions by 2 users not shown) | |||
| 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. | ||
** [[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 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. | ||
** [[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 | ||
** [[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. | ||
= 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 [[ | 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 | ||
| Line 92: | Line 95: | ||
= 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 | |||
**** [[User:Dbaron|David Baron]]: I don't think this is actually true. | |||