RE: [css3-animations] Effect of display:none and visibility:hidden on animations

I know Dean's proposal does not cover these scenarios today. I suggested they be addressed as part of such a proposal for that reason. I don't know what it means to say 'CSS is interpreted directly by native code in the browser'. I'm pretty sure Javascript is interpreted by native code in the browser too. I think you mean that more declarative information enables some optimizations which are much harder to achieve if the same operations are buried in JS. That is true but a) this really depends on the underlying platform and the UA b) it's not clear to me why synchronization in particular benefits more from a declarative setup.

No editability is lost; you can still read the animations back and modify them. It just so happens that launching/pausing/rewinding/forwarding arbitrary set of animations together is done through script. All things that would seem awkward to manage through CSS.

"Don't create the outer <div> and set the playstate of the all the animations to 'paused'. Once the event occurs that starts the movie, set all the animations to 'running'."
And how you do set all the animation-play-state properties to 'running' ? Through the same mechanism - script - you're trying to avoid ?

At a minimum, I don't believe authors should have to mess with display in some cases, animation-play-state in others to compose animations and synchronize them. That this may be the only way to do this today is an issue, not a solution. Whether/how the solution for synchronization scenarios is spread across CSS and Javascript should be discussed in its own thread.


From: Rik Cabanier [mailto:cabanier@gmail.com]
Sent: Tuesday, July 19, 2011 9:35 PM
To: Sylvain Galineau
Cc: www-style@w3.org
Subject: Re: [css3-animations] Effect of display:none and visibility:hidden on animations

Dean's proposal also doesn't deal with the asynchronous nature of events. It simplifies access to the existing functionality but doesn't solve its problems.

I agree that there is a need for APIs to pause and manipulate animationa (see http://lists.w3.org/Archives/Public/www-style/2011Mar/0624.html) but it would also be very helpful if there was a way to describe an animation through CSS.
The biggest advantage would be performance since the CSS is interpreted directly by native code in the browser.
Another advantage is editability. Users and design applications would be able to read the animation CSS back in and modify it. This would be impossible if animation is done through JS.
For instance animations that are generated by swiffy or smokescreen can not be read in by any other programs.


I get the part about wrapping the animations into a display:none parent (though, again, this doesn't address the perfectly reasonable use-case where you want the initial state of the animation to be visible).

Do you want the animation to run once the page loads?
In that case, just don't create the outer <div> with 'display: none'

Or do you want the whole animation to be paused to its initial state (including the subanimations)?
Don't create the outer <div> and set the playstate of the all the animations to 'paused'. Once the event occurs that starts the movie, set all the animations to 'running'.

Looking at how our flash users create content, having the movie paused is not a very common use case. Most of the time, content is put on the stage and animates immediately.
A possible exception are content preloaders but I think HTML can solve this more elegantly since it is not frame based.

Rik


On Tue, Jul 19, 2011 at 4:43 PM, Sylvain Galineau <sylvaing@microsoft.com<mailto:sylvaing@microsoft.com>> wrote:
I get the part about wrapping the animations into a display:none parent (though, again, this doesn't address the perfectly reasonable use-case where you want the initial state of the animation to be visible).

Your proposal suggests to me that we're missing an animation API. Authors shouldn't have to monkey around with display and create display:none frames for the purpose of achieving synchronization. To be more specific, I would like scenarios like these to be addressed as part of proposals such as Dean's here http://lists.w3.org/Archives/Public/www-style/2011Apr/0058.html.

From: Rik Cabanier [mailto:cabanier@gmail.com<mailto:cabanier@gmail.com>]
Sent: Tuesday, July 19, 2011 4:35 PM

To: Sylvain Galineau
Cc: www-style@w3.org<mailto:www-style@w3.org>
Subject: Re: [css3-animations] Effect of display:none and visibility:hidden on animations

I've posted about this before on the forum. See: http://lists.w3.org/Archives/Public/www-style/2011Mar/0624.html

Basically, if you have to rely on JavaScript to trigger animations, it becomes impossible to keep everything in sync because the clock keeps on ticking while your script run.
The more complicated or faster-switching your animations are. the worse this problem will become.
Having support for 'display' in the keyframes structure would do away with scripting.
ie the css+html for a simple animation with 3 true keyframes would look like:

@keyframes KF_1 {
from{ display: block;}
33%{ display: none;}
}
.k1{
animation-name: KF_1;
display: none;
}

@keyframes KF_2 {
33%{ display: block;}
66%{ display: none;}
}
.k2{
animation-name: KF_2;
display: none;
}

@keyframes KF_3 {
66%{ display: block;}
to{ display: none;}
}
.k3{
animation-name: KF_3;
display: none;
}

html:
<div style="display:none">
<img class="k1" src="frame1.svg">
<img class="k2" src="frame2.svg">
<img class="k3" src="frame3.svg">
</div>

If you now make the outer div visible, the animation will run.
The idiom will also extend if you have nested animations.

My original email also proposes to add pseudo selectors to the keyframe structure. This is just to make the notation easier and make the size of the CSS smaller.
With pseudo selectors, the example above could be described with 1 keyframe structure and 1 style.

Rik
On Tue, Jul 19, 2011 at 3:22 PM, Sylvain Galineau <sylvaing@microsoft.com<mailto:sylvaing@microsoft.com>> wrote:
I would expect the animation-play-state to be the property for this behavior as I do not think it is safe to assume that an initially suspended animation will always also be invisible.

With this caveat, I don't get how or why allowing display:none in @keyframes enables synchronization ?

From: Rik Cabanier [mailto:cabanier@gmail.com<mailto:cabanier@gmail.com>]
Sent: Tuesday, July 19, 2011 11:56 AM
To: Sylvain Galineau
Cc: www-style@w3.org<mailto:www-style@w3.org>
Subject: Re: [css3-animations] Effect of display:none and visibility:hidden on animations

I think WebKit's behavior is more useful since it lets you predefine an animation (with potentially nested animations) and then trigger it with 1 state change.

This is also why it would be very useful if 'display' was allowed in the keyframes structure. It would allow users to construct intricate animations that would stay in sync with each other.

Rik
On Sat, Jul 16, 2011 at 4:07 PM, Sylvain Galineau <sylvaing@microsoft.com<mailto:sylvaing@microsoft.com>> wrote:
The specification does not define what should happen for visibility:hidden or display:none. In the former case, one expects the animation to run and have the normal layout impact of a visibility:hidden element. This is the case in Webkit and Gecko.

There does not seem to be agreement for display:none yet; WebKit does not run the animation and applying display:none resets the animation. But getComputedStyle() indicates Gecko animates the specified properties when display is none.

WebKit's behavior is certainly performance-friendly; Gecko's is what I would expect though i.e. if my 2mn animation was script-based and the element had display:none for the first minute, setting display:block at the 61st second would reflect the state of the element at that point in the animation's timeline.

Thoughts ?