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

Re: Advanced Transitions, Targeting Individual Transition Edges

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 5 Apr 2011 14:47:58 -0700
Message-ID: <BANLkTikf7eTQ0mseq1oqrqxeism8ynSDgw@mail.gmail.com>
To: Rik Cabanier <cabanier@gmail.com>
Cc: www-style list <www-style@w3.org>
On Tue, Apr 5, 2011 at 2:20 PM, Rik Cabanier <cabanier@gmail.com> wrote:
> 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...

I think that *all* properties should be transitionable.  Most don't
have special transition behavior; that's fine, we should just define
that, absent any specially-defined transition behavior, properties
like 'display' represent the source value when t=0 and the dest value
when t>0 (or source when t<1 and dest when t=1, or src when t<.5 and
dest when t>=.5, whatever).  You can then use the step timing
functions to control the animation properly.


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

True, the scale transform does indeed work for this specific case,
assuming you want it do be a purely visual pulse, not a
layout-affecting one.  Hopefully you see what I mean in general,
though - there are many other cases where you'd like to animate
something in relative terms.


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

I believe it's useful for much more than that.

For one, there are more built-in CSS-expressible states than just the
interaction ones - :disabled and :invalid, to name just two.  Authors
may want to define special transitions for moving between these states
in a similar way to what I described for moving between the
interaction-based states.

For two, full-on application-based state for widgets and such can lean
on this in the same way to define custom states based on
application-specific rules, and then hook transitions onto such state
changes.


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

Yes, I expect that being able to listen for property value changes
directly, or perhaps just state-* property value changes, would be
pretty useful for authors.  That's definitely something that can be
layered on top of this later.


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

Indeed, though it's also much more complicated.  ^_^  I'm definitely
willing to wait on this sort of control until we get more basic stuff
planned out and implemented.


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

(I can't get that page to animate well - it just does spurts of
animations every few seconds for me. ;_;)

No, I don't think so.  The element that needs to be animated is
separate from the element being hovered.  This really feels like
something substantially different from what we're discussing.  I'm not
even sure if it's solveable with a reasonable declarative extension to
CSS - it may just be something we keep in JS.

~TJ
Received on Tuesday, 5 April 2011 21:48:46 GMT

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