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

I've posted about this before on the forum. See:

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
ie the css+html for a simple animation with 3 true keyframes would look

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

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

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

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

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.

On Tue, Jul 19, 2011 at 3:22 PM, Sylvain Galineau <>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 []
> *Sent:* Tuesday, July 19, 2011 11:56 AM
> *To:* Sylvain Galineau
> *Cc:*
> *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 <>
> 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 ?****
> ** **

Received on Tuesday, 19 July 2011 23:35:48 UTC