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



On 3/18/13 3:51 PM, "L. David Baron" <dbaron@dbaron.org> wrote:

>This is a followup to the discussion in
>http://lists.w3.org/Archives/Public/www-style/2013Feb/0385.html

>about the interaction of animations and transitions in the cascade.
>I met with smfr, dino, hober, and sylvaing a few weeks ago (on
>2013-02-22) to discuss this issue further, and I wanted to describe
>some of the results of that discussion (which was still
>inconclusive, although I think we made a bunch of progress).
>
>There are really two questions that are closely tied together:
>  How transitions and animations interact in the cascade.
>  How transitions are started.
>
>Based on previous discussions in the group, we think it's important
>that:
>  1. User !important rules for properties (e.g., color) must
>     override that property in the animation without preventing the
>     rest of the animation from running.
>  2. Animations should override transitions (that is, if an
>     animation is started while a transition is running, the
>     animation should win).
>  3. Animations and transitions of inherited properties (e.g.,
>     color) should work.
>  4. When an animation is set, it should take effect immediately,
>     even if there is also a transition specified or already running.
>  5. Changes caused by animations animating should not trigger
>     transitions.

Thanks, David. It's been a while but this aligns with my recollection
of this an other discussions on the topic.

>Important things we want that are pretty much taken care of:
>  6. We don't want ridiculous numbers of transition events firing
>     when an inherited property (e.g., color) is transitioned.  This
>     should be handled just fine because we we get at most one for
>     each element that actually has a 'transition-property' property
>     set on it to transition that property.
>
>The fundamental problem we're running into is that we're having
>trouble finding *any* model to describe the interaction of
>animations and transitions and the starting of transitions that
>satisfies points 1-6 and is also sufficiently Web-compatible.  I'd
>like to avoid adding any additional constraints to the problem
>before we have a solution to the existing constraints.  (The
>Web-compatibility problem hopefully isn't that bad, since there's
>quite a bit of wiggle room since implementations have very
>significant disagreements.  However, that wiggle-room is not
>infinite.)
>
>Some examples of things we want to be interoperable (and clearly
>defined by the model in the specification) but feel like we can't
>worry too much about (in other words, we'll take whatever we get
>from a model that satisfies the above):
> 7. What happens with:
>      <span id="a">a <span id="b">b</span> a</span>
>      #a { color: green }
>      #a:hover { color: blue }
>      #a { transition: 2s color linear }
>      #b { transition: 10s color linear }
>    While we agree that the color on #a should transition over 2s,
>    and that we don't want the current WebKit behavior in which the
>    colors transition in sequence, we don't have a strong opinion on
>    whether #b transitions over 2s or 10s.  10s seems likely to be
>    easier.  (Gecko does 2s, though.)  Also consider the behavior
>    when reversing the times.  (In an ideal world, we might want to
>    take the longer time, but we don't see how to describe a model
>    that produces that result.) Also consider the behavior when the
>    color (and :hover style) are on #a's parent.
>
> 8. What happens with this harder variant of the previous case:
>      <div id="a"><div id="b"><div id="c"></div></div></div>
>      #a { font-size: 15px }
>      #a:hover { font-size: 20px }
>      #b { transition: font-size: 5s }
>      #c { width: 10em; transition: width 3s; }
>      #a:hover > #b > #c { width: 20em }
>    When #a goes into the :hover state, ignoring transitions, #c's
>    width changes due to two different reasonso
>
> 9. Consider the variant of the previous case where #a's font-size
>    was already animating:
>      <div id="b"><div id="c"></div></div>
>      @keyframes fs { from { font-size: 15px } to { font-size: 20px } }
>      #b { animation: font-size infinite alternate 2s linear }
>      #c { width: 10em; transition: width 3s }
>      #c:hover { width: 20em }
>    When #c goes into the hover state, does the animation of width
>    (a) not run (b) run but jump at the end to update to the current
>    state of the animation or (c) run without jumping?  We couldn't
>    find a model that describes (c) without a lot of complexity.
>    We'd probably prefer (a) but don't prefer it enough over (b) to
>    impose significant performance constraints on implementations.
>
>
>So here's an outline of a  proposed model that I'd like to try
>implementing (and thus test for Web-compatibility) that I think
>might satisfy constraints 1-6:
>
>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.  In other words, the "old style" used in the
>   comparison to determine whether to start a transition is old in
>   the sense of not being up-to-date in terms of style changes
>   triggered by sources other than animations, but must be
>   up-to-date in terms of animations.  This is the mechanism to
>   address requirement (5).
>
>B. The styles from animations and transitions both fit in the
>   cascade between non-!important and !important rules.  In other
>   words, the cascade is:
>     UA
>     User
>     HTML Presentation Hints
>     Author
>     Transitions
>     Animations
>     Author !important
>     User !important
>     UA !important
>   This addresses requirements (1), (2), and (4), but then requires
>   that we explain how transitions start in a way that satisfies
>   requirement (3).

OK.

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

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

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?

>
>E. Transitions "run" whether or not they are overridden in the
>   cascade.  In other words, if there is a style change that should
>   trigger a transition based on the model described, but it is
>   overriden by an animation or by an !important rule, the
>   transition still fires events and is still exposed to any other
>   APIs through which it could be detected (e.g., something
>   resulting from the Web Animations work).
>
>I'd like to try implementing this proposal in Gecko if others think it's
>a reasonable approach, though I can't promise to do so particularly
>promptly.
>
>I think advancing transitions past CR is going to require actually
>testing our solution here to see if it's Web-compatible, but it might be
>possible to move to CR at the point when we have an experimental
>implementation.
>
>Does this model seem reasonable to others?

It seems reasonable; given the relatively simple usage of
transitions/animations
on the web at the moment I cannot spot anything obviously web-incompatible
with
it either.

>
>-David
>
>-- 
>𝄞   L. David Baron                         http://dbaron.org/   𝄂
>𝄢   Mozilla                           http://www.mozilla.org/   𝄂
>

Received on Saturday, 13 April 2013 21:27:40 UTC