W3C home > Mailing lists > Public > public-css-archive@w3.org > January 2021

Re: [csswg-drafts] [web-animations] Could commitStyles always write the end state of the animation? (#5394)

From: Brian Birtles via GitHub <sysbot+gh@w3.org>
Date: Wed, 13 Jan 2021 01:36:01 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-759145509-1610501760-sysbot+gh@w3.org>
I started trying to specify how the fill mode part of this works and came across a few possibilities for how this could work. I'll list them out as questions.

### 1. Does this behavior apply to just the animation on which `commitStyles` is called? Or all the animations below it in the stack?

**Suggested answer:** It should be just the animation itself.

**Rationale:** The special behavior where we re-add removed animations to the stack already only applies to the animation on which `commitStyles` is called.

For use cases where you have a lot of animations finishing at the same time that would be removed, we rely on the fact that simultaneous `remove` events are going to be dispatched in their composite order so we'd work our way up the stack and everything should behave as expected.

We should follow the same behavior for this adjustment too.

### 2. Is the adjustment to the fill mode? Or to the endpoint-exclusive timing?

This matters for a few cases.

One is if you have an animation in its delay phase with no fill mode (or a `forwards` fill mode). Does `commitStyles` act as if it has a fill mode of `both`/`backwards`?

Another is if you seek an animation past its end time. Does `commitStyles` act as if it it has a fill mode of `both`/`forwards` then too?

**Suggested answer:** The adjustment applies only to endpoint-exclusive timing.

**Rationale:**

* It's less likely to produce surprises when applied to animations in their delay phase
* As a result it's more likely to be Web compatible if we make this the default behavior (see question 4 below)
* It's more likely to produce a sane result when we introduce group effects (see question 3 below)

Unfortunately, it's a little more bit invasive than tweaking the fill mode.

### 3. Does it apply to just the root target effect, or to all descendant effects?

**Suggested answer:** All children

The previous suggestion was that this only applies to the root target effect but I think we want it to apply to all descendants.

For example if you have:

* Group effect (fillMode = "auto" → "both")
  * Child keyframe effect (fillMode = "auto" → "none", end time of keyframe effect == end time of group effect)

If we only tweak the fill mode on the root target effect, we'll fail to apply the styles from the keyframe effect, but I think the author would expect the keyframe effect to fill in this case.

Conversely, if the child keyframe effect finished _before_ the parent group effect, I think if we call `commitStyles` on the animation when it has finished, we would _not_ expect it to apply to any child keyframe effects that finished before the end of the group (or else you'd get very odd results for sequence groups).

### 4. Does this apply by default? Is there an opt-out mechanism?

There are a few possibilities here:

1. Make it opt-in with a parameter, e.g. `commitStyles({ endMode: 'extend' })`
2. Make it opt-out with a parameter, e.g. `commitStyles({ endMode: 'finish' })`
3. Make it apply only to effects whose specified fillMode is "auto" (i.e. make it opt-out but use `fillMode` as the mechanism)
4. Make it the default and wait until people complain

**Suggested answer:** 4? Keep it simple and take a risk that this is Web-compatible? 3 is also interesting as the author is making an explicit signal that the animation should not continue past the end? 3 would also allow a means of opting-out on a per-effect basis.

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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 13 January 2021 01:36:04 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 19 October 2021 01:31:38 UTC