- From: Callie Riggins via GitHub <sysbot+gh@w3.org>
- Date: Thu, 09 Mar 2023 19:57:41 +0000
- To: public-css-archive@w3.org
That's super interesting and love the direction. Thinking about it from our perspective and we wrap `startViewTransition` currently but perhaps we'd be able to look at the event trigger in a handler to know what triggered it, ie: `item1`. We generally let anything such as a button click or even history navigation trigger the `startViewTransition`, so really trying to ponder how exactly we'd know the `old-state/new-state` in that context. It is really interesting, I think in the meantime the history state or navigation api's `getState` would be a good fill-in. Also just thinking out loud but avoiding it in JS would be so great. We already have to selectively ensure that there's only a single `view-transition-name: item`. Could an approach with `view-transition-new-state: item1` or `-old-state` work? We might model that as something like this: ```tsx <a id="listing-card-link" class="list-item" href="/some-destination" style={{ '--view-transition-state="item1" }}>List Item 1</a> ``` ```css .list-item { &:focus-within { view-transition-name: item; view-transition-new-state: var(--view-transition-state); view-transition-old-state: index; } } ``` -- GitHub Notification of comment by calinoracation Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8209#issuecomment-1462688895 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 9 March 2023 19:57:43 UTC