Re: transitions vs. animations

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

Simon

Received on Sunday, 4 April 2010 17:12:40 UTC