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

Re: transitions vs. animations

From: Brad Kemper <brad.kemper@gmail.com>
Date: Wed, 7 Apr 2010 08:17:14 -0700
Cc: Maciej Stachowiak <mjs@apple.com>, Chris Marrin <cmarrin@apple.com>, "www-style@w3.org list" <www-style@w3.org>
Message-Id: <0695CEA6-5FD2-4498-AD03-8645A0F5E2B3@gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>

On Apr 7, 2010, at 7:52 AM, Tab Atkins Jr. wrote:

> The "play-in" and "play-during" I suggested are exactly the same as
> the current Animations draft

I'm confused. I don't see those in the Animations draft. 

> - play-in animations are just finite
> iterations, while play-during are infinite.  There is no concept of
> "events" or "states" invented to handle them; they trigger purely
> through CSS values changing, exactly like the current Animations
> draft.  

Animations play for anything that you can write a selector for, including one with no pseudo-class. The values do not need to change to trigger them; they can be there as soon as the element is loaded with its specified values. 

On April 5, you said this:

> I propose to address this use-case and solve this problem by
> explicitly separating the concepts of an animation run when an element
> enters a state, leaves a state, or is in a state.  Rather than a
> single "animation" shorthand property, and an associated set of
> "animation-*" subproperties, I propose having three shorthand
> properties, "play-in", "play-out", and "play-during".

So, yes, you are looking at states, and you are looking at when those states start and end. Since a state represented by :hover is triggered by a mouse-over (or mouse-enter) and ended by a mouse-out (or whatever), then you are in essence handling events.



Received on Wednesday, 7 April 2010 15:17:54 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:26 GMT