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
them.

- 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.

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
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