Re: Proposal: will-animate property

On Wed, Dec 4, 2013 at 8:57 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> I understand what you've said, but it seems a little abstract to me.
>
> Can we just defer the introduction of "will-animate:positioning" until we
> have a more concrete use-case for it, and a stronger argument that
> alternatives such as automatic inference for that use-case are not tenable?
> We can easily add it later if we need it.
>

I think the use case is situations like [1], where the actual animation is
on the green box, but layerizing the blue boxes (which are effectively
being moved) using the translateZ hack gives a roughly 10X speed up in
paint time for Blink (specifically, paint time goes from roughly
1.5ms/frame to 0.15ms/frame on my Linux desktop).

Authors will of course want to take advantage of this sort of speed up, and
we should give them a way to do so without resorting to hacks like
translateZ and without having to hackily apply a "will-animate: top" (say)
to the blue boxes, since we're trying to discourage hacks and encourage
authors to use will-animate honestly.

So I think the spec needs to address the "right" thing for authors to do
here. I don't think we want the spec to require that UAs perform inference
on will-animate values (unless there's a strong argument that this can be
done efficiently in general -- I'll leave this part of the discussion to
others, since I'm not familiar enough with the complexity of layout to
usefully contribute), so perhaps a way forward is to split off the notion
of inferred changes from actual changes, into something like
"will-effectively-animate" with allowed values "positioning" and "size".
Since "will-effectively-animate" would be a pure hint, UAs that figure out
how to do inference efficiently could ignore it altogether without any ill
effects, and it could easily be killed-off in the future if we wanted to.

[1] http://jsfiddle.net/ZQx45/14/