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

Not sure what 'evaluating the element' means; all animations for the element and its descendants stop.
________________________________
From: Rik Cabanier [cabanier@gmail.com]
Sent: Wednesday, October 05, 2011 8:57 PM
To: Sylvain Galineau
Cc: Tab Atkins Jr.; divya manian; Brian Manthos; L. David Baron; Boris Zbarsky; www-style@w3.org
Subject: Re: [css3-animations] display:none, visibility:hidden and animations

Sylvain,

if an element's style becomes 'display: none' through a CSS animation, you will continue evaluating the element, correct?
All its children should stop and their animations should start over when the parent becomes visible again.

Rik

On Wed, Oct 5, 2011 at 10:53 AM, Sylvain Galineau <sylvaing@microsoft.com<mailto:sylvaing@microsoft.com>> wrote:

[Tab Atkins Jr.:]
>
> On Wed, Oct 5, 2011 at 9:03 AM, divya manian <divya.manian@gmail.com<mailto: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.