Re: Proposal: will-animate property

In discussions I've had off-list about this proposal, a couple issues have
been raised that I think ought to be discussed here.

First off, animating a property on one element can potentially affect the
layout of other elements in a way that makes it useful to treat these other
elements as animated in addition to the element whose property is changing.
More concretely, consider [1] and [2]. In both examples, the green box is
animating, but it's the blue boxes (whose position is effectively changing)
that are worth caching. Similarly, for [3], the animation on the green box
causes the effective sizes of the blue boxes to change, meaning the blue
boxes ought to be treated as if they were being animated too.

In these situations, it would be ideal if authors could simply specify the
appropriate "will-animate" property on the green box, and have
implementations infer the effect on the blue boxes. But my understanding is
that this sort of inference is, in general, too expensive to compute
on-the-fly. Without such automatic inference, the concern is that in these
situations, authors would be tempted to "lie" to us by putting a
"will-animate: top" on the blue boxes for [1] and [2], even though the top
property of the blue boxes isn't changing, to get the performance benefits
of caching the blue boxes. Similarly, authors would be tempted to put a
"will-animate: width" on the blue boxes in [3].

Since we want to encourage authors to give us truthful hints, and we also
want them to get the performance benefits that effect inference would give
without actually incurring the cost of computing inferred effects, we
should give authors a way to say what they really mean in this situation.
For example, it might be reasonable to allow "will-animate: positioning" to
mean that an element's effective position will be changing and
"will-animate: size" to mean that an element's effective size is changing.

The other issue is what to do when a property in the will-animate list is
one that's inherited (e.g. color, font-size). Should "will-animate" be
inherited too in this case (since the animation itself will be)?

Taken together with the issue of how to future-proof the stacking context
rules, all of this has me wondering whether, instead of a list containing
any property + scroll, we'd be better off starting with something more
constrained, like:

will-animate: [auto |  [ transform, | opacity, | scroll, | positioning, |
size, | appearance ]+ ]

where the presence of transform, opacity, or scroll in the list induces a
stacking context, and where "appearance" is intended to cover non-size
non-positioning changes like color and background-color.

This approach seems to cover all the use cases that have been raised in
this thread, and saves authors from potentially specifying long lists of
properties that mostly make no difference (a concern that Benoit raised
earlier). The list could still be grown in the future if implementations
find that more granularity is needed.

Thoughts?

[1] http://jsfiddle.net/ZQx45/12/
[2] http://jsfiddle.net/Z8vuU/2/
[3] http://jsfiddle.net/ZQx45/11/


On Tue, Dec 3, 2013 at 6:10 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Wed, Dec 4, 2013 at 11:06 AM, Ali Juma <ajuma@chromium.org> wrote:
>
>> To see why it would helpful for some will-animate values other than
>> "auto" to not create a stacking context, consider the following example:
>> http://jsfiddle.net/6rUyf/
>>
>> There's a list of items and a pop-up menu attached to one of them (more
>> generally, there might be pop-ups associated with each item). Say the
>> author would like be able to animate the items' positions, and also wants
>> the pop-up to move with its parent item and stay above the other items. In
>> this case, transform animations cannot be used, since applying transforms
>> to the items will turn them into stacking contexts, causing the pop-up to
>> pop underneath other items. Instead, top/left animations need to be used.
>> But there's still value in buffering/layerizing the items and the pop-up to
>> avoid re-rasterizing. The translateZ hack cannot be used (for the same
>> reason that transform animations cannot be), so the current hacky way to
>> achieve this (that is, to layerize without creating a stacking context) in
>> Blink is to use "-webkit-backface-visibility: hidden". For the same reasons
>> that "will-animate: transform" is preferable to "translateZ(0)", using
>> "will-animate: left" (or "will-animate: top") would be preferable to
>> "-webkit-backface-visibility: hidden" (and the analogous hacks in other
>> implementations), but for this to happen we'd need "will-animate: left" to
>> not create a stacking context.
>>
>
> OK, we can make will-animate:foo induce a stacking context only if foo
> does, but then I don't know how to fix the future-proofing problem. Maybe
> it isn't a big problem and we don't need to fix it.
>
> Rob
> --
> Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
> le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
> stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
> 'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
> waanndt  wyeonut  thoo mken.o w
>