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

Re: transitions vs. animations

From: Simon Fraser <smfr@me.com>
Date: Mon, 05 Apr 2010 09:27:00 -0700
Cc: Anne van Kesteren <annevk@opera.com>, www-style@w3.org
Message-id: <6AFD9FA3-D9A4-45A4-969F-AB33A99AB51A@me.com>
To: Håkon Wium Lie <howcome@opera.com>
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.

Received on Monday, 5 April 2010 16:27:33 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:33 UTC