W3C home > Mailing lists > Public > www-style@w3.org > August 2015

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

From: L. David Baron <dbaron@dbaron.org>
Date: Tue, 25 Aug 2015 14:54:21 +0200
To: www-style@w3.org
Message-ID: <20150825125421.GA26306@pescadero.dbaron.org>
To close the loop on this thread (replying to the message below,
which is
https://lists.w3.org/Archives/Public/www-style/2013Mar/0297.html ),
the group resolved to accept this proposal with modifications to
part (B), as minuted in
and the edits to do so were made in:


On Monday 2013-03-18 15:51 -0700, L. David Baron 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.
> 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/   𝄂

𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                          https://www.mozilla.org/   𝄂
             Before I built a wall I'd ask to know
             What I was walling in or walling out,
             And to whom I was like to give offense.
               - Robert Frost, Mending Wall (1914)

Received on Tuesday, 25 August 2015 12:54:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 25 August 2015 12:54:50 UTC