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

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