Re: transitions vs. animations

On Wed, Apr 7, 2010 at 8:17 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
> 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.

Sorry, I meant that they work exactly the same as normal animations do
in the current Animations draft.  Specifying "play-in: bounce 1s;" is
exactly the same as "animation: bounce 1s;", and "play-during: bounce
1s;" is exactly the same as "animation: bounce 1s infinite;".


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

Correct; I oversimplified my explanation.  I did not intend to leave
out that edge-case.  It is definitely true for play-during animations.

I'm not sure, though, if making a play-in animation happen when the
page loads makes sense.  The Animations spec specifically calls out
this case and makes it clear that it does, but it has to handle both
continuous animations (play-during) and ones that happen when
something changes (play-in).  I think this intermixing of concepts
isn't ideal here.  For example, if I want a tooltip to spiral into
view when it has the .visible class, do I really want it to do so on
page load if, for some reason, I have a visible tooltip immediately?
I doubt it.  If play-in animations did run on page load, then I'd have
to set up a different class that just applied the spiral animation,
and set both .visible and .spiral when I'm making a tooltip show
dynamically, but only set .visible when I'm making it show
immediately.  That's not very good.

On the other hand, I might want some element to throb for attention a
few times before quieting down on page load, which would either
require play-in to work on page load, or for me to set a play-during
and then remove it after a few animationiteration events in
javascript.  The latter is okay, I think.  It's pretty trivial to
code:

$(".immediate-attention").bind('animationiteration',function(){
  var throbs = $(this).data("throbs") || 0;
  if( throbs >= 3 ) {
    $(this).removeClass('.immediate-attention');
  }
  $(this).data("throbs",throbs + 1);
});

I think I'd rather write the above code on the (rare, I think) times
when I want a finite animation to run on page load, then have to deal
with what I described above to *prevent* an animation from happening
on page load, but have it happen any other time.


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

No, I'm not.  I made this much more clear in the separate thread that
was specifically about the play-* properties.  I attempted to
re-explain it here.  Don't try to infer anything contradictory from my
original email in this thread; it was a first draft.  I recommend
taking any further discussion in this vein over to the dedicated
thread on this idea, where it's explained better and I've already
clarified the issue twice.

The fact that :hover, :focus, and :active happen to correspond to
events happening in the DOM does not have anything to do with my
proposal.  They may change the value of any of the play-* properties
on an element, which may make an animation fire, but so can any change
in what selectors match an element.  My proposal doesn't care about
the selectors at all; the only thing that matters is the value of the
animation property.

~TJ

Received on Wednesday, 7 April 2010 15:48:58 UTC