- From: Bramus via GitHub <sysbot+gh@w3.org>
- Date: Wed, 06 Nov 2024 09:04:21 +0000
- To: public-css-archive@w3.org
> _([#](https://github.com/w3c/csswg-drafts/issues/10995#issuecomment-2458413542))_ Here are multi-page use cases: > > https://astro-records.pages.dev > https://spotify-astro-transitions.vercel.app Those examples can “upgrade” themselves to SPA-like behavior with the Navigation API. See https://view-transitions.chrome.dev/pagination/mpa-or-navigation-api/ for a demo where I have done so: when the Navigation API is available, it will use that and trigger same- document view-transitions. If not, it’ll fall back to cross-document view transitions. > _([#](https://github.com/w3c/csswg-drafts/issues/10995#issuecomment-2454252345))_ To avoid confusion between MPA and SPA, if `match-element` is calculated for an MPA transition, it should behave like `none` (or even fail the transition completely) and show a console warning. In that case we are special casing things on _how_ the transition was triggered, which would make `match-element` behave inconsistently. I would expect `match-element` to do what it is currently specced to do _(which is: create an internal identifier, unobservable by authors)_ regardless of the trigger. Also, an author could in some cases be fine with `match-element` giving an element an internal `view-transition-name` as part of a cross-document view-transition. The snapshotted element will simply fade out or they can target it through `view-transition-class`. Example is a list of thumbnails in which you click one thumbnail to go to the detail page (MPA): while the clicked one grows, the non-clicked ones crumble down and fall off the screen. > _([#](https://github.com/w3c/csswg-drafts/issues/10995#issuecomment-2454252345))_ `match-element` breaks the above goal, because there's no equivalent between documents. Because of this, it should be kept as an exception. Developers have already been taught to give elements between two VT-states the same `view-transition-name` for it to work properly. Building on that, I think it’s somewhat safe to assume that we can teach them to name elements – by assigning an explicit `view-transition-name` or by giving it an `[id]` – between two documents and use `auto` as much as possible. The `match-element` case should be reserved for those cases in which an author explicitly doesn’t want to use the `[id]` for whatever reason they come up with. --- Rewinding a little bit: personally I’m fine with how `auto` behaves, my main gripe is (~was) with the keyword itself as authors most likely interpret it as _“auto generate me a name”_ + it’s limited to reading the `[id]` attribute. Using `attr(id <ident>, match-element)` – which is what `auto` does – is more explicit + allows targeting other attributes. -- GitHub Notification of comment by bramus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10995#issuecomment-2459062467 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 6 November 2024 09:04:23 UTC