[csswg-drafts] [css-contain-3][css-animations][css-transitions] Isolate animation side-effects? (#6398)

andruud has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-contain-3][css-animations][css-transitions] Isolate animation side-effects? ==
(Using "animations" loosely to refer to any of CSS/Web Animations/Transitions/):

There seems to be an underlying idea in the specifications that effects caused by animations should themselves not trigger new animations. We solve this by making things "not animatable", "animation-tainted", etc. With container queries this problem becomes a bit worse, since the animated size of some element can cause the size of a sibling container (for example) to re-evaluate its container query, hence applying a totally different style to its descendants, including new `animation-` properties. Probably we need some adjustment to the specs to define what should happen when such animation properties appear (or change) because of "animated re-evaluation" of container queries.

The css-transitions spec describes some alternate-reality-styles ([before-change style](https://drafts.csswg.org/css-transitions-1/#before-change-style) and [after-change style](https://drafts.csswg.org/css-transitions-1/#after-change-style)) which is used to determine from/to values. This _does_ give a behavior for container queries, but the before/after-change styles now implicitly become before/after-change _layouts_. The before-change style is particularly painful, since we would need to do _layout_ in a world where existing animations are updated to the current time, producing different animation effects, potentially causing a change in container query evaluation results, arbitrarily modifying the "previous" style and layout. This sounds pretty complicated to me, and I thought we should explore alternatives. And even if we want to keep css-transitions as is, we probably do need some update for css-animations.

What if we isolate all side-effects that happen because of stuff that's animating, such that it can't trigger new animations:

 - Let the _base style_ be the style as it would be without _any_ animation effects applied (of any kind), inheriting from the base style of the parent.
 - Let the _before-change style_ be the base style as of the previous style change event, inheriting from the before-change style of the parent. (I.e. just remember the previous base style).
 - Let the _after-change style_ be the base style as of the _current_ style change event, inheriting from the after-change style of the parent.
 - CSS transitions are triggered using the before-change style/after-change style. (Taking into account the current effect value for re-targeting purposes. The spec already covers that, though).
 - CSS animations are triggered using the after-change style.
 - Let the _animated style_ be the style as of the current style change event, _including_ all animation effects.
 - The `animation-`/`transition-` properties are ignored on the _animated style_, hence if they appear/disappear/update because of container queries re-evaluating, then nothing happens. ("Global animation-tainting").

Not sure how web-compatible this is, or if this loses us any crucial aspect of the current specified behavior. On the other hand, the interop situation seems pretty poor in this area, and no browser seems to implement the current before/after change style correctly, so there might be wiggle-room.

At the moment I don't have any other great ideas for how to deal with animations and container queries.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6398 using your GitHub account


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

Received on Monday, 21 June 2021 13:46:23 UTC