[css-contain-2] content-visibility should pause css animations in subtree

[vmpstr]

content-visibility property, when skipping its contents should also pause css animations, as if animation-play-state: paused has been applied to them.

This allows UA to skip work that would otherwise be necessary to keep the animations going and up to date.

/cc @chrishtr @dvoytenko

[flackr]

Does this include css transitions? I think for consistency it perhaps should, although transitions normally don't have the ability to be paused. Does this include web animations? I think it shouldn't since the web animation's lifetime is not tied to the element[1].

This does add a bit of hysteresis about whether content-visibility elements have been visible in the past. I.e. new content will not be styled so the animations won't be created until the content is first visible, and animations will start whenever any style invalidation is requested.

Pausing may make the most sense, but I think it's worth considering all of the options:

1. Pause CSS animations. This would be a fairly new behavior, would only apply to elements which had previously been visible (since only those know they have css animations), and is inconsistent with how animations normally continue on otherwise invisible elements (e.g. visibility: hidden, opacity: 0 etc) or how animations are removed on display: none elements.
2. Continue to tick animations. This would be consistent with visibility: hidden and with how web animations would continue to tick even when the contents of the subtree are skipped. Also with content-visibility: auto I believe this option makes the most sense as normally scrolling elements off screen does not pause running animations.
3. Remove animations. This would be consistent with display: none, which would likely be what a polyfill of content-visibility would do since it is conceptually closest. It also is consistent with how content which has not yet been visible does not have animations until it becomes visible.

[1] https://jsbin.com/fobafok/edit?html,css,js,output

[flackr]

Also what should happen if the subtree has not yet been visible but there is a forced style update? If we use option 1 / 2, should we create the animation at that point in time?

[vmpstr]

content-visibility doesn't actually say that we skip styling, it just tries to set itself up in a way that allows style to be skipped (ie it's a "should" language not "must"). Without any explicit mention of what happens with animations, I think the only possible interpretation is that these animations are created in the same way as if content-visibility was not present. In Chromium, this would currently be a bug. And you're right that on forced style, the animation would be created and start ticking.

The intent of pausing the animation is that it allows us to not tick the animation whether it has already been created or not. In turn, I believe this means that we can actually skip style (at least from the animations perspective)

[chrishtr]

I don't think that continuing animations while skipped is compatible with avoiding style updates for the subtree. Animations can start at times defined by the next update-the-rendering opportunity after modifying style, and if we're avoiding style recalc for performance reasons we can't say when that animation should have started.

I like the option (3) @flackr mentioned, because it's simple and matches what display: none content does.

[chrishtr]

Option (1) has an advantage though, in that any existing animation would naturally continue once it came back on-screen.

[flackr]

content-visibility doesn't actually say that we skip styling, it just tries to set itself up in a way that allows style to be skipped (ie it's a "should" language not "must"). Without any explicit mention of what happens with animations, I think the only possible interpretation is that these animations are created in the same way as if content-visibility was not present. In Chromium, this would currently be a bug. And you're right that on forced style, the animation would be created and start ticking.

The intent of pausing the animation is that it allows us to not tick the animation whether it has already been created or not. In turn, I believe this means that we can actually skip style (at least from the animations perspective)

Whether animations are created or not is developer exposed through animationstart listeners and getAnimations({subtree: true}) as well as the start time of the animation. We don't have to do regular per frame work for non-visible animations except firing event handlers when various times are reached.

I don't think that continuing animations while skipped is compatible with avoiding style updates for the subtree. Animations can start at times defined by the next update-the-rendering opportunity after modifying style, and if we're avoiding style recalc for performance reasons we can't say when that animation should have started.

Is this a reason not to do option 2? I think that option 1 and 2 have all of the same difficulties since playing or paused, animations and their start times are observable.

I like the option (3) @flackr mentioned, because it's simple and matches what display: none content does.

I think option (3) is my preferred option as well as I think it's the most internally consistent and least likely to have interop issues if/when we change when we can skip style recalcs and has no hysteresis about whether the element had been previously styled.

