Proposal: will-animate property

I'd like to propose a will-animate CSS property.

To render a web page efficiently, a web browser needs to know which parts
of the page are animated. Currently browsers have to rely on heuristics[1]
for predicting what element(s) in the page will animate in the future. When
these heuristics don't work, web authors resort to tricks to hint that
elements will animate[2]. Mispredictions are costly and will depend on the
implementation. Typically these will result in increased memory consumption
and compositing costs for over-prediction, and skipped animation frames for
under-prediction. Indeed, a browser will need some time to prepare for an
efficient animation of an element.

The proposal is to introduce a hint that an element will animate in the
future, say as the result of user input. This will provide a hint to the
browser that it should prepare itself to animate the element. The aim is to
replace work around web authors typically use such as trying to trigger
browser heuristics[2]. To avoid tying will-animate to implementation
details of the platform the author should hint a list of animation(s) that
are expected to be applied such that appropriate caching may be performed
ahead of time. The supported hints should be 'transform, opacity, scroll'.

The new property 'will-animate' should be treated as a hint only by the
browser. This means that under certain conditions such as memory pressures
the elements can be de-optimized.
To ease optimizations, will-animate values other than 'auto' force the
element to create a stacking context.

Here's the syntax:
will-animate: [auto | [transform, |  scroll, | opacity]+ ]

In the future this proposal can be extended to cover more CSS properties.
Similarly it can be extended to cover 'will-animate: none' to hint that an
element will not animate. This would help in cases where something changes
just enough to trigger heuristics but not enough to benefit from it.

A good way to use this property is to set it a short time before the
animation starts. This lets the implementation prepare the optimization
ahead of time or possibly prepared progressively in the background.

This property is prone to abuse. But currently web authors are trying to
trick heuristics which are implementation specific and can trigger non inten
ded side effects. Browser already have to watch for abuse of these
heuristics[3]. By using a proper hinting system browsers can and should
implement their own abuse mitigation. These mitigations could be based on
the optimization costs such as limiting the amount of resources consumed by
will-animate elements or the number of elements in a page for which
will-animate will be honored. Note that any mitigation must continue to
force a stacking context.

[1] http://www.html5rocks.com/en/tutorials/speed/layers/<http://www.html5rocks.com/en/tutorials/speed/layers/#toc-layercreation>
#toc-layercreation<http://www.html5rocks.com/en/tutorials/speed/layers/#toc-layercreation>
[2] http://aerotwist.com/blog/on-translate3d-and-layer-creation-hacks/
[3]
http://hg.mozilla.org/mozilla-central/file/b9980eb88a26/layout/base/FrameLayerBuilder.cpp<http://hg.mozilla.org/mozilla-central/file/b9980eb88a26/layout/base/FrameLayerBuilder.cpp#l2219>
#l2219<http://hg.mozilla.org/mozilla-central/file/b9980eb88a26/layout/base/FrameLayerBuilder.cpp#l2219>

-Benoit Girard