Re: transitions vs. animations

On Apr 4, 2010, at 12:11 PM, Simon Fraser wrote:

>
> On Apr 4, 2010, at 2:50 am, Anne van Kesteren wrote:
>
>> On Sat, 03 Apr 2010 10:06:38 +0200, Håkon Wium Lie  
>> <howcome@opera.com> wrote:
>>> Then we have to attach this animation to two events: when the  
>>> element
>>> is hovered over, an and when it is un-hovered over. We'd like to do
>>> this without adding an event model to CSS. Let's make up a syntax:
>>>
>>> [example 3]
>>>
>>> .blue-box:hover {
>>>   effect: on-entry bounce 1s, on-exit bounce 1s;
>>> }
>>>
>>> The above uses two new keywords: 'on-entry', 'on-exit'. These are
>>> values on the 'effect-delay' property. That is, 'on-entry' is  
>>> equal to
>>> 0 in the current draft so that the animation starts immediately when
>>> hovering occurs. The 'on-exit' keyword has no numeric equivalent,  
>>> but
>>> is interpreted to mean that the delay should last until un-hovering
>>> occurs. In both cases, the effect will last for one second.
>>
>> I think the problem is that this proposal assumes an element can  
>> only be in one state. What if an element just matches :hover at  
>> first, but then also matches :focus? And then no longer matches  
>> either? This works fine with transitions as they are today, because  
>> it is just the property values that change and they are animated as  
>> specified by the transition properties. I don't really see how it  
>> can work with anything that assumes there's an entry and exit for a  
>> given state.
>
> I agree that attaching behavior to state changes creates problems.
>
> In the simple case, consider:
>
> .one {
>  effect: on-entry jiggle 2s, on-exit bounce 1s;
> }
>
> .two {
>  effect: on-entry sway 1s;
> }
>
> If the classname changes from  "one" to "two", do you run both  
> "bounce and "sway"? What if the classname changes from "one" to "one  
> two"? Then you just run "sway"? Now consider the classname changing  
> from none to "one two". You now run both "jiggle" and "sway".
>
> I also think that "states" here are poorly defined. Consider:
>
> .one.two {
>  effect: on-entry jiggle 1s;
> }
>
> .two.three {
>  effect: on-entry twirl 1s;
> }
>
> and the class changes from "one" to "one two three". Am I entering  
> the "one two" state, as well as entering the "two three" state?
>
> As I think was mentioned at the meeting, attaching effects to state  
> changes causes a combinatorial explosion in the number of changes  
> that an author has to deal with. I can see developers having to do  
> lots of special-casing because they only want to run an exit effect  
> on A when transitioning from A to B, and not A to C.
>
> Page authors want to think in terms of states, not in terms of state  
> changes.
>
> I also think this proposal is harder for implementors. With the  
> current transitions and animations proposals, the user agent doesn't  
> have to keep track of what selectors contribute to the current  
> style; all it cares about is that the style changed (for  
> transitions), or that the style contains a animation rules (for  
> animations).

Perhaps instead of calling them 'states' or 'state changes', call them  
'events'.  I'm new to this list so I don't understand Håkon's  
statement, "We'd like to do this without adding an event model to  
CSS."  It may be that my way of thinking opens a can of worms that has  
already been discussed.

First, it solves Simon's concerns because the event would not happen  
when a class is added or removed.

And, while it might make some people's head spin, it seems like  
calling them 'events' addresses Anne's concerns too.

Feel free to shorten my names but lets start with:
   'when-pointed-to' to mean when a person moves the mouse to a  
particular element
   'when-pointed-away-from' to mean when the mouse is moved away
   'when-focused-on' to mean when an element gains focus
   'when-focused-off' to mean when an element loses focus
   etc

Define the events as atomic -- they occur at one instant in time.   
Elements with the event handles at the time of the event get  
animated.  Adding the event handle is not retroactive in time.  And,  
the animation starts at that instant.

So, if an element has 'when-pointed-to' and 'when-focused-on', then  
when the user moves the mouse and points to the element, it starts the  
'when-pointed-to' animation.  It may be that the element gains focus  
during this animation so that animation will start when that event  
happens.

The one "ick" that I can see in this is you would also like a "stop  
any animation currently happening" as a "pseudo transition" so authors  
could clearly specify that if an animation is happening at the start  
of another, they could stop it and have only the single animation  
happening.  Another "pseudo transtion" might be to "append" the new  
animation to any currently running -- so it would start when any  
others have completed.

Perry

Received on Sunday, 4 April 2010 18:23:50 UTC