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

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

From: Brian Birtles via GitHub <sysbot+gh@w3.org>
Date: Tue, 23 Apr 2019 00:43:38 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-485600563-1555980217-sysbot+gh@w3.org>
There is a PR for this over in #3833 but I've encountered one issue regarding `commitStyles` when updating my WIP implementation to match that PR.

Initially I argued that `commitStyles` should not flush styles first: having a method that both flushes and mutates style means that if you call `commitStyles` on a number of animations within the same frame, you end up flushing styles a lot and there's really nothing the author can do to avoid it.

In that PR I also specified that `commitStyles` should throw if any of the target elements was not [being rendered](https://html.spec.whatwg.org/#being-rendered) since we won't computed style to build on (and we won't have a computed `writing-mode` etc. in order to map logical properties to physical properties when the author specifies a list of properties).

However, that means that simple test cases like the following don't work:

```js
const div = createDiv(t);
const animation = div.animate({ opacity: 0 },  { duration: 1, fill: 'forwards' });
animation.finish();
animation.commitStyles();
```

At the point where we call `commitStyles()` we still haven't resolved style for `div` so we will think it is not rendered and hence throw.

I think it might be better to make `commitStyles()` flush style after all. Not only will it make the above test case work as expected, it will also produce less confusing results when style has not been updated yet -- i.e. you'll get the styles for this frame, not the previous frame.

It's not great for performance, but at least UAs only need to flush style, not layout.

I'd be keen to know what others think about this. I imagine @emilio might have some ideas.

(The only other alternative I can think of to this API that avoids this issue _and_ accommodates `GroupEffect`s is to record the effective animation values on the `remove` event by using some sort of map from target elements to computed style. We could possibly even add a method that takes such an event or its map and applies it to inline style directly--but all that sounds very clumsy to me.)

-- 
GitHub Notification of comment by birtles
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3689#issuecomment-485600563 using your GitHub account
Received on Tuesday, 23 April 2019 00:43:39 UTC

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