Re: [css3-transitions][css3-animations] Cascading of animations/transitions and starting of transitions



On 4/14/13 4:10 AM, "L. David Baron" <dbaron@dbaron.org> wrote:

>On Saturday 2013-04-13 14:27 -0700, Sylvain Galineau wrote:
>> On 3/18/13 3:51 PM, "L. David Baron" <dbaron@dbaron.org> wrote:
>> >C. Determining when transitions start involves a comparison that is
>> >   (logically, at least, though not necessarily in terms of
>> >   implementation) comparing the "old" computed style for the entire
>> >   document with the "new" computed style for the entire document,
>> >   where "old" and "new" are as defined in point (A) above.  This
>> >   means that when an inherited property changes dynamically, it is
>> >   possible to start more than one transition at the same time if
>> >   'transition-property' is specified on both an ancestor and
>> >   descendant for that property.  Such transitions will execute
>> >   simultaneously; if the descendant transition finishes first, the
>> >   element will end up inheriting the ancestor's transition.  While
>> >   this is not necessarily a nice effect, it is the effect the
>> >   author requested.  This is part of how point (6) is addressed.
>> >   (If we can figure out how, it might be nice to let the longer
>> >   transition win, since that seems likely to produce better
>> >   results.  But I can't currently describe a model that leads to
>> >   that result.)
>> 
>> So you'd want inheritance to trigger a transition start on the
>>descendant
>> but the ancestor's inherited value to win while the latter's transition
>> runs? Why is that nicer than the current model? I don't have an opinion,
>> just curious what use-cases you have in mind.
>
>The use case I have in mind is somewhat vague; I'm having trouble
>coming up with concrete examples where it feels like a good idea
>since it seems odd to nest interactive elements.
>
>But the basic idea is that authors might specify a transition on
>something like :hover or :active with a somewhat general selector,
>e.g., all buttons of a certain style, or all "interactive sections"
>of a page.  Suppose, now, that one of the transitions is barely
>visible due to its duration (say, 100ms), while the other one is
>quite visible (say, 1s).  If this transition involves an inherited
>property (say, color, or visibility), I think the "right" way to
>combine these general styles is for the more "visible" transition to
>win, that is, the longer one.  But I don't know how to describe a
>model that produces that result.

OK, I see what you mean. It sounds like you want inherited animated
values to take precedence/mask local transitions. But then that would
not deal with the case where the inherited animating value is the less
visible effect.

Also: did we define what it means to transition to/from the 'inherit'
keyword, especially when the inherited value is also animating? I can't
recall.
   


>
>> >D. Transitioning values are inherited by descendants just like any
>> >   other values.  In other words, explicit 'inherit', or for
>> >   inherited values, lack of any cascaded value on a descendant,
>> >   leads to the transitioning value being inherited.  If, from (C),
>> >   there is a transition simultaneously running on the descendant,
>> >   that overrides the inherited value as any other specified value
>> >   does.  This is the remainder of the explanation for how point (6)
>> >   works, and also addresses point (3) in that the result of the
>> >   transition inherits just like anything else does.
>> 
>> This makes sense to me. Enabling your parenthetical preference at the
>> end of C would seem to change this though, right?
>
>It might, depending on what model was used to explain the desired
>behavior.  But I don't have a model to explain it.
>
>> Here is another scenario: while ancestor A is running a slow/long
>> transition on an inherited property like color, descendant D runs
>> a much shorter one on the same property. As D's transition completes,
>> D will be able to inherit the current value of A's slower transition:
>> does this trigger another instance of the same transition on D?
>
>I think it doesn't, which is what I want.  (I was worried briefly
>that it would, and that my proposal wouldn't be acceptable as a
>result.)  It doesn't, because I think we can assume that the end of
>the transition is associated with a change in the animation time.
>That is, for any given animation time (at least at the end of a
>transition, perhaps not at the start), the transition is either
>overriding the style or it isn't.  I agree this should be explained
>more clearly than what I wrote explained it, but I think it works,
>because of this bit that I wrote above:
>
>> >A. In order to prevent animations from triggering transitions, we
>> >   specify that the decision about whether to start a transition (in
>> >   response to a style change) involves not just a simple comparison
>> >   of the old computed style to the new computed style, but always
>> >   involves a comparison between styles that correspond to the same
>> >   animation times.
>
>-David
>
>-- 
>𝄞   L. David Baron                         http://dbaron.org/   𝄂
>𝄢   Mozilla                           http://www.mozilla.org/   𝄂

Received on Monday, 29 April 2013 17:58:56 UTC