- From: Jake Archibald via GitHub <sysbot+gh@w3.org>
- Date: Fri, 10 Mar 2023 09:49:52 +0000
- To: public-css-archive@w3.org
My opinion: `view-transition-name` is used to determine which elements are captured to form old/new views, and it applies the required constraints as a convenience. However, the functionality of `view-transition-name` (aside from the application of constraints) doesn't apply throughout the transition. Assuming the element is rendered & not skipped, a `view-transition-name` of not-none will enforce the constraints we require. However, I chose not to use it has a proxy, because at this stage we're kinda 'done' with `view-transition-name`. For example, once we capture the `view-transition-name` as `foo`, it creates a `foo` group. If you change the `view-transition-name` to `bar` half way through the transition, nothing happens, it's still part of the `foo` group, since that decision was made at capture time. If we make `view-transition-name` part of the requirements during the transition, we'd only be doing so in a weird half way. As in, we'd only be requiring `view-transition-name` to be set to any non-none value. We decided against making `view-transition-name` part of the checks here. Although it would be cheap to check the `view-transition-name` hasn't changed for captured elements (and skip otherwise), it'd be more expensive to check if any new `view-transition-name`s have appear, per frame. That said, my feelings here aren't super strong. -- GitHub Notification of comment by jakearchibald Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8548#issuecomment-1463545218 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 10 March 2023 09:49:54 UTC