Re: [csswg-drafts] [css-contain-2] content-visibility should pause css animations in subtree (#5611)

After chatting with @vmpstr and @chrishtr I've learned that the main goal is ensuring that when engines perform style updates in content-visibility hidden subtrees that we do not have timing dependent side effects. I.e. setting element.style.animationDuration may result in different behavior depending on when a hidden subtree cleans style. However, even if animations are paused changes to display and animation-name would have observable side effects based on when style invalidations happened unless we defer updating runing animations.

To this end I believe there are two necessary changes to achieve this behavior (which I think @birtles may have been alluding to):
1. CSS animations and transitions within currently invisible content-visibility subtrees do not update their local times until visible. As such, they do not finish or fire other events.
2. We defer [updating active css animations and transitions](https://drafts.csswg.org/css-animations-2/#animations) on currently invisible content-visibility subtrees. I.e. not only do we defer creating new animations but also removing existing animations when they disappear from the animation list or when the element is in a `display: none` subtree. (I believe in blink we may be able to do this by [deferring calling ElementAnimations::MaybeApplyPendingUpdate](https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/dom/element.cc?q=file:element%5C.cc%20CssAnimations%5C(%5C)%5C.MaybeApplyPendingUpdate)).

When the subtree becomes visible again, we would then process animation updates, creating new animations, modifying existing animations and deleting old animations.

Note: We should probably update the [starting of transitions](https://drafts.csswg.org/css-transitions-1/#starting) to define that they should not start at this time, which I believe is [consistent with elements which were display: none](https://jsbin.com/kufanec/edit?html,css,js,output). Otherwise making such a subtree could cause many transitions to start.

Orthogonally, we can decide what time animations resume at when they become visible again. I believe we have all agreed that it makes the most sense for them to keep their old start time and jump to the appropriate current time when visible again - as otherwise users would be very aware of at what threshold `content-visibility: auto` elements left the screen, making it difficult for engines to choose different thresholds.

-- 
GitHub Notification of comment by flackr
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5611#issuecomment-708863588 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 15 October 2020 02:58:05 UTC