Re: [csswg-drafts] [css-view-transitions-2] view-transition-name determined by element (#8320)

> > I wonder if attr() is usable here? I think if attr() is supported, it would probably address most use cases.
> 
> +1 to using `attr()`.

Great!

> 
> Also +1 to Jen's usecase and proposal ( [#8320 (comment)](https://github.com/w3c/csswg-drafts/issues/8320#issuecomment-2023077559) ) for `auto`.
> 
> > See discussion above - the problem with this solution is that it doesn't work for cross-document, or if the framework recreates the element. Generating the name from attributes is perhaps more verbose but works for all those use-cases.

> 
> An `auto` keyword wouldn't address those use cases, but it would address the ones that Jen is trying to solve, which don't have this problem. If you're rebuilding the DOM, then yes, you will need to do something else. But if you're not -- and there are many interesting cases where where you're not -- we can make this a lot simpler for the author.

It would only address the use case of animating grid positions if the underlying mechanism used for it is an SPA, with a framework that doesn't replace elements. If, for example, this was an MPA where every "current image" had its own page, the author would have to refactor this use case if they used `auto`.

In other words, where `auto` is enough is not a matter of *use case*, but a matter of *underlying mechanism*, or "how your app is built". The problem is that underlying mechanisms can be replaced, and having to refactor `view-transition-name: auto` values that are sprinkled around a CSS code base might make people feel that perhaps they should have used `attr()` + `ident()` in the first place. This will be even more apparent in use cases that feel less obvious, like an expanding header. `auto` would work when the app mechanism is simple, and then when the mechanism changes the author would incur an additional cost because they went with the simpler approach that's less portable by design.

> 
> We could go further to address cross-document cases by relaxing the restriction that a name must be unique and come up with a matching algorithm that can handle multiple elements.

Can you give an example for such algorithm? Or you mean that what's below here is that example?
 
> To address things that move or disappear, authors can use unique tags for those items. So let's say you have a list of 10 items and you're moving item 8 to be the 2nd item. You identify that item with a unique name, and the rest of the items with a generic one, and the UA matches them up in DOM order.

This feels simple but actually adding complexity, because it overloads `auto` with opinionated behavior that authors have to remember. `ident("item-" counter())` or so is much simpler to understand because it's neutral. CSS frameworks can take the role of adding opinionated stuff on top of this for ergonomics, and if we see patterns emerge there we can consider adding something like that into the platform.




-- 
GitHub Notification of comment by noamr
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8320#issuecomment-2060909740 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 17 April 2024 10:12:31 UTC