W3C home > Mailing lists > Public > www-style@w3.org > December 2013

Re: Proposal: will-animate property

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 2 Dec 2013 14:39:04 -0800
Message-ID: <CAAWBYDDP73Pi_eh=K0qi5TP0wB1S5_83d3wXZ5R1rkoFhDMfqA@mail.gmail.com>
To: Benoit Girard <bgirard@mozilla.com>
Cc: www-style list <www-style@w3.org>
On Tue, Nov 26, 2013 at 12:33 PM, Benoit Girard <bgirard@mozilla.com> wrote:
> 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]+ ]

Okay, so it looks like the current syntax idea is:

will-animate: auto | <animateable-feature>+
<animateable-feature> = volatile | scroll | <property-name>

Where <property-name> is any <ident> except 'all'.

Anyone have opinions on where to put this?

Received on Monday, 2 December 2013 22:39:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:37 UTC