One potential wrinkle I just thought of is the interaction with Element.getAnimations. I assume that getAnimations({subtree: true}) should not enter hidden content-visibility subtrees, but presumably if you call Element.getAnimations on an element within the hidden content-visibility subtree it should because it needs to freshen the style of that element which will create an animation? Alternately perhaps getting all animations in a subtree is another performance pitfall similar to selecting all text?

[vmpstr]

What is the behavior of getAnimations({subtree: true}) or Element.getAnimations for display none subtrees? If option 3 is the favorite, then presumably we should do "the same thing"?

[chrishtr]

Is this a reason not to do option 2? I think that option 1 and 2 have all of the same difficulties since playing or paused, animations and their start times are observable.

I don't think option 2 is feasible at all, because it would mean we would have to compute style every time it changes, even while skipped, just in case it affected an animation.

I like the option (3) @flackr mentioned, because it's simple and matches what display: none content does.

I think option (3) is my preferred option as well as I think it's the most internally consistent and least likely to have interop issues if/when we change when we can skip style recalcs and has no hysteresis about whether the element had been previously styled.

Agree about those advantages, but the developer ergonomics might be better with option (1). I say only "might" because the hysteresis may be a problem for some developers due to the new race conditions.

One potential wrinkle I just thought of is the interaction with Element.getAnimations. I assume that getAnimations({subtree: true}) should not enter hidden content-visibility subtrees, but presumably if you call Element.getAnimations on an element within the hidden content-visibility subtree it should because it needs to freshen the style of that element which will create an animation? Alternately perhaps getting all animations in a subtree is another performance pitfall similar to selecting all text?

I think it's ok for this to just be another performance pitfall.

[birtles]

Is it possible to just not tick the animations in a content-visibility: hidden subtree, i.e. without pausing? (And not create them if they don't already exist, unless the author forced style resolution via getAnimations() etc.)

That would mean events / promise callbacks etc. would be delayed indefinitely, or until style resolution was forced, but that seems reasonable?

[chrishtr]

Hi @birtles,

Is it possible to just not tick the animations in a content-visibility: hidden subtree, i.e. without pausing? (And not create them if they don't already exist, unless the author forced style resolution via getAnimations() etc.)

That would mean events / promise callbacks etc. would be delayed indefinitely, or until style resolution was forced, but that seems reasonable?

Wouldn't not ticking be effectively the same as pausing though?

[birtles]

Wouldn't not ticking be effectively the same as pausing though?

No, because when it does resume the intervening time would have elapsed (since the animation time is based on wallclock time, regardless of whether it is ticked or not). Furthermore, the paused-state of the animation is observable using getAnimations().

[flackr]

+1, between (1) and (2) my preference would be to conceptually continue the animation (essentially (2)) making the hiding not directly observable from the animation's point of view.

[flackr]

Is this a reason not to do option 2? I think that option 1 and 2 have all of the same difficulties since playing or paused, animations and their start times are observable.

I don't think option 2 is feasible at all, because it would mean we would have to compute style every time it changes, even while skipped, just in case it affected an animation.

I'm not sure I understand this point. We would tick the animation's time, but we could leave the elements with dirty style unless it was queried. As far as I can tell, all properties which could start or stop animations are not animatable, i.e. animation-* and display are not animatable properties.

For composited animations we already only tick the time if something else requests a blink main frame so we can skip frame updates in the same way here.

[vmpstr]

I don't think option 2 is feasible at all, because it would mean we would have to compute style every time it changes, even while skipped, just in case it affected an animation.

I'm not sure I understand this point. We would tick the animation's time, but we could leave the elements with dirty style unless it was queried. As far as I can tell, all properties which could start or stop animations are not animatable, i.e. animation-* and display are not animatable properties.

The problem is that when the element is skipped, we don't process its style. This, in turn, means that if script modifies the style in such a way that some element in the subtree now has an animation, then we don't know about this unless we always keep style clean. This is also true if script modifies an element in such a way that, say, increases its animation duration, or adds animation-play-state: paused, or changes any other animation-affecting style.

If we don't have up-to-date style, we can only continue ticking an animation as we knew it at the time we started skipping the element (or, even worse, at the last time style was forced). This is why option 2 seems like a poor fit here.