[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]

Yes, it looks good to me.

[birtles]

Seems fine to me.

[vmpstr]

So, to re-summarize the proposed change is the following:

Animation work is skipped in content-visibility subtrees when they are not rendered. Specifically, in the content-visibility unrendered subtree, we avoid creating animations, ticking them, and ending them.

If style is updated for any reason, the animation state is 'refreshed'

[css-meeting-bot]

The CSS Working Group just discussed [css-contain-2] content-visibility should pause css animations in subtree, and agreed to the following:

• RESOLVED: Animation work is skipped in content- visibility subtrees when they're not rendered. creating, taking, or ending animations. Animation is refreshed if recalculate

The full IRC log of that discussion

<dael> Topic: [css-contain-2] content-visibility should pause css animations in subtree
<dael> github: https://github.com/w3c/csswg-drafts/issues/5611
<dael> vmpstr: Hard to talk about this without previous one in mind. This is about skipping css animations in subtrees that are unrendered by content-visibility
<dael> vmpstr: Building toward making sure we can skip the animation work if elements are not rendered
<dael> vmpstr: Have agreement from a couple people on issue who I believe are animation experts
<dael> vmpstr: I think we should still resolve, though we haven't solved the previous issue
<dael> astearns: What's the resolution they agree on?
<dael> vmpstr: Animation work is skipped in content-visbility subtrees when they're not rendered. creating, taking, or ending animations. Animation is refreshed if recaluclate
<dael> astearns: Reasonable to me. Any concerns?
<dael> astearns: Objections?
<dael> RESOLVED: Animation work is skipped in content- visibility subtrees when they're not rendered. creating, taking, or ending animations. Animation is refreshed if recalculate
<emilio> hmm

[emilio]

Hmm, so how do we plan to deal with animations that would cause content-visibility: auto to be e.g. moved into the screen?

That seems like a reasonable use case.

[flackr]

content-visibility enforces containment, so an animation within a content-visibility: auto subtree wouldnt' be able to move its parent (the element with content-visibility) onscreen would it?

[emilio]

I guess so, yeah, that's a good point, nevermind then :)

[tabatkins]

Rereading the above thread, I'm not 100% clear on whether the animation events should fire when animations are refreshed. The start and end events are obviously relevant, but what about iteration events? Should we fire multiple of them if several iterations occurred between refreshing?

[flackr]

IMO, we should fire a single animationiteration just as we do if you background a tab running an animation and come back to it, e.g. https://jsbin.com/cacakeq/edit?html,css,js,output

[tabatkins]

Ah, excellent, that's a great precedent. Thanks!

[tabatkins]

Okay, draft spec text is up; you can check it at https://github.com/w3c/csswg-drafts/commit/82fc7ddb1abf9ce0c3f616cbd91a0f1d2069a215.

Does this match up with what y'all are expecting? I did my best to synthesize this thread's consensus into a reasonable whole. Is there anything missing that still needs to be detailed?

[birtles]

Okay, draft spec text is up; you can check it at 82fc7dd.

Does this match up with what y'all are expecting? I did my best to synthesize this thread's consensus into a reasonable whole. Is there anything missing that still needs to be detailed?

CSS animations level 2 and CSS Transitions level 2 list out the possible events that can be dispatched for each "refresh". It might be better to refer to those definitions since they're a little more thoroughgoing (e.g. they define that if the "refresh" interval entirely covers an active interval then only start and end are fired and all iteration events are skipped).

Other than that, it looks good to me.

[chrishtr]

@tabatkins the only thing blocking closing this issue is @birtles's comment above, can you take a look?

[tabatkins]

Finally updated this, thanks.

---

Heya @birtles, this was delayed on my part because I tried yak-shaving a bunch of broken links. Animations 2 and Transitions 2 were both using anchors block to define a bunch of links as existing in Web Animations, but a lot of those links were busted. Most of them should be updated on a case-by-case basis specifying what they're for (animations or timelines is the main thing needing discrimination), but some were simply busted and I have no idea what they were meant to refer to, such as the term "sampling" which I want to use, but which literally occurs nowhere in the text of Web Anim 1, and once in a header of Web Anim 2, so I can't tell what the term is actually meant to be pointing at.

For now I've just deleted the anchors block entirely from both specs: that feature is meant to let you autolink into things that aren't bikeshedded at all. All it was doing was masking errors and making the specs look like they built clean. There's now a bunch of linking errors in both specs which could use your attention. (If all instances of a term do need to go to a specific definition, link-defaults is meant for that; it plays nicely with autolinking rather than masking errors.)

[birtles]

@tabatkins Thanks. I've had a look and fixed the links in CSS Transitions 2. I'll work on CSS Animations 2 next week.

Sampling has been replaced with referring to animations frames. I suspect I didn't understand the difference between anchors and link defaults so that makes sense as to why the broken references were never picked up. (I believe there was also a time when there was a delay in getting the autolinks database updated so I might have used anchors as a workaround for that.)

[css-meeting-bot]

The CSS Working Group just discussed CSS Animation and content-visibility, and agreed to the following:

• RESOLVED: Accept edits, if any issues open a new issue

The full IRC log of that discussion

<fantasai> Subtopic: CSS Animation and content-visibility
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/7576
<florian> github: https://github.com/w3c/csswg-drafts/issues/5611
<fantasai> florian: We had that discussion and had ar esolution, but afterwards discussion because some things weren't clear
<fantasai> florian: Tab made edits based on subsequent discussion, so had resolution on fundamentals
<fantasai> florian: but commit contains more
<fantasai> florian: I suspect it's fine, but precise thing in the spec is beyond what we resolved in
<fantasai> florian: suggestion is if you care about it, please review it, and open a new issue if you don't like it
<fantasai> RESOLVED: Accept edits, if any issues open a new issue
<TabAtkins> original edits: https://github.com/w3c/csswg-drafts/commit/82fc7ddb1abf9ce0c3f616cbd91a0f1d2069a215
<TabAtkins> subsequent edits: https://github.com/w3c/csswg-drafts/commit/1ef126260e59fb486bc3749d731b8ba22556d92a