A partial archive of discourse.wicg.io as of Saturday February 24, 2024.

Add a property to control the animation outside the screen is not executed

rmli
2017-01-10

Animations that are frequently executed on the mobile side are very power hungry. But outside the screen

animation users can not see.The use of JS code can control the animation outside the screen is not

implemented, but this is too time-consuming.Consider adding an animation property that automatically

pauses the animation element beyond the screen.

demo:

animation: name duration timing-function delay iteration-count direction autostop;

transition: property duration timing-function delay autostop;

nicolasjengler
2017-01-11

I’m interested, I think this could be extremely useful but I’m seeing some edge cases, mostly with the transition property, i.e.: what happens if there’s a transition on class change, and the element happens to be outside of the viewport? Does the transition happen when that elements enters the viewport again? This can cause some confusion.

Looking forward to see where this leads.

rmli
2017-01-12

Adding this property is the hope that web developers will be able to write code with lower power

consumption. The animation element is outside the screen and does not start the animation directly.The

animation that begins within the screen, over the boundary, continues the animation,Does not produce the

boundary conditions you are considering.

The web developer should be aware of the effect of this attribute.

nicolasjengler
2017-01-12

I understand the main reason why something like this would be implemented, and I’m a fan of anything that may improve performance, yet I’m not able to completely grasp how a property like this one could work for some edge cases, like I mentioned before.

For animations this could work in a similar manner as the animation-play-state property with a paused value for elements outside the viewport and a value of running for elements that entered/are in the viewport. For linear transitions is a bit trickier, maybe the best way to approach this is to jump directly to the ending state of the transitioned properties if the element is outside the viewport? Doing nothing at all seems like a wrong way to provide a solution, and like I said, animating the transitioned properties once the element has entered the viewport can cause a lot of confusion.

rmli
2017-01-12

I understand your thoughts and agree with your concerns. animation-play-state with a paused/running value

for elements will be more clarity,maybe this requires developers to more carefully debug the animation.On

the confusion you talk about, I may think that the simple, Only concerned with the beginning of

the animation, the location of elements in the screen.If you want to control the life cycle of the animation, I

feel there will be a lot of confusion.

adamschwartz
2017-01-15

This would be a great addition. I think this would be most flexible / clear with something like a pseudo-class. So you could do something like this:

.animated {
  animation: animation-name infinite;
}

.animated:not(:contained-within-viewport) {
  animation-play-state: paused;
}
rmli
2017-02-05

Add a property with a definite meaning . Is this usage simpler?

.animated { animation: animation-name infinite autopause; }