RE: [css3-animations] display:none, visibility:hidden and animations


[Tab Atkins Jr.:]
> 
> On Wed, Oct 5, 2011 at 9:03 AM, divya manian <divya.manian@gmail.com>
> wrote:
> > On Tuesday, October 4, 2011, Tab Atkins Jr. wrote:
> >> Precisely.  JS animations work over specified values, but the
> >> principle is the same.  You know what the values are, and in the case
> >> of the display:none element itself, you're not fighting against
> >> performance optimizations either.
> >
> > What is the use case for animating elements that are display none? One
> > I can think of would be to somehow use CSS animations to update
> > (generated) content on a page and then by setting display to none, you
> > would be disrupting the update of the content. But it seems like a
> > terrible hack to do this in any case.
> 
> For example, running an animation on some content within a <details> that
> stays consistent when you open/close the element.
> 
> Unfortunately, that's probably the "subtree" case that's harder to deal
> with.
> 
I think your mental model and mine agree; but I also think the implementation 
and perf concerns voiced here are very reasonable. Fwiw, we strongly prefer 
stopping animations on elements and their children when display:none is applied 
as well. So it does come down to use-cases. And it's relatively hard to think of 
scenarios where you need properties to keep animating without any of the visible 
side-effects of doing so.

Moreover, while it may seem coherent and thus more attractive for CSS animations 
to walk and talk like their scripted equivalent, I'm not sure being a replacement
in every respect must be a goal. If a design where display:none stops animations
forces some authors to use script for some rare use-cases, so what ? Should we 
slow down display:none matching overall and make animations more burdensome in the
general use-cases they're meant to address ? When an author applies display:none to 
a rotating animated 'wait' throbber like the one in OSX and Windows 8, does she really 
expect the animation to still run in the background, burning CPU cycles and extra battery 
power for as long as the element is gone ? When developers build such effects with script 
do they *intentionally* keep their animation timer loop going after they apply 
display:none ?

So the use-cases of interest are those where stopping the animation on display:none force
the author to fall back to scripting to keep the properties computing. I can't think of
a scenario where that is critical at the moment but it could be my lack of imagination.

Received on Wednesday, 5 October 2011 17:53:35 UTC