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

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.

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

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

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.

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?

-David

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

Received on Monday, 18 March 2013 22:52:09 UTC