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

Re: Proposal: will-animate property

From: Ali Juma <ajuma@chromium.org>
Date: Tue, 3 Dec 2013 17:06:11 -0500
Message-ID: <CANLC6v1ExcDUu2-RncpamoriboNALUbyrZqg0eGyT1_1=9t6zA@mail.gmail.com>
To: "Robert O'Callahan" <robert@ocallahan.org>
Cc: "L. David Baron" <dbaron@dbaron.org>, Benoit Girard <bgirard@mozilla.com>, Matt Woodrow <matt@mozilla.com>, Cameron McCormack <cmccormack@mozilla.com>, www-style <www-style@w3.org>, "Tab Atkins Jr." <jackalmage@gmail.com>
To see why it would helpful for some will-animate values other than "auto"
to not create a stacking context, consider the following example:

There's a list of items and a pop-up menu attached to one of them (more
generally, there might be pop-ups associated with each item). Say the
author would like be able to animate the items' positions, and also wants
the pop-up to move with its parent item and stay above the other items. In
this case, transform animations cannot be used, since applying transforms
to the items will turn them into stacking contexts, causing the pop-up to
pop underneath other items. Instead, top/left animations need to be used.
But there's still value in buffering/layerizing the items and the pop-up to
avoid re-rasterizing. The translateZ hack cannot be used (for the same
reason that transform animations cannot be), so the current hacky way to
achieve this (that is, to layerize without creating a stacking context) in
Blink is to use "-webkit-backface-visibility: hidden". For the same reasons
that "will-animate: transform" is preferable to "translateZ(0)", using
"will-animate: left" (or "will-animate: top") would be preferable to
"-webkit-backface-visibility: hidden" (and the analogous hacks in other
implementations), but for this to happen we'd need "will-animate: left" to
not create a stacking context.
Received on Tuesday, 3 December 2013 22:06:38 UTC

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