(WIN+Linux) CSS animations + javascript

[muselato]

I noticed that CSS animations work not in Pale Moon 27.2.1 if they are connected with change of display from "none" to "block" triggered by javascript. I haven't checked wheather it is wider problem or is valid only for this specific circumstance.
For example: https://codepen.io/pigner/pen/zwGazN or https://www.w3schools.com/w3css/tryit.asp?filename=tryw3css_tabulators_animate. The examples work not both in Windows 64 bit version of Pale Moon and in Linux version of it. The mentioned examples work in all other Windows and Linux browsers that I have tested.

[Moonchild]

Question: what animation point do you expect the browser to go from when display is "none"? By definition, its state from a layout point of view is undefined. You can't animate from an undefined to a defined state.

EDIT: just on the off-chance I was mistaken, I looked it up:
https://www.w3.org/TR/css3-transitions/ ... properties

Take note: "display" is not a css animatable property. Wouldn't make sense if it was, because changing the display property normally requires a reflow/repaint of the layout.
We are, therefore, doing things according to spec, and the W3Schools people are not following their own standards in their demo. Might want to let them know.

[GMforker]

You see this commit and a unstable version of Pale Moon.

[muselato]

"display" is not a css animatable property ...
the W3Schools people are not following their own standards

You made me uncertain because I had believed the specifications have been observed.
I know that display is not an animatable property but it is not animated in the given examples.
For example: on the W3C site, an element, display property of which is changed from none to block by javascript has a class "w3-animate-zoom" that reads:
.w3-animate-zoom {animation:animatezoom 0.6s}
@keyframes animatezoom {from {transform:scale(0)} to {transform:scale(1)}
So, transform property is animated here and the browser should animate it at the moment the element appears, in other words when its display property is changed (by javascript) from none to block. I believe that it is not against specifications? Or am I wrong?

[Moonchild]

Please see what I wrote above. Display is not an animatable CSS property. If any non-animatable css property is included, especially one that would change the layout of the page, the animation can't be properly executed and should be skipped.

@GMForker: what are you saying about that commit? That shouldn't even apply. Does it have as an unintended side-effect that this now works?

[Moonchild]

Oh, that's funny. Yeah, it looks like fixing that performance issue for non-visible elements does make these transitions possible now because the element is not considered until its display value has already changed to "block" (or other displayed value) at which point the transition becomes possible since all properties are animatable ("display" no longer changes and isn't requested for animation). I guess the unintended quirk as a result is being used in the wild then.

Ohwell, if that's the case then it will unintentionally be solved in 27.3.

[muselato]

It was still making me wonder, so I asked about the above mentioned animation elsewhere. I was referred to a W3C material (https://www.w3.org/TR/2013/WD-css3-animations-20130219/) which literally reads:

Setting the display property to ‘none’ will terminate any running animation applied to the element and its descendants. If an element has a display of ‘none’, updating display to a value other than ‘none’ will start all animations applied to the element by the ‘animation-name’ property, as well as all animations applied to descendants with display other than ‘none’.

[Moonchild]

You're right. Looks like it's part of the draft specifically, and I overlooked it because it's not in a logical place in the document.

I'm not sure when it was added but it looks like it's around the same time this was ironed out in Mozilla with bug #962594 which is the performance bug I based our patches on, here. Of note, David Baron is the Mozilla employee there that is also a co-author of the draft, so likely this was added when there was a good idea what the "implemented behavior" was going to be with browser parity.

The question was asked about the spec status in that bug but wasn't answered:

So here's an interesting question. http://dev.w3.org/csswg/css-animations/ seems to pretty explicitly say that animations don't run on display:none elements. David, what _is_ the spec status here?

Ultimately, it's still a side-effect of this performance optimization. The section right above it talks about intrinsic style and the fact that animations are only controlled by animation start and animation delay. If the intrinsic style is "none" when the animation is defined, it implies that the animation shouldn't run or start when the display changes. That's why the added sentence tacked on at the very end is very important.