Re: Advanced Transitions, Targeting Individual Transition Edges

Hi Tab,

this is a very interesting proposal taht could enable some very nice effects
through use of CSS.

1. The jQuery slideIn/slideOut animations.  The mental model here is
> that these are fancy ways of transitioning to/from "display:none".
> Right now, you have to do some complex and fragile hacking of classes
> and states to make this more-or-less work with the 'animation'
> keyword; you can't simple say "any time this element goes to
> display:none, play the slideOut animation for it".
>

Having the ability to specify 'display: none' or 'block' is something that
was requested before.
I see that you're using it here and in a couple of other places. Do you
believe that it should be added to the list of properties that can be
animated?
I think it would be a very usefull addition...


>
> Right now, keyframes animations are absolute, in that you must fill in
> all values at the time of defining the keyframe.  This is very
> limiting - it means you can't create a general "pulse" animation that
> makes an element get slightly wider and narrower, for example;
> instead, you have to create individual pulse animations for every
> box-size you want to animate, and you have to remember to change the
> animation if the size of the box is changed.  If the box size is
> dynamic, you're screwed.
>

FWIW
@-webkit-keyframes myanim {

from { -webkit-transform: scale(1, 1); }

to { -webkit-transform: scale(1.2, .8); }

with 'animation-direction: both;' would implement a 'pulse' animation
for any size.


Running an Animation on Arbitrary State Changes
> -----------------------------------------------
>
> Even with the previous addition, we still can't easily solve the
> Button use-case, because there isn't, in general, a single property
> which represents the four states with unique values, such that we can
> key some @transition rules off of it.  We can possibly hack this in by
> using some property that we very barely alter (like changing the text
> color from #000000 to #000001 to represent going from normal=>hover),
> but that's nasty.
>
> To fix this, I propose that we add a set of user-extensible properties
> to CSS that can take arbitrary values.  These will have absolutely no
> effect on any type of rendering; they are to be used solely for keying
> transitions off of.  (They are roughly analogous to the
> user-extensible set of data-* attributes in HTML5, intended for
> storing private app-specific data in a well-known location.)
>

Is it necessary to come up with such a general approach?
It seems only useful for buttons, checkboxes and menus. Why not predefine
this?


>
> They would be used like so:
>
> button { state-interaction: normal; }
> button:hover { state-interaction: over; }
> button:hover:active { state-interaction: down; }
> button:active { state-interaction: out; }
>
> @transition button {
>  over: state-interaction;
>  from: normal;
>  to: over;
>  ...
> }
> ...6 more transitions...
>

This is actually how Flash player works as well, except it fires transition
state events which you then handle in ActionScript.
People use this for all sorts of interesting effects.


>
> Control Over Mid-Animation Interruption
> ---------------------------------------
>
> If an animation is interrupted midway through, there are a lot of
> options for what to do.  Which one is appropriate can even vary based
> on what the new endpoint is.  For example, if you're currently
> animating from A to B, and then the user does something to make the
> value change back to A, you may want to simply reverse everything that
> has been done so far.  This may not always be true, though - say you
> have a graphic of a train on a loop of track, where the train starts
> at the top and moves down to the bottom of the loop when you hover.
> If the user just quickly hovers and unhovers, you may want the train
> to continue forward and finish the loop back, rather than reversing
> quickly.
>
> When you interrupt an A=>B transition by moving back to A, the
> reasonable options seem to be (a) reverse the transition, or (b)
> continue the transition to B, then pathfind a new transition from
> B=>A.  When you interrupt an A=>B transition by moving to C, the
> reasonable options seem to be (a) continue the transition to B, then
> pathfind a new transition from B=>C, or (b) automatically generate a
> new transition from the interruption point to C, subbing in some
> default animation values.
>
> On a related topic, when you interrupt a transition and change to a
> new strategy, you may want a sense of "momentum", where it takes a
> moment to switch from its previous direction to the new.  This is
> basically just a transition over transitions!
>

This would be very cool!


>
> Transitions Covering Multiple Elements
> --------------------------------------
>
> For example, I've seen game UIs before where the active menu item has
> a little bobbing light thing that flits around when you change the
> active item.  I have *no* idea how to solve this.  We've put a few
> hours of thought into it, but haven't yet come up with something I'm
> too happy with.  I can present it later, though, for brainstorming
> purposes.
>

Could this simply be a running animation when the item is hovered?
like: http://mobiletest.host.adobe.com/w3c/button.html

Rik