- 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
http://lists.w3.org/Archives/Public/www-style/2013Jun/0682.html
and the edits to do so were made in:
https://hg.csswg.org/drafts/rev/3379bf6d2b39
https://hg.csswg.org/drafts/rev/9f7a990bfc09
https://hg.csswg.org/drafts/rev/bf51b9779673
https://hg.csswg.org/drafts/rev/d377b9f852f3
https://hg.csswg.org/drafts/rev/1b274b3a1e4b
https://hg.csswg.org/drafts/rev/bc715cd7b08c
-David
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