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

RE: transitions vs. animations

From: Alex Mogilevsky <alexmog@microsoft.com>
Date: Mon, 5 Apr 2010 01:05:48 +0000
To: Håkon Wium Lie <howcome@opera.com>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <CF67E24A6230D0418F669B711BD5AADB2A57F67D@TK5EX14MBXC116.redmond.corp.microsoft.com>
I didn't have an opportunity to follow this discussion closely, so perhaps anything I'll say has been said... I think this is a very important topic, and it really would be great if we came up with a unified model. 

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)

A transition is an animation that adapts to specific start and end state and transition time. An animation doesn't even have to have an end state, and if it has one it generally can't be predicted without running the animation.

Furthermore, transitions are actually triggered by end state:

	(any state A) --> transition --> (desired state B)

This is useful in particular for backwards compatibility with transition-unaware UA -- they will change the state, just no the fancy transition.
Also, since this is triggered by end state, and declared at the same point with the end state, it doesn't need to change when start state changes. That adjustment is automatic.

For the above difference, I think it is important to have a simple way to declare a transition. It is probably possible to have generic animations adjust to transition inputs but it seems pretty complicated.

There is however a large number of cases where start and end of transition is perfectly well known. Then specifying arbitrary animation in place of transition in/out of a state seems very desirable.

In Hakon's examples, I do like approaches where both animation and transitions can apply. It could be something like this (slightly modified):

/* start with a known static state - animations assume these start values */
.button {
	position:relative;
	color:blue;
	left:0;
}

/* 1. transition */
.button:hover {
	left: 10px;
	color:red;
	on-entry: transition(color, 1s), transition(left, 1s);
	on-exit: transition(color, 1s), transition(left, 1s);
}

/* 2. custom animation */
.button:hover {
	left: 10px;
	color:red;
	on-entry: animation(button_normal_to_hover); 	
	on-exit: animation(button_hover_to_normal);
}	

/* 3. custom animation - no specified end state*/
.button:hover {
	on-entry: animation(button_normal_to_hover); 	
	on-exit: animation(button_hover_to_normal);
}	

In this progression, in case (2), it is still backwards compatible, but can have arbitrary custom effects. The animation has to be manually tuned to start and end in predefined states. (3) has no effect at all for older UA but has no restrictions for end state of animation (it can be continuous and run until mouse exit).

Perhaps there is a middle ground between (2) and (3), maybe a way to tell animation-aware browser to ignore property settings.

Well, again, it is possible that I am repeating what has been said... 

Thanks
Alex

-----Original Message-----
From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of Håkon Wium Lie
Sent: Saturday, April 03, 2010 1:07 AM
To: www-style@w3.org
Subject: Re: transitions vs. animations

...

We had a productive discussion on this topic at the CSS WG F2F meeting in Cupertino. I think there's general agreement that:

  - transitions are simple, elegant, and they fit nicely into the CSS
    architecture

  - animations and keyframes are powerful...

 
Received on Monday, 5 April 2010 01:06:23 GMT

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