- From: Jake Archibald via GitHub <sysbot+gh@w3.org>
- Date: Thu, 19 Dec 2024 11:22:18 +0000
- To: public-css-archive@w3.org
@fantasai you've mentioned a few times that I'm not thinking about a broad range of web site builds in my arguments here. I really don't think that's the case. ## Build style 1: a component demo in codepen `match-element` and therefore `auto` works well here. However, the reason it works well is because it's a demo of a component in isolation. Once you try and make it work as part of a page, you run into issues relating to view transitions operating over the whole document, when you're really trying to make a component transition. What we really need here is scoped view transitions, and I think `match-element` becomes much more interesting in this case. Since scoped view transitions are always same-document, I don't think we need `auto`'s ID behaviour. ## Build style 2: a simple no-framework page transition The most common way people hand-roll SPA style page loads, in a progressive enhancing way, is to load the HTML of the target page and inject it into the current page via something like `innerHTML`. This is kinda AJAX 101, but it's been packaged up and called various things, such as TurboLinks. I used this style for [my basic view-transition demos](https://simple-set-demos.glitch.me/4-fixed-header/) because it only takes a couple of lines of JS using the navigation API. But, the result of this is that some things that are intended to be the same are different elements, such as the header in the example above. `match-element` isn't useful here. I could make `auto` work by adding IDs, but they're vulnerable to the footguns already outlined in this thread. A more stable solution here would be assigning `view-transition-name`s deliberately, but I'm interested in the proposals that allow names to be built up using attributes from the current element and its ancestors. ## Build style 3: VDOM frameworks I know there's a lot of distaste for frameworks in this group, and I recognise their issues, but they are popular. In this system you sometimes get element equality, but sometimes you don't. It's mostly an optimisation. If an element stays within the same parent, you can usually keep the same element instance intentionally. However, folks often get this wrong, and end up with new elements, or worse, element equality with something else. `match-element` is kinda tricky in this case. Again, `auto` could work by adding IDs, but there are footguns. Again, a more stable solution here would be assigning `view-transition-name`s deliberately, or using specific attributes other than ID. --- I promise you I'm not coming at this from a framework-first perspective. I've built sites by dragging HTML files into an FTP client, and PHP with progressive enhancement, and all the way up to big horrible framework sites. I'm drawing on all of those styles in my recommendation here. It looks to me like `view-transition-name: auto` has been designed after looking at a couple of codepen demos, because the design isn't helpful when you try and scale it beyond that. We shouldn't be designing APIs that are only useful in tech demos, and we definitely shouldn't be using a "this is what you want" name like `auto` for those patterns. I'm happy that we're shipping `match-element`, because it will be useful in some cases, including tech demos. I think it'll be more useful in scoped view transitions. But it shouldn't be the first thing you reach for unless you know how it works. -- GitHub Notification of comment by jakearchibald Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10995#issuecomment-2553463222 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 19 December 2024 11:22:19 UTC