- From: Khushal Sagar via GitHub <sysbot+gh@w3.org>
- Date: Tue, 13 Jun 2023 22:11:04 +0000
- To: public-css-archive@w3.org
> If the author picked two different mix-blend-modes for the same element, that's kindof their problem. +1. > Option 2 seems to make sense to me? For `mix-blend-mode` yeah. Trying to think through other CSS properties which could be conceptually similar. Early on, we were debating whether effects like `filter`, `opacity` or `clip-path` should be lifted onto the `::view-transition-group` instead of baking them into the captured image. But there were use-cases where that doesn't make sense. For example, you have a widget's content being replaced with another with a slide-and-fade animation. It was common to see customization where the image does a full slide but the fade animation finishes half way through the slide, such that you see the widget contents completely midway during the slide. Now if the morphing widgets have different `opacity` values, we have 2 options: 1. `opacity` is baked into the image. Such that any fades during the transition are on top of all the effects on the element. 2. `opacity` from the element is copied over to the `::view-transition-group` and animated like `transform`. Both are valid use-cases. The spec currently does 1 but we plan to have a [mode](https://github.com/WICG/view-transitions/blob/main/explainer.md#more-granular-style-capture) to support 2. I'm convinced that `mix-blend-mode` is different from other effects since it can't be "baked" into the image. So it must be copied onto the group. But not sure if there are other properties like `mix-blend-mode`. -- GitHub Notification of comment by khushalsagar Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8962#issuecomment-1590118540 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 13 June 2023 22:11:05 UTC