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>wrote:

>
> [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.
>
>
>
>