W3C home > Mailing lists > Public > www-style@w3.org > January 2010

Re: [css3-transitions] starting and reversing animations

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 29 Jan 2010 08:17:28 -0600
Message-ID: <dd0fbad1001290617t1a20cb88wf3114557a8431f4@mail.gmail.com>
To: news@terrainformatica.com
Cc: www-style <www-style@w3.org>
On Fri, Jan 29, 2010 at 1:11 AM, Andrew Fedoniouk
<news@terrainformatica.com> wrote:
> So you will have two transitions defined:
> div { transition: 111 }
> div:hover { transition: 222 }
> Question is which value of the transition to use when the element changes
> its :hover state.
> It appears that in your interpretation used value is the one that element
> had before changing the style and not the one that is defined
> for the element in that state.

That is indeed how it works, based on examples used in mailing lists.
An example of such would probably be good.

> If it is so than it makes sense to define this somehow.
> In any case this phrase
> "If a running transition with duration T, executing so far for duration TE,
> from state A, to state B, is interrupted by a property change that would
> start a new transition"
> somehow implies that value of the transition has immediate effect.

I'm not sure what you mean here.  That phrase just indicates some
special behavior if you, say, quickly hover and unhover an element
before its transition can complete.  If a transition is *finished*
from state A to state B, and you then go back to state A, there is no
special behavior - it's just a new transition starting.

>> I don't think that, in general, there is a coherent notion of
>> 'reverse' transitions.  Say that, in addition to the rules you had
>> above, you have the following CSS:
>> div.one { height: 200px; }
>> div.two { height: 300px; }
>> If you set the .one class programmatically, it should delay for 1s,
>> then animate to 200px height over 1s.  Then say that you add .two
>> programmatically.  It should also delay for 1s, then animate to 300px
>> height over 1s.  Now what is a reverse transition?  If you remove
>> ..two?  If you remove .two, and then remove .one?  If you remove both
>> ..one and .two at the same time?
> So we are speaking about the following style set:
> div
> {
>  width:200px;
>  height:16px;
> }
> div.one { height: 200px; }
> div.two { height: 300px; }
> div:hover
> {
>  width:300px;
>  height:100px;
>  transition: width 1s linear,
>              height 1s linear 1s;
> }

Almost.  You had the transition property applied on div previously,
rather than div:hover.

> The way I see all this:
> When @transition changes snapshot of used values and
> attributes of just applied style is taken . These values are
> used as start/end points for the transition.
> On each animation step [ani-]calculated values are applied
> on top of anything else including styles that you may set using
> script. So these values are applied as if they have !very-important
> modifier.
> If to look on the problem that way then applying
> .one class to the element programmatically will have
> no effect until animation finishes.

Do you mean that if you apply .one while in the middle of, say, a
:hover transition, that the :hover transition will still go to
completion before letting the .one have any effect?

I really don't think that's a desirable behavior.

> div.one
> {
>  height:200px;
>  transition: height 1s;
> }
> This will stop previous transition without reverting it and
> start new one with current used value as a start point.

That's how things work by default according to the draft; there's no
need to specify extra transition rules.  The element still inherits
its transition property from the "div" rule, so any change to the
transitionable properties will stop any current transitions and begin
a new one.

> It will be nice if it would be so easy.
> Consider that you have, say, these two rules
> div:hover { .... }
> div:checked { .... }
> and you want to define  different types of animations for
> :normal -> :hover and
> :normal -> :checked changes.
> Following your logic it is not possible to define different animations for
> these two distinct paths. As used value for the transition
> is not the one that defined inside :hover rule but the one that the element
> used to have. Am I correct in my understanding of your idea?

Correct - the transition property the element has *before* the change
is what's used to run the transition.  So :normal->:hover and
:normal->:checked run with the same transition function.  However, you
can have :checked->:normal and :hover->normal use different
transitions, since they start from different states.

Your proposal (gathering the transition property from the end-state)
would allow different transitions starting from normal, but would
require them to be the same returning to normal.

The two are equivalent, they just work oppositely.  The only way to
get something that handles all this ideally is to have transitions
that depend on *both* the start and end states, and that's not
currently possible with the way the draft works.

Received on Friday, 29 January 2010 14:18:20 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:13:42 UTC