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

Re: Proposal: will-animate property

From: Ali Juma <ajuma@chromium.org>
Date: Fri, 6 Dec 2013 15:40:53 -0500
Message-ID: <CANLC6v36Z+aKxYUd2H+vDe7dYYBKPfPZvBwMdNpoQiSrPyoSaw@mail.gmail.com>
To: "Robert O'Callahan" <robert@ocallahan.org>
Cc: Nat Duca <nduca@chromium.org>, 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>, Ojan Vafai <ojan@chromium.org>
On Fri, Dec 6, 2013 at 4:54 AM, Robert O'Callahan <robert@ocallahan.org>wrote:
>
> I'm interested in examples where the animated scene cannot easily be
> constructed by animating properties of the element that is moving, and the
> elements that will move cannot easily be identified once we know the
> elements whose properties will change, thus requiring use of
> "will-animate:positioning".
>

Consider the following example:  http://jsfiddle.net/ZQx45/24/

(Note for Firefox users: the example uses 'flex-grow', and as I discovered
after I had already put the example together, support for 'flex-grow' in
Firefox only landed earlier today. So please use a trunk build to view the
example or wait for the next Nightly -- sorry about this.)

Think of the blue boxes as representing news stories. As user expands
shrinks/expands one of the blue boxes, the other blue boxes expand/shrink
to make room. Think of the first green box as holding some images that
don't change, and think of the second green box as holding some content
that is changing frequently (maybe a scrolling stock ticker). Note that the
green boxes move as the height of the blue boxes animates. Since changing
the height of one blue box automatically also changes the height of the
other blue boxes (to make room or take up more space), achieving the same
visual effect in a way that involves changing properties of the green boxes
is not easy.

Even if we could automatically infer (from "will-animate: height" on the
blue boxes) that the green boxes would be moving, we wouldn't be able to
differentiate between the first box (whose content is fixed, and hence
worth caching in a layer) and the second box (whose contents are not fixed,
and hence wasteful to cache in a layer) without a hint from the author.
This is worth emphasizing: for elements where we get an explicit hint, we
can expect authors to use hints wisely; indeed, this is essentially the
motivation provided for "will-animate: scroll", allowing authors to point
out which overflow:auto elements are actually worth caching since just
layerizing them all might be too expensive. For elements where we're
inferring an effect, authors no longer have this discretion (and it
wouldn't be reasonable to expect them to apply discretion by first figuring
out which inferences we'd derive from their will-animate hints and then
changing their will-animate hints accordingly, especially since every UA
might do inference differently).
Received on Friday, 6 December 2013 20:41:21 UTC

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