Re: Comments on CSS Transitions

On Thu, Feb 26, 2009 at 11:16 PM, Cameron McCormack <cam@mcc.id.au> wrote:
>  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. :))

Because many properties simply don't have a sensical transition.  For
example, transitioning from position:static to position:relative, or
display:block to display:inline.  Even one that could possibly make
sense, like display:block to display:none, still has way too many
variables to be implementable.  It's *actually* an opacity animation,
or a height animation, or what have you.  jQuery defines such a
transition (via its hide() function) to be on *all* of those at once.

> 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)?

I don't see any particular reason not to do this.

> 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.

There just aren't any aural properties currently defined as accepting
a transition.  I have a hard time imagining how that would work in any
case, but somebody more familiar

> 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.

It seems clear that transitions are triggered whenever the specified
value changes, whether through direct manipulation or through the
cascade.

The start and end values, similarly, seem to obviously be the previous
specified value, and the newly specified value.

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

It means that it doesn't bubble further up the DOM.

> '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.

It does need specification, but I suppose it would be an interpolation
between the used values.

> 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).

I agree here.  Since visibility is discrete, I would prefer it to
actually change only at the end of the transition.  Adopting this
convention would allow all other properties to be transitioned as
well.

~TJ

Received on Friday, 27 February 2009 16:53:29 UTC