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

Re: Advanced Transitions, Targeting Individual Transition Edges

From: Rik Cabanier <cabanier@gmail.com>
Date: Tue, 5 Apr 2011 14:20:13 -0700
Message-ID: <BANLkTimJq1NzQmPj3kJO9mqS0TbyNn9=_A@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: www-style list <www-style@w3.org>
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
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.

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

> 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

Received on Tuesday, 5 April 2011 21:20:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:49:58 UTC