Re: Comments on CSS Transitions

Hey Cam,

On 27/02/2009, at 4:16 PM, Cameron McCormack wrote:

> In section 2 Transitions, it says:
>
>  Normally when the value of a CSS property changes, the rendered  
> result
>  is instantly updated, with the affected elements immediately changing
>  from the old property value to the new property value.
>
> This makes it sounds like the purpose of Transitions is to affect just
> the rendered result.  Later in that section it explains, however, that
> using script to fetch the computed value of a property mid-transition
> will return the current animated value.  I suggest that instead of
> talking about the “rendered result” it talk instead about the  
> property’s
> specified value, or the about the value in the relevant style sheet.

Agreed.

>  The computed value of a property transitions over time from the old
>  value to the new value.
>
> The spec doesn’t define how the computed value comes to be set to  
> the
> current animated value of the property.  Does it modify the cascade so
> that the point at which the computed value of a property is normally
> computed is overridden with the animated value?  In SVG animation,
> property animation is effected by modifying the override style sheet  
> of
> the target element.  There may be some benefit to defining transitions
> to work the same way, here, although there is then the question of  
> what
> happens when a transition and an SVG animation are both applied to a
> particular property on a given element.  If you could define exactly  
> how
> transitions are applied, that would help us with reviewing how
> Transitions interacts with SVG animation.

[long discussion in followup messages]

>  Only animatable CSS properties can be transitioned.
>
> Why are some properties defined as animatable and others not?  In SVG
> 1.1, all CSS properties are animatable, however Transitions defines  
> only
> certain SVG properties as being animatable.  Why not use the property
> definitions from SVG to determine whether a transition can be applied
> to that property?  (Although in SVG Tiny 1.2 there are two properties
> that aren’t animatable[2], this seems like an oversight to me.  And  
> I
> guess that allowing transition-duration, etc. to be transitioned would
> be… interesting. :))

This is likely my fault when I extracted a list of properties but, as  
followups have mentioned, not all CSS properties can be smoothly  
interpolated. We currently animate 'visibility', but my preference  
would be to remove that.

I'm ok either way with this, but I'd want to make sure that:

- any jump can be clearly defined (eg. animate as a float, and all  
values < 1 take the value X)
- any property with multiple values can be given an ordering

> The model used for specifying transitions, i.e. that the
> transition-property, transition-duration, etc. properties each take a
> sequence of values, seems to prevent an author from specifying
> independent transitions.  For example, an author may want to specify:
>
>  .canmove {
>    transition-property: left;
>    transition-duration: 0.5s;
>  }
>
>  .canhide {
>    transition-property: opacity;
>    transition-duration: 0.25s;
>  }
>
> where the set of elements matched by .canmove and .canhide are
> different.  If more than one element matches both selectors, however,
> the properties from the .canhide rules will override the ones from
> .canmove.  It also means that it will be difficult to apply multiple
> style sheets with transitions (possibly from different sources) to the
> same document, without some of the transitions getting lost.  I  
> don’t
> have a specific suggestion on how to avoid this problem.

Right. I don't think there is a good solution here - it's just the way  
CSS is.

> All of the properties are defined to apply to block-level and
> inline-level elements.  SVG elements, as far as I know, are neither,
> since they don’t participate in the CSS box model.  Can you make  
> them
> apply to SVG elements too (perhaps by stating that they apply to all
> elements)?

Yes. They should apply to SVG elements too. I'll make the change.

> Also, it would seem to be useful to be able to transition properties  
> in
> non-visual media as well (e.g. transitioning aural properties), so I
> suggest that these properties apply to all media.

We can do this but, again, I want to make sure that we're not  
increasing implementation complexity for no benefit (ie. do all the  
properties have smooth interpolation). Also, in general there isn't  
much harm in starting with a small set of properties and adding to the  
list over time.

> It’s not exactly defined when transitions are triggered.  The  
> definition
> of transition-delay says:
>
>  A ‘transition-delay’ value of ‘0’ means the transition will  
> execute as
>  soon as the property is changed.
>
> There are many ways a property can be changed, including by being
> transitioned!  I imagine that you want to support
>
>  elt.style.opacity = 0;
>
> to trigger a transition for the ‘opacity’ property on the  
> element.  But
> what about modifying some other style sheet that applies to the  
> element,
> e.g. through the CSS OM?  Maybe the triggering of transitions can be
> defined in terms of when the specified value of a property changes.
> It’s also not defined exactly what values are chosen as the start/ 
> end
> points of the transition.  Perhaps this could be the specified value,
> too, although that could be a poor choice if you want to interpolate
> between a percentage and a pixel length, say.

Short answer: yes (and transitions do not trigger transitions)

Long answer: yes (see followups :)

>  This method may only be called before the TransitionEvent has been
>  dispatched via the dispatchEvent method, though it may be called
>  multiple times during that phase if necessary. If called multiple
>  times, the final invocation takes precedence.
>
> Multiple times during which phase?  This sounds like it’s talking  
> about
> something other than DOM Events phases, and if so, should probably  
> use a
> different word.

Agreed.

> The transitionend event is defined to be cancelable, but what does it
> mean to cancel this event?

Nothing, since it is for notification only. Unfortunately we do not  
undo time :)


> The content info for the event lists propertyName but not elapsedTime.
> Should elapsed time be there too?

It should.

>  The ‘transitionend’ event occurs at the completion of the  
> transition
>
> Is the event dispatched if the transition doesn’t reach its natural  
> end
> (e.g. if the ‘transition-property’ property is modified during a
> transition)?

No, and this should be clearly stated. Thanks.

> The rules for interpolating transitioned or animated values in  
> section 4
> aren’t very strictly defined.  For example, with a “space- 
> separated list
> of above”, what happens if the two lists don’t have the same  
> number of
> items?

Agreed, this needs to be clarified.


> The definition of interpolation for SVG paint servers doesn’t seem
> possible; values for ‘fill’ and ‘stroke’ are URL references  
> to paint
> server elements.  What computed value do you have mid-transition if  
> you
> are to interpolate the gradients?  (I suppose you might be able to
> construct a data: URL that represents a gradient whose stop colours  
> have
> been interpolated, but that seems a bit hacky.)

Indeed, and this is one of the reasons why I'd like to keep the  
transitioning properties as simple as possible. I think transitioning  
between solid fills is ok, but anything with a url() does not  
transition. Note that we do allow transitions between gradients (in  
CSS) if they have the same number of stops.

> ‘vertical-align’ is defined to allow keyword values to be  
> animated, but
> there’s no definition in section 4 for how to perform that
> interpolation.  Perhaps the ‘visibility’ interpolation should be  
> removed
> and replaced with something like applying the start value for times
> t ∈ [0,1) and the end value when t = 1 (assuming unit time here).

Good idea.

Dean

Received on Tuesday, 3 March 2009 21:25:44 UTC