Re: [csswg-drafts] [web-animations-1] Alternative to FillAnimation: replace events (#3689)

Discussed this with @stephenmcgruer @flackr @graouts @majido and Olga yesterday. Summarizing some of the points:

* Changing the order of interpolation vs composition may be desirable but it does not solve the issue of filling animations (specifically it does not handle the need to retain animations with context-sensitive values such as those that use CSS variables, `em`, `rem`, `vh`, `%` units etc.) so should probably be discussed as a separate issue.
* Concern about the declarative version of `commit` -- it hides the fact that this is simply writing computed values to specified style. As a result it's not obvious that this loses information (e.g. variables, em units etc. get lost) or that it will change the layering (e.g. other animations may start overriding the result since they are higher in the cascade). Having the author apply the values to specified style makes it more obvious and makes it their responsibility.
* Long-term we probably want some other mechanism for triggering transitions from script and it's tempting to try to cover that here, but maybe this is not the right way. e.g. a proper solution might keep the result in a separate animation layer of the cascade or have some way to make that distinction observable.
* If we were to go ahead with the declarative `commit` behavior, it should probably apply at the point when the animation finishes, as opposed to when it is replaced. (And this raises questions about its relationship to `fill` as well as to any `persist()`-like functionality.)
* The above points lead us towards taking a more procedural approach to committing values for now and leaving open the door to a better way of generating transition-like animations in future.
   * (Perhaps after introducing an `interpolate()` function to CSS along with an addition mechanism such as `!add`--doing that would allow us to more faithfully retain the result of animations.)
* Ideally, the procedural approach would be an extension to `CSSStyleDeclaration`--i.e. something generally useful that makes the loss of context-sensitivity / cascade position obvious. However, this will not scale well to `GroupEffect`s.

That last point highlights a problem with the proposal in this issue: specifically the proposed replace/remove event includes a single `computedStyle` member but in future we may have `Animation`s that target multiple elements, and hence require multiple sets of `computedStyle`.

There are a few possibilities for addressing this last point:

1) Proceed with extending `CSSStyleDeclaration` and add a `computedStyle` member to `KeyframeEffect`. Script would then need to write:

    ```js
    animation.onremove = evt => {
      animation.effect.target.style.merge(animation.effect.computedStyle);
    };
    ```

    (Presumably we could make `merge()` to take an optional list of properties to merge.)

    and in a `GroupEffect` world:

    ```js
    animation.onremove = evt => {
      applyComputedStyle(animation.effect);
    };

    function applyComputedStyle(effect) {
      if (effect.children) {
        effect.children.forEach(applyComputedStyle);
      } else if (effect instanceof KeyframeEffect) {
        effect.target.style.merge(effect.computedStyle);
      }
   }
   ```

    This is pretty horrible, but at least the author is in full control of what happens and can see what is happening -- there's no magic.

2) Add a method to `Animation` to do this

    ```js
    animation.onremove = evt => {
       animation.commitStyles();
    };
    ```

    This is less obvious -- it's not clear that it's the computed style that gets applied (although "commit" does suggest something final to it) nor that it changes the composite order (although "Styles" hopefully suggests the "style" attribute, i.e. specified style). `commitResult` would address the first concern but probably obscure the latter.

    On the other hand it makes supporting `GroupEffect` much simpler--code continues to work without any changes. Furthermore, it exactly parallels the approach when persisting.

    Presumably `commitStyles` would take an optional array of longhand physical property names to clobber.

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

Received on Wednesday, 3 April 2019 04:27:17 UTC