- From: Khushal Sagar via GitHub <sysbot+gh@w3.org>
- Date: Thu, 22 Jun 2023 19:30:48 +0000
- To: public-css-archive@w3.org
Welp, I started a spec change for this and realized that using a single keyframe runs into an issue with animations which have only one of old/new images. The setup in the spec for opacity animations is as follows: 1. There are static UA rules [here](https://drafts.csswg.org/css-view-transitions-1/#ua-styles) which add fade-in and fade-out animations to all `::view-transition-new` and `::view-transition-old` elements respectively. This means that if a view-transition-name is only present in the old DOM (some widget is exiting the screen), it fades out in-place. And if a view-transition-name is only present in the new DOM (some widget is entering the screen), it fades in in-place. 2. There are dynamic rules [here](https://drafts.csswg.org/css-view-transitions-1/#setup-transition-pseudo-elements-algorithm:~:text=Set%20capturedElement%E2%80%99s%20view%20blend%20mode%20rule%20to%20a%20new%20CSSStyleRule%20representing%20the%20following%20CSS%2C%20and%20append%20it%20to%20document%E2%80%99s%20dynamic%20view%20transition%20style%20sheet%3A) which are generated based on the state of old/new DOM elements. Part of that is adding `mix-blend-mode: plus-lighter` to old/new pseudos if both are present. We do this dynamically to only do complex blending for the case which needs it. So we gotta go back to doing the suggestion in the first comment. The behaviour is the same as intended by this resolution, just that the exact syntax has changed. I put up a PR to avoid ambiguity about what's being proposed: https://github.com/w3c/csswg-drafts/pull/9000/. -- GitHub Notification of comment by khushalsagar Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8924#issuecomment-1603205296 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 22 June 2023 19:30:50 UTC