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

Re: [csswg-drafts] [css-contain-3][css-animations][css-transitions] Isolate animation side-effects? (#6398)

From: andruud via GitHub <sysbot+gh@w3.org>
Date: Tue, 24 Aug 2021 15:41:32 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-904754453-1629819690-sysbot+gh@w3.org>
I've implemented a prototype of container-size-change-is-style-change-event, and so far it appears to be a win-win: it gives much more desirable web-facing behavior, and it's also much easier and less expensive to implement (avoids having to know "two layouts" as @flackr  was worried about).

Taking this into account, how about this revised proposal:

 - Let the _base style_ be the style as it would be without any animation effects, inheriting from the base style of the parent.
 - Let the _before-change style_ be the base style as of the previous style change event.
 - Let the _after-change style_ be the base style as of the current style change event.
 - Let the _animated style_ be the style as of the current style change event, _including_ all animation effects, inheriting from the parent's animated style.
   - Note: It should no longer be possible for any "not animatable" property to differ from the the corresponding base style, so no need to specify that we use computed values from the after-change style.
   - Note: Only the animated style is "seen" by layout; there is no "base layout".

 - A container size change acts as a _style change event_ within that container. This means the _base style_ of descendants _may_ be affected by animation effects that influence the container's size.

At first I was worried that this would be a problem for container units, since they act as mini-container queries that dynamically respond to _any_ change in container size. With this proposal, if you define a transition on something that uses container units, and _also_ animate the size of that container, then it would trigger a transition on each frame. However, I think this is expected and non-fatal:

 - Container units already intrinsically respond to the (animated) container size. I don't think authors need to define a transition on top of this.
 - It seems consistent with what would happen today with an animated iframe + inner viewport units. (Well, for what that's worth ...)

So to me the container units situation looks acceptable.

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

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 24 August 2021 15:41:34 UTC

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