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

Re: Proposal: will-animate property

From: Robert O'Callahan <robert@ocallahan.org>
Date: Thu, 5 Dec 2013 11:00:09 +1300
Message-ID: <CAOp6jLaoB-ZZP2UsaqpHmR0fJU5hOD4CQC6nXsxRt5tsLpVx7g@mail.gmail.com>
To: Ali Juma <ajuma@chromium.org>
Cc: www-style <www-style@w3.org>, "L. David Baron" <dbaron@dbaron.org>, Benoit Girard <bgirard@mozilla.com>, Matt Woodrow <matt@mozilla.com>, Cameron McCormack <cmccormack@mozilla.com>, "Tab Atkins Jr." <jackalmage@gmail.com>
On Thu, Dec 5, 2013 at 10:35 AM, Ali Juma <ajuma@chromium.org> wrote:

> In these situations, it would be ideal if authors could simply specify the
> appropriate "will-animate" property on the green box, and have
> implementations infer the effect on the blue boxes. But my understanding is
> that this sort of inference is, in general, too expensive to compute
> on-the-fly.
>

Why?


> The other issue is what to do when a property in the will-animate list is
> one that's inherited (e.g. color, font-size). Should "will-animate" be
> inherited too in this case (since the animation itself will be)?
>

The UA can determine whether the changing font-size of the will-animate
element will be inherited. We don't need to explicitly inherit will-animate
as well.

Taken together with the issue of how to future-proof the stacking context
> rules, all of this has me wondering whether, instead of a list containing
> any property + scroll, we'd be better off starting with something more
> constrained, like:
>
> will-animate: [auto |  [ transform, | opacity, | scroll, | positioning, |
> size, | appearance ]+ ]
>
> where the presence of transform, opacity, or scroll in the list induces a
> stacking context, and where "appearance" is intended to cover non-size
> non-positioning changes like color and background-color.
>
> This approach seems to cover all the use cases that have been raised in
> this thread, and saves authors from potentially specifying long lists of
> properties that mostly make no difference (a concern that Benoit raised
> earlier). The list could still be grown in the future if implementations
> find that more granularity is needed
>

> Thoughts?
>

The problem with that approach is that when some browser adds new-property
and extends will-animate syntax to support new-property, and an author
writes "will-animate: transform, new-property", other browsers get no
will-animate at all.

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 Wednesday, 4 December 2013 22:00:37 UTC

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