- From: Callie Riggins Zetino via GitHub <sysbot+gh@w3.org>
- Date: Thu, 30 Nov 2023 20:05:40 +0000
- To: public-css-archive@w3.org
Just a quick clarification on https://github.com/w3c/csswg-drafts/issues/9424 and knowing it all up front. I'm not necessarily sure that'll always be the case. The majority of our use cases would know the current type such as `SearchResults` and then we'd have a generic router implementation that at that stage would know the "to" page, ie: `home-details | experience-details`. I'm very much in favor of it being a mutable option for `type` to be able to use the `active-view-transition` to differentiate ones where we are going from specific types of pages to the other. Another use case would be someone clicks from `SearchResults` to `Profile`, we would likely use multiple "tags" on the `type`, both `['profile', 'account-page']` and try to do a Slide in from edge or similar type effect and want to use the `:active-view-transition` to do that. I think with that though my original question on https://github.com/w3c/csswg-drafts/issues/9424 would still be how do we distinguish knowing old vs new is still a question. **To re-iterate our current use-cases and strategy:** We semantically map all of our elements that _might participate_ in a View Transition. So for a `<navigation-panel>` we might set a `view-transition-name: --navigation-panel` and on a more specific surface we might have a `--details-amenities-panel`. At the time we initiate the call to `startViewTransition` we apply a class to the document that maps `--navigation-panel` to `navigation-panel` and `--details-amenities-panel` to `details-panel`. Sometimes we might have to map `navigation-panel` to a different component on old vs new, old might map to `--navigation-panel` and new might map `navigation-panel` to `--amenities-navigation-panel`. We _do_ at our current stage know the type of animation we want to do, but as we scale up I would assume we're going to want to use the more generic bits like I mention before: `profile -> search` and `search -> details -> checkout -> confirmation`. We'd want to define both a generic and specific set of configurations on those so we have a general navigation model, but also using the specificity mentioned be able to do something more specific like a Contextual Grow. The more basic navigation model would apply to all navigations for common types, and if a surface wants to "get fancy" they can be more specific and do the multiple tags for their specific flow, like `:active-view-transition(search-to-pdp, contextual-grow)`. In that case we would no longer match the generic `search-to-pdp, slide-in-from-edge` and would instead do the more fancy version. **Here are some examples so ya'll have an idea of some of what we're trying to accomplish.** https://github.com/w3c/csswg-drafts/assets/23196205/f55ec350-dd3c-4614-a620-07de593e43e5 https://github.com/w3c/csswg-drafts/assets/23196205/8f037bc9-fdbb-43e5-bcfe-87849274fa02 https://github.com/w3c/csswg-drafts/assets/23196205/7bf1ac64-24f4-4f27-873c-599dd92342e8 -- GitHub Notification of comment by calinoracation Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9526#issuecomment-1834466688 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 30 November 2023 20:05:43 UTC