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

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.

> >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 Sunday, 14 April 2013 12:48:28 UTC