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

You still have to do selector matching and run the cascade for the nodes below A which is something user agents can skip today.

From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of Shane Stephens
Sent: Thursday, October 06, 2011 5:27 PM
To: Sylvain Galineau
Cc: Rik Cabanier; 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

I don't think that performance considerations enter into this. Whatever optimizations are made in the presence of a "display: none" subtree can continue to be made, with the results applying to animation state while the subtree root is "display: none". For example, if I've got:

<A><B><C></C></B></A>

and A is "display: none", then directly animated properties on B should report with their current interpolated values when I call getComputedStyle. However, if I'm animating the width of B and I try to getComputedStyle of C, then C's width will be auto (as currently happens for C if A is "display: none" and C doesn't explicitly set a width).

Basically I would propose that under the influence of "display: none" animations should continue to run and be allowed to start and stop. While "display: none" applies, an animation is nothing more than a timer value until getComputedStyle is called on a relevant element or "display: none" stops applying:
* if getComputedStyle is called, the explicitly animated properties are updated to their current value and the getComputedStyle algorithm runs as per normal under the conditions of "display: none" with these explicit values taken into account
* if "display: none" stops applying, the explicitly animated properties are updated to their current value and a full style recalculation occurs to the subtree (as per normal when "display: none" stops applying)

This has two desirable properties:
(1) "display: none" and animations are mutually transparent to each other
(2) there are no unexpected performance overheads when running display: none animations

Thoughts?

Cheers,
    -Shane

On Wed, Oct 5, 2011 at 10:37 PM, Sylvain Galineau <sylvaing@microsoft.com<mailto:sylvaing@microsoft.com>> wrote:
Not sure what 'evaluating the element' means; all animations for the element and its descendants stop.
________________________________
From: Rik Cabanier [cabanier@gmail.com<mailto: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<mailto: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.