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

Yesterday at our sync up we discussed yet another alternative approach which is somewhat of a middle-ground between this proposal and the `FillAnimation` proposal (#3210).

The idea is something like the following:

* As with the proposal in this issue, once indefinitely filling animations are completely covered by other indefinitely filling animations, they are "replaced" (tentative name).

  (As with the proposal in this issue, this basically means canceling the animation but I don't think we want to _actually_ cancel the animation for reasons described earlier in this issue. Instead we probably want some orthogonal state to indicate that the animation is no longer effective.)

* _However,_ unlike this proposal, at the point when an animation is "replaced", a new `FillAnimation`-like object is automatically generated. That is, a read-only `Animation` that preserves the fill value in all its fidelity (e.g. responding to `font-size` and variable changes).

* The new `FillAnimation` occupies the same position in the global animation list as the replaced `Animation`.

* When a newly-generated `FillAnimation` includes the effect of an existing `FillAnimation`, the previous `FillAnimation` is also "replaced".

* A replaced `Animation` is basically useless. It's not clear if we want to be able restore it or not.
  (Supposing we did have a `persist()` / 'restore()' method on the original `Animation`, it would likely need to cancel the generated `FillAnimation`. But what if the generated `FillAnimation` had itself been replaced?)

* Calling `getAnimations()` returns said `FillAnimation` objects (excluding ones that have been since replaced).

That's a fairly high-level overview. I haven't thought through the specifics of it yet.

Advantages:

* Compared to the proposal in this issue, this alternative proposal ensures the style output is unaffected, even when using additive animation. The author doesn't need to do anything.

* Compared to the `FillAnimation` proposal, it avoids the complexity introduced by making existing `Animation` objects remain functional.

Disadvantages:

* It introduces _two_ new concepts for authors to understand: "replacing" and `FillAnimation`s. That said, many authors will never need to deal with either.

* It suffers the same problems as `FillAnimation` with regards to it being difficult to compact additive content. It will always be an incomplete solution.

* It has the same compatibility uncertainly as the proposal in this issue.

* It's a bit more magical than the proposal in this issue.

Personally, my main concern is that I'm still not sure that this alternative offers a net reduction in complexity. Although it reduces complexity surrounding existing `Animation` objects, it still includes many of the harder parts of the `FillAnimation` proposal (e.g.  generating a sensible result from `getKeyframes()` for some internal representation of an additive stack) and adds to it the complexity of the replacing functionality.

If it turns out that this proposal is comparable to the `FillAnimation` one in terms of implementation complexity, then I would lean towards the original `FillAnimation` proposal for its conceptual simplicity.

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

Received on Wednesday, 6 March 2019 08:54:40 UTC