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

Re: Proposal: will-animate property

From: Robert O'Callahan <robert@ocallahan.org>
Date: Tue, 3 Dec 2013 22:52:57 +1300
Message-ID: <CAOp6jLbd0vWsXo6VODtCgNZZDh7NKG_xOQvBz6s_nCvCtMLxLg@mail.gmail.com>
To: Dirk Schulze <dschulze@adobe.com>
Cc: "L. David Baron" <dbaron@dbaron.org>, Benoit Girard <bgirard@mozilla.com>, Ali Juma <ajuma@chromium.org>, Matt Woodrow <matt@mozilla.com>, Cameron McCormack <cmccormack@mozilla.com>, www-style <www-style@w3.org>, "Tab Atkins Jr." <jackalmage@gmail.com>
On Tue, Dec 3, 2013 at 9:47 PM, Dirk Schulze <dschulze@adobe.com> wrote:

> > It might help if you presented more specific scenarios that you're
> concerned about.
> I already did. To summarize:
> - We already have different implementations of the compositor in browsers
> - Scrolling (one gainer) is implemented differently in browsers

I don't know what you mean by "gainer" here.

Sure, scrolling and compositing work differently in different browsers, but
I don't see how that makes it dangerous to allow authors to signal an
intent to scroll a particular element. Implementations can take advantage
of that signal in different ways, or just ignore it if it doesn't matter to

- teaching authors browser specifics that they rely on later ->
> improvements on compositor and heuristics get harder

Unlike translateZ(1px) hacks, will-animate is not a browser-specific hack.
I'm not sure how your comment applies to will-animate.

- performance benefits are different depending on the platform may lead to
> things like * { will-animate: all; }

I already explained that we'll just start ignoring will-animate if a page
applies it to too many elements.

> - buffered rendering for animated transforms and filters might not be true
> for all time (see NVPath)

That's absolutely fine. If some implementations evolve to the point where
it's not helpful to know whether an element will be transformed, they can
just ignore "will-animate:transform".

You seem to think "will-animate:transform" mandates some particular
implementation strategy. It doesn't.

My personal guess is that implementations will work on the last point more
> in the next 2-3 years. Creating a stacking context would harm more at that
> time.

What's the harm of creating a stacking context? It's very cheap in Gecko.

These concerns still seem vague to me. I'd like to hear a much more
concrete example of how something could go wrong.

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
Received on Tuesday, 3 December 2013 09:53:25 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:17 UTC