- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 7 Apr 2010 08:48:10 -0700
- To: Brad Kemper <brad.kemper@gmail.com>
- Cc: Maciej Stachowiak <mjs@apple.com>, Chris Marrin <cmarrin@apple.com>, "www-style@w3.org list" <www-style@w3.org>
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