W3C home > Mailing lists > Public > public-css-archive@w3.org > April 2018

Re: [csswg-drafts] [web-animations-1] Define requirements for retaining animations to be returned by getAnimations

From: Brian Birtles via GitHub <sysbot+gh@w3.org>
Date: Wed, 11 Apr 2018 09:50:22 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-380394543-1523440219-sysbot+gh@w3.org>
Considering a fairly complex example. Suppose we have:

A. Forwards filling: opacity
B. Forwards filling: opacity (composite: add), transform (composite:  add)
C. Playing: transform
D. Forwards filling: transform
E. Forwards filling: background-color
F. Forwards filling: background-color (composite: add)
G. Forwards filling: background-color (composite: add)

Script has a handle to F.

`getAnimations()` in this case will return:

1. `FillAnimation` representing A and B (with *two* keyframes -- the opacity keyframe has `composite: replace` and the `transform` keyframe has `composite: add`)
2. `Animation` C
3. `FillAnimation` representing D~G (with *one* keyframe containing `transform` and `background-color` with `composite: replace`).

Internally, (3) needs to represent D+E, F, G since there is still a handle to F and script could call `cancel()` or even `play()` on F in which case the visual result will change and the result of `getAnimations()` would change.

Once script drops all references to F, the UA can collapse to the result of D+E+F+G internally. This is not observable, however.

This behavior can nest in that script could take a reference to the `FillAnimation` in (3) and then if C finishes and fills forwards `getAnimations()` would return a new single `FillAnimation` that internally recognizes that the `FillAnimation` from (3) is still alive and allows that `FillAnimation` to be independently canceled.

GitHub Notification of comment by birtles
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2054#issuecomment-380394543 using your GitHub account
Received on Wednesday, 11 April 2018 09:50:33 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:28 UTC