Re: transitions vs. animations

On Apr 5, 2010, at 10:14 AM, Simon Fraser wrote:

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

Ah.  I see.  I was using "computed value" and "intrinsic value" based  
upon the diagram and text in the animation document.

In my case (I'm not proposing to use this -- just trying to clarify),  
"intrinsic value" would be what the reference above would call  
"computed" if there was no animation.  And my use of "computed" was  
the transient value(s) caused by running the animation.

Received on Monday, 5 April 2010 20:33:31 UTC