W3C home > Mailing lists > Public > www-style@w3.org > April 2010

Re: transitions vs. animations

From: Simon Fraser <smfr@me.com>
Date: Mon, 05 Apr 2010 08:14:42 -0700
Cc: Alex Mogilevsky <alexmog@microsoft.com>, Håkon Wium Lie <howcome@opera.com>, "www-style@w3.org" <www-style@w3.org>
Message-id: <C38CC5B0-A374-49E8-BBF3-D665F1EBE509@me.com>
To: Perry Smith <pedzsan@gmail.com>
On Apr 5, 2010, at 7:00 am, Perry Smith wrote:

> On Apr 4, 2010, at 8:05 PM, Alex Mogilevsky wrote:
>> One fundamental difference between transitions and animations is the definition of start and end state. Generally, it is like this:
>> 	(known state A) --> animation --> (no end state)
>> 	(known state A) --> transition --> (known state B)
> "An animation does not affect the computed value before the application of the animation, before the animation delay has expired, and after the end of the animation." [1]
> So, after the animation, the state is very well known.  It is the original state A
> On a slightly different topic but I think it might lead somewhere, I see this in the animation spec:
> "If a 0% or "from" keyframe is not specified, then the user agent constructs a 0% keyframe using the computed values of the properties being animated. If a 100% or "to" keyframe is not specified, then the user agent constructs a 100% keyframe using the computed values of the properties being animated." [2]
> There is an "issue" just after it asking about repeating animations.  But, isn't the two uses of "computed value" a mistake?  They should be "intrinsic value".

What is "intrinsic value"? http://www.w3.org/TR/CSS2/cascade.html#value-stages doesn't tell me.

>  And that would resolve the issue about repeating animations -- I think.

That section is still being worked on. I realized after I wrote it that WebKit does in fact require a 0% keyframe, but it can be empty (in which case rules apply that related to behavior when a property is not specified in all keyframes).

The point, however, is that you can leave out the value of a property from any keyframe, and then the user agent will use the current computed (intrinsic?) value for that property. This allows you to have the animation interpolate from the current value of the property, run some keyframes, and then go back to that value.

This does not, however, address the use case of keyframes for transitions. For example:

div { left: 0; }

div.bouncing {
  left: 100px;
  animation: bounce 1s;

@keyframes bounce {
  from { }
  30% { left: 80px; }
  60% { left: 120px; }
  to { }

Here, when class "bouncing" is applied to a div, the left property changes to 100px instantaneously, and then the animation starts, and uses left: 100px in the first and last keyframes. So you don't get a smooth change from 0 to 100px. (Note that if you try this in WebKit builds more than a few weeks old, you may see older, incorrect behavior.)

Received on Monday, 5 April 2010 15:15:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:44 UTC