Re: transitions vs. animations

On Apr 5, 2010, at 8:20 am, Håkon Wium Lie wrote:
> 
> So, to conclude, the effects are not tied to "states". Rather, the
> effect trigger when the value of the 'effect' property changes for a
> given element. When this happens, the respective 'on-exit' and
> 'on-entry' effects will be shown.

This is getting closer to a concrete proposal that I can see may be implementable.

For transitions ("on-change" in this syntax), your rule needs to be extended so say:

"Effects trigger when the value of the 'effect' property changes for a given element, or,
for on-change effects, when the value of the targeted property changes."

I'm not a bit fan of the somewhat arbitrary "on-entry tumps on-exit" rule. I think on-exit
animations in general can have unwanted behavior. You haven't thus far considered
infinitely repeating animations, but consider:

.foo {
  effect: on-exit play(spin, 1s, infinite);
}

@keyframes spin {
...
}

It seems pretty evil to me that leaving a state (or, more specifically, un-applying
the effect property) can potentially leave around an animation. There's no currently
applied style rule in the document that controls that animation, so no obvious way to stop it.

If on-exit were to be removed, then what's left here is simply a re-casting of animations
and transitions with a functional syntax.

Simon