W3C home > Mailing lists > Public > www-style@w3.org > February 2009

Comments on CSS Transitions

From: Cameron McCormack <cam@mcc.id.au>
Date: Fri, 27 Feb 2009 16:16:38 +1100
To: www-style@w3.org
Cc: www-svg@w3.org
Message-ID: <20090227051638.GA23440@arc.mcc.id.au>
Hello CSS WG.

The SVG Working Group spent some time last week reviewing the CSS
Transitions and Animations modules.  At this stage, we won’t be sending
an official single review mail from the group, but instead we’ll send
some individual comments.  Below are some comments from me on
Transitions, although it is reasonably safe to assume that other members
of the SVG WG agree with them too.  (Comments on CSS Animations are
forthcoming.)


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.


  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.


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


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.


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

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.


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.


  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.


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


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


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


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?

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


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


Thanks,

Cameron

[1] http://dev.w3.org/cvsweb/~checkout~/csswg/css3-transitions/Overview.html?rev=1.1&content-type=text/html;%20charset=iso-8859-1
[2] http://www.w3.org/TR/SVGTiny12/attributeTable.html#PropertyTable

-- 
Cameron McCormack ≝ http://mcc.id.au/
Received on Friday, 27 February 2009 05:17:31 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:16 GMT