Copying over my comment from 8320 for visibility:

One thing I don’t like about from-element is that it reads like “read the id from the element” which authors will interpret as “read the id attribute from the element”. Ideally the value makes it clear that it’s an internal id, unrelated to the id attribute.

I think element-uuid as suggested in the OP comes closest to this.

Copying over my comment from 8320 for visibility:

One thing I don’t like about from-element is that it reads like “read the id from the element” which authors will interpret as “read the id attribute from the element”. Ideally the value makes it clear that it’s an internal id, unrelated to the id attribute.
I think element-uuid as suggested in the OP comes closest to this.

Any thoughts on self?

Not a big fan of it, but also not against it.

I recently read up on first-valid() – which I didn’t know existed up until then.

This give me a new idea (which would alter the resolution from #8320): what if there was a function that allowed authors to list certain options and it returns the first non empty one?

• auto = auto generate a name (element identity).
• attr(id "<ident>") = use id attribute
• first-non-empty(attr(id "<ident>"), auto) = try getting id attribute first. if there is none, fall back to auto behavior.

That would prevent a lot of confusion on the author side, as auto here now means “auto-generate a v-t-name”.

Otoh it would require a little more typing if they want the fallback behavior, but it would also allow authors to add more options to the fallback: e.g. first-non-empty(attr(id "<ident>"), attr(data-name "<ident>"), auto)

• first-non-empty(attr(id "<ident>"), auto) = try getting id attribute first. if there is none, fall back to auto behavior.

That would prevent a lot of confusion on the author side, as auto here now means “auto-generate a v-t-name”.

Otoh it would require a little more typing if they want the fallback behavior, but it would also allow authors to add more options to the fallback: e.g. first-non-empty(attr(id "<ident>"), attr(data-name "<ident>"), auto)

To me this feels too verbose for a feature that's supposed to be a DX convenience... I think once attr is there we wouldn't need this. Though `first-non-empty might still be a valuable proposal regardless of auto view-transition-names.

I think the direction the auto resolution went with is is to have some keywords that have reasonable defaults and to leave attr etc. for the general-purpose more complex cases.

To me this feels too verbose for a feature that's supposed to be a DX convenience

True.

Other possible keyword values I can think of, as an alternative to self:

• generated/generate
• auto-id

I think both clear convey that a value is automatically generated.

(Curious to know if @nt1m or @fantasai have suggestions or a preference here)

Fwiw, the same feature in the random() function uses per-element for the keyword. Ideally we'd be able to use the same term in both places. (random() hasn't shipped anywhere, so it's changeable if we decide on something different for VT.)

I like per-element! Added Agenda+ for this, I hope we can bikeshed a bit and decide on something.
My favorites so far are per-element and self.

I’m running a poll on several social media platforms to get an idea of how authors interpret the keywords: X, Mastodon, BlueSky.

We don't really need first-non-empty, attr() already has a fallback argument: attr(id ident, per-element) would be the equivalent of auto.

I’m running a poll on several social media platforms to get an idea of how authors interpret the keywords: X, Mastodon, BlueSky.

Looking at the results of these polls:

• Authors interpret the keyword auto as “the name is an automatically generated value”, not as “the name is derived from the id attribute, falling back an automatically generated value”
• Keywords that signal “the name is an automatically generated value” are auto and auto-id
• Keywords that signal “the name is derived from the id attribute, falling back an automatically generated value” are from-element and first-non-empty(…)

There is clear mismatch between how authors interpret the keywords and what is currently resolved on and/or proposed within the working group. Authors don’t interpret auto as “do the default behavior” but as “auto generate me a value”:

• The name is an automatically generated value:
  • CSSWG: from-element or self
  • Authors: auto or auto-id
• The name is derived from the id attribute, falling back an automatically generated value:
  • CSSWG: auto
  • Authors: from-element or first-non-empty(…)

Two people shared loose replies that suggested the keyword generate(d). On suggested to use the fallback value in the attr() function.

We don't really need first-non-empty, attr() already has a fallback argument: attr(id ident, per-element) would be the equivalent of auto.

I kinda forgot that attr() provided a fallback option, so this is a great suggestion.

Winging back tot he naming/keywords aspect: can we meet authors here?

Strawperson suggestion:

• Revert previous resolution about what auto does and change it into “the name is an automatically generated value”
• Push authors towards using attr(id ident) and attr(id ident, auto) when they want the fallback behavior.

This matches with how they interpret things.

Revert previous resolution about what auto does and change it into “the name is an automatically generated value”

I disagree with this. The auto behavior should also do something sensible for cross-document view transitions, hence why we also had the ID heuristic in it. auto should give you the most sensible behavior with as many situations as possible.

I'm personally not sure we need something like per-element given auto should do the sensible thing most of the time, but I'd be open to also have a per-element keyword.

For today’s breakout session, I think there are two paths forward:

1. Revert the previous auto resolution and use auto for the “automatically generate me a name” case, because authors interpret that keyword as doing the latter. If so, we need to figure out a better keyword for the “try to use the id attribute’s value and fall back to an automatically generated name” case or could leave it as is and push authors towards using attr(id <ident>, auto).
2. Keep the previous auto resolution but come up with a very good keyword that clearly conveys that the name is automatically generated (which this issue is all about).

Things to consider:

• A poll with authors suggests that the keywords from-element, per-element, and self do not clear express “auto generate me a value”. Authors prefer auto or auto-id here. Some authors have suggested generate(d).
• Some authors have suggested the attr() approach without it being presented as an option (many did vote for the first-non-empty() thing).
• Any new keyword that gets chosen must be specced as an invalid value for view-transition-name. This already is the case for auto.
• The chosen keyword could potentially be exposed, depending on the outcome of [css-view-transitions-2] Allow an auto-generated view-transition-name that doesn't default to ID #10995 (do we expose the keyword, or the auto-generated id?)

Something that just came to mind: the keyword that covers the “automatically generate me a name” case can potentially be reused in the ident() function discussed in #9141

Agree with @nt1m here, and I think the Twitter poll was not worded in a way to answer the question of “is our current definition for auto understandable” -- you'd have to invert the question for that, and ask “what do you think auto means?” with some possible definitions. I also think the question was focusing too hard on the underlying mechanism (generated IDs) rather than on the higher-level concept (matching the element object). So I would go with option 2.

The CSS Working Group just discussed [css-view-transitions-2] Allow an auto-generated `view-transition-name` that doesn't default to ID, and agreed to the following:

• RESOLVED: [Pending async confirmation] `auto` will match elements using their ID attributes, falling back to element identity; `match-element` will only use element identity.

The CSSWG will automatically accept this resolution one week from now if no objections are raised here. Anyone can add an emoji to this comment to express support. If you do not support this resolution, please add a new comment.

Proposed Resolution: auto will match elements using their ID attributes, falling back to element identity; match-element will only use element identity.

I strongly feel the current direction is a mistake. auto meaning "use the value of the ID attribute if it's there, otherwise generate an internal value from the node instance" is super unintuitive. It's clearly two very different features smashed into one value.

The auto behavior should also do something sensible for cross-document view transitions

I understand where this is coming from, but I don't think 'some completely different behaviour' is at all sensible. The behaviour is only the same between same & cross-document transitions if every element has an id, in which case you'd be well served by a feature that allows you to assign the view-transition-name from an attribute. If every element doesn't have an id, then the behaviour change you see when switching from same to cross-document transitions is going to seem very weird.

Given this, having two features:

• One that takes the view-transition-name from an attribute.
• One that generates a view-transition-name for the (pseudo-)element.

…seems much more sensible and easier to understand. The first feature will behave consistently between same & cross-document transitions. The second won't work cross-document at all, but it's easy to understand why - the nodes are different.

By smashing them into one feature, instead of having one feature that consistently works cross-document, and one that consistently doesn't work cross-document, we're ending up with one feature that doesn't behave consistently. Even worse, parts of the transition might kinda work, depending on which elements have IDs, and it's going to be hard for developers to figure out why view-transition-name: auto seems to 'partially' work in these cases.

Even if you learn that "view-transition-name: auto gets weird if you don't add id to everything", it's going to bite you with pseudo-elements like ::before, where you can't give those a different id to their host.

Given how different these features are, as I developer I want to pick between them. I don't want the UA picking for me. I don't want removing an id attribute to come with such a drastic and difficult-to-debug change of behaviour.

These two features you mention already exist:

One that takes the view-transition-name from an attribute.

attr()

One that generates a view-transition-name for the (pseudo-)element.

match-element

auto is nice because it tries to do the "right thing" for both SPA and MPA without having to write attr(id ident, match-element). It's essentially just syntax sugar.

My point is that it isn't doing the right thing, it's obfuscating doing an unreliable thing.

If I want the thing to work for both SPA and MPA, then I'll use attr(id ident), because attr(id ident, match-element) may not work in the MPA case. The fact that it 'tries' to work and ends up partially working is really confusing.

If I only want the thing to work SPA, then match-element is fine, and means I don't have to assign IDs everywhere, and it works nicely with pseudo-elements.

I guess it's interesting that attr(id ident, match-element) is possible, but I don't know when I'd ever want that. If I'm intending for the transition to work for SPA and MPA, I'd much rather it fails in both cases if I've forgotten an id. Otherwise, I'm likely to ship something that "works on my machine", because it works inconsistently between SPA and MPA.

The good thing about attr(id ident, match-element) as a piece of syntax, is I can see that it involves the SPA-only feature match-element, so it's something I should avoid if I want to support MPA. auto doesn't provide that clarity, it hides the problem. I cannot fathom why this group deliberately wants that for the platform.

The web design world does not revolve around SPA/MPA frameworks

My argument isn't related to frameworks. When I say SPA, I mean same document transition. When I say MPA, I mean transitions across documents.

making the decorative use of view transitions within a page easier to author.

Yes but the current auto proposal behaves unpredictability, therefore becomes hard to author.

@jakearchibald I don't think single-page use cases and multi-page use cases are the same. Your assumption is that they are the same, but I don't see that be the case in the future.

Here are some single-page use cases of view transitions:

https://codepen.io/smashingmag/full/BabaBKz
https://codepen.io/argyleink/pen/dyLNgpX
https://codepen.io/argyleink/pen/ZEmLrze

Here are multi-page use cases:

https://astro-records.pages.dev
https://spotify-astro-transitions.vercel.app

Yes but the current auto proposal behaves unpredictability, therefore becomes hard to author.

It's surely not optimized for someone converting between SPA & MPA, but I think it's more than reasonable for the use cases above.

Realistically, all the use cases you envision to be similar between SPA & MPA will become MPAs in the future, so it makes sense to consider the most realistic use-cases of each type, rather than trying to optimize for the conversion between an outdated practice to a newer practice.

Given the use cases are different, I think it's OK to have the behavior for SPAs and MPAs be different, especially for a value like auto.

If this group is insistent that the behaviours should be unpredictable between SPA and MPA, even in cases where it can be easily avoided, then I think the API should be forked to make this clear to developers.

we should consider forking the whole API (eg cross-document-transition-name), so it's clear that there isn't an intent for these behaviours to be similar, and that any similarities are coincidental

(#) 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.

(#) 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.

(#) 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.

@jakearchibald I don't think single-page use cases and multi-page use cases are the same. Your assumption is that they are the same, but I don't see that be the case in the future.

Here are some single-page use cases of view transitions:

https://codepen.io/smashingmag/full/BabaBKz https://codepen.io/argyleink/pen/dyLNgpX https://codepen.io/argyleink/pen/ZEmLrze

match-element should work great here. The automatic ID matching doesn't add anything to any of these. Perhaps some confusion...

Here are multi-page use cases:

https://astro-records.pages.dev https://spotify-astro-transitions.vercel.app

What makes these "multi-page" in the cross-document sense? Astro supports both cross-document and same-document mode. Right now auto name generation would not work with either the auto and match-element proposal without changing the DOM and adding IDs everywhere (neither astro examples use IDs in conjunction with view-transition-name)...

If I was building an app like this and wanted auto name generation, I'd probably wait until attr is around and use view-transition-name until then.

The auto keyword allows the CSS author to identify a set of elements using selectors (such as class selectors), and to indicate that they should use view transitions to visually transition from one DOM state to another, and let's the JS author figure out how they want to manage the tree and the elements' sense of identity. This is imho a perfectly reasonable way to divide the responsibilities. It is not going to be reasonable for some use cases, but it is going to be very convenient for others. And that's OK.

auto also implies that this is some sort of standard/common/best-practice way to use the API. I find that using IDs in today's web is not a common practice, and CSS shouldn't be the place to be opinionated about it. As evidence, in the 5 examples brought here only one uses IDs on elements with view-transition-name.

Perhaps having this behavior under a different name would feel a bit more reasonable? auto-match?
Also some example where the ID-matching behavior does something useful beyond match-element would help the conversation.

If this group is insistent that the behaviours should be unpredictable between SPA and MPA, even in cases where it can be easily avoided, then I think the API should be forked to make this clear to developers.

That fork is already planned, in the shape of element-scoped view transitions.
Seems to me that the examples that are "clearly same-document" fall into that category because the transition is constrained to one part of the page. In cases where the transition is scoped for the whole document, I think we should uphold the design goal of having as match less difference as possible between same-document and cross-document transitions. The astro examples only reinforce this.

100%. Although, even in that case, I don't think we should be introducing arbitrary differences.

What's making me sad in this thread, is I'm pointing out the footguns of this feature in actual real-world use-cases, and also pointing out how it's harder to teach a feature that has arbitrary branching behaviours, and the counterargument seems to be the assertion that "auto is useful and expected" without any reason or evidence.

My points are being dismissed as being related to frameworks, when they're not, and the counter evidence is a bunch of codepen demos that actually want scoped view transitions.

Can we get this on the agenda? I don't think this is being handled well.

If this group is insistent that the behaviours should be unpredictable between SPA and MPA, even in cases where it can be easily avoided, then I think the API should be forked to make this clear to developers.

That fork is already planned, in the shape of element-scoped view transitions. Seems to me that the examples that are "clearly same-document" fall into that category because the transition is constrained to one part of the page. In cases where the transition is scoped for the whole document, I think we should uphold the design goal of having as match less difference as possible between same-document and cross-document transitions. The astro examples only reinforce this.

Seems like a very incoherent model if element.startViewTransition() behaved differently than document.startViewTransition(). It's even more unpredictable than document.startViewTransition() behaving differently than @view-transition.

What's making me sad in this thread, is I'm pointing out the footguns of this feature in actual real-world use-cases, and also pointing out how it's harder to teach a feature that has arbitrary branching behaviours, and the counterargument seems to be the assertion that "auto is useful and expected" without any reason or evidence.
My points are being dismissed as being related to frameworks, when they're not, and the counter evidence is a bunch of codepen demos that actually want scoped view transitions.

match-element is the clearly the right behavior for auto in scoped-element transitions. Are we going to make auto behave differently there? attr(id ident, match-element) is useful in case someone tries to do scoped-element transitions while rebuilding the DOM. Not to mention it brings in some amount of predictability being the first choice for cross document view transitions.

Re: arbitrary branching behaviours, how many people are going to hit this? Sure, there's going to be people converting from SPA to MPA, but that's a one time thing, and I don't expect it to happen in the future. Frameworks can choose not to use auto if it provides more predictable behavior when switching modes.

What makes these "multi-page" in the cross-document sense? Astro supports both cross-document and same-document mode. Right now auto name generation would not work with either the auto and match-element proposal without changing the DOM and adding IDs everywhere (neither astro examples use IDs in conjunction with view-transition-name)...

I wanted to point out these types of use cases would exclusively use cross document view transitions in the future.

Seems like a very incoherent model if element.startViewTransition() behaved differently than document.startViewTransition(). It's even more unpredictable than document.startViewTransition() behaving differently than @view-transition

Nobody is suggesting any particular change in behavior; I think this is becoming a bit hypothetical.

match-element is the clearly the right behavior for auto in scoped-element transitions. Are we going to make auto behave differently there? attr(id ident, match-element) is useful in case someone tries to do scoped-element transitions while rebuilding the DOM.

I don't think so; Just pointing out that branching match-element makes sense, but that I don't see examples of usefulness of trying to match by ID first.

What makes these "multi-page" in the cross-document sense? Astro supports both cross-document and same-document mode. Right now auto name generation would not work with either the auto and match-element proposal without changing the DOM and adding IDs everywhere (neither astro examples use IDs in conjunction with view-transition-name)...

I wanted to point out these types of use cases would exclusively use cross document view transitions in the future.

We can't be sure of that.
Sounds like this is a bit of an attempt to "favor" cross-document HTML-first apps over JS-based single-page apps. You know I appreciate that sentiment and I would very much like to find interesting solutions to this problem (if we see that attr doesn't cut it), but I think that match-by-ID is a bit too particular to be it.

@nt1m

match-element is the clearly the right behavior for auto in scoped-element transitions.

fwiw, I don't agree with this. There are many cases where you want to transition between two things that aren't the same element. match-element is a good feature for same-document transitions, and it's great that it has a name that reasonably communicates what it's doing.

I don't see why folks are desperate to attach a behaviour to auto today. I think we'll discover much more interesting opportunities in future.

One thing I see developers doing it giving view-transition-name to too many elements, which aren't changing state either side of the transition. I don't have a solution in mind right now, but it'd be nice if auto could tackle that by computing to none in cases where a transition isn't needed.

Seems like a very incoherent model if element.startViewTransition() behaved differently than document.startViewTransition(). It's even more unpredictable than document.startViewTransition() behaving differently than @view-transition.

Then let's shake hands on "incoherence is bad" and drop the incoherent auto proposal.

Sounds like this is a bit of an attempt to "favor" cross-document HTML-first apps over JS-based single-page apps. You know I appreciate that sentiment and I would very much like to find interesting solutions to this problem (if we see that attr doesn't cut it), but I think that match-by-ID is a bit too particular to be it.

There is a good reason to do so, JS based apps can attach whatever view-transition-name they want programmatically via script. If the person is using a JS framework, there's a great chance that will be abstracted away anyway.

I don't see why folks are desperate to attach a behaviour to auto today. I think we'll discover much more interesting opportunities in future.

I do think it is useful having an auto value that tries to do the right thing on your behalf, especially to reduce the need for complex JS or CSS syntax. Let's try to discuss this more on the call to see how this should look like.

When is the call? Is there a special call for this or is it Wednesday's meeting?

When is the call? Is there a special call for this or is it Wednesday's meeting?

It's up to the chairs, I'll ask for it to be prioritized for this Wednesday but it depends on other issues etc.

Proposing to have a time-boxed discussion and optionally resolve based on this comment - remove auto from the spec temporarily, ship match-element and proceed later based on community feedback (maybe we'll end up bringing it back in the current form!)

As there is no current consensus on the ID behavior of auto and no other proposals have matured I think this is the most reasonable course of action.

I might not make the call, but I want to strongly support the resolution @noamr is proposing.

The current view transition tools support 'page' transitions, not inner component transitions. At Shopify, we recently abandoned view transitions for some "list reordering" transitions because other UI had to become inert during the transition. Scoped view transitions are the solution here, but we're not at that stage. It feels like folks are being guided by a few codepen demos that don't actually work in practice, although they make me excited about what we could do in future with scoped transitions.

match-element is useful, but maybe not as useful as folks are assuming. It feels like folks want this to be the default under the assumption that it solves most problems. I think folks are underestimating how often 'equivalent' bits of UI are actually different element instances. Remember we're talking about page transitions here. Outside of frameworks, it's common to download a load of HTML and set it as some container's innerHTML. This means a lot of equivalent elements are different element instances. With frameworks, more elements are preserved, but most developers don't understand when this does and doesn't happen, since the diffing algorithms are largely treated as an optimisation.

Using an ID as the view-transition-name is interesting, but not as useful as folks are assuming. I'm glad we're looking to unlock it as a feature, but IDs aren't that common as style hooks. I've seen cases where, eg an ID is generated from a heading's content (for linkablity), then it's used for styling in some subtle way, then a small change in the heading content breaks that. For reliability, I would encourage folks to keep their view-transition-name and ID semantics separate, to reduce the likelyhood that an ID would change and impact view transition CSS styles. But, I'm still glad that we're making this kind of thing possible in CSS.

View transition CSS behaviour should be as similar as possible between same-document and cross-document transitions. Some folks don't see that as an acceptable design goal. I strongly disagree. Arbitrary behaviour differences make systems difficult to learn. I don't see why we'd put that on developers without good reason. I don't see a good reason here. We could look at different defaults for scoped transitions if they make sense.

The proposed behaviour of auto is a confusing foot-gun. It takes match-element and mixes it in with the ID behaviour in ways that are difficult to keep track of, and even if they appear to work in a given situation, will likely break in unexpected ways the developer wasn't expected (eg an ID is removed from an element). Partial failures are the worst to debug.

I'm not against at some point having a "it's what you want most of the time" auto value, but the behaviour proposed here isn't it. It's worrying that it's being pushed though by folks who have less experience building sites with view transitions.

The CSS Working Group just discussed [css-view-transitions-2] Allow an auto-generated `view-transition-name` that doesn't default to ID.

Going back further into the discussion, I’d like to bring back the idea of using attr() fallback for the proposed auto behavior. If it turns out this is useful and prevalent, we can then talk later about giving it a name for ease of use.

Perhaps we have just these three options?

1. Spec/implement auto and match-element
2. Spec/implement match-element only for now, and use attr(id, match-element) for the proposed auto functionality
3. Do not spec/implement either auto OR match-element yet (was @jakearchibald suggesting this?)

Going back further into the discussion, I’d like to bring back the idea of using attr() fallback for the proposed auto behavior. If it turns out this is useful and prevalent, we can then talk later about giving it a name for ease of use.

Perhaps we have just these three options?

1. Spec/implement auto and match-element
2. Spec/implement match-element only for now, and use attr(id, match-element) for the proposed auto functionality
3. Do not spec/implement either auto OR match-element yet (was @jakearchibald suggesting this?)

Note with (2), that match-element as a fallback in attr doesn't work out of the box, unless we say that match-element generates a string or ident that's observable in means other than view transition.

I'm personally in favor of (3), OK with (2), and opposing 1 (in its current form).

Not speccing match-element would be unfortunate I think, as it has legitimate use-cases. See #8320 (comment) for a good example of where it would be useful.

(Originally, I had envisioned that the keyword auto would afford that behavior, but we settled at match-element – something I made peace with)

Not speccing match-element would be unfortunate I think, as it has legitimate use-cases. See #8320 (comment) for a good example of where it would be useful.

(Originally, I had envisioned that the keyword auto would afford that behavior, but we settled at match-element – something I made peace with)

To be clear, I'm happy with spec'ing and shipping match-element, but I'm not sure about supporting attr(id, match-element) because it would mean match-element generates an actual observable name, or alternatively that attr would have a special behavior as a view-transition-name value.

I wonder though if in the future we'd want something like the match-element behavior outside of view transitions, in which case just having this as a CSS primitive that produces idents would not be that bad.

To be clear, I'm happy with spec'ing and shipping match-element, but I'm not sure about supporting attr(id, match-element) because it would mean match-element generates an actual observable name, or alternatively that attr would have a special behavior as a view-transition-name value.

+1 on making the values generated by match-element not observable.

I wonder though if in the future we'd want something like the match-element behavior outside of view transitions, in which case just having this as a CSS primitive that produces idents would not be that bad.

The solution here would be the proposed ident() function (See #9141) which could take an argument that auto-generates an observable ident.

If attr(id, match-element) has to expose a string or ident, then that is certainly a show-stopper.

But wouldn’t this just be a fallback to a keyword, the same as saying view-transition-name: match-element when there is no id?

If attr(id, match-element) has to expose a string or ident, then that is certainly a show-stopper.

But wouldn’t this just be a fallback to a keyword, the same as saying view-transition-name: match-element when there is no id?

Yea I can get behind that.

I'm not against match-element. I was trying to explain that it isn't anywhere near "the thing you always want" when it comes to page transitions. Also, it doesn't work effectively in cross-document navigations. Because of this, I'm glad that it's a keyword that roughly expresses how it works, rather than be mixed in with other behaviours behind an enticing auto keyword.

Being able to use an attribute as the view transition name is interesting, and I'm not against that functionality being added. I have some worry that people will do something like:

.some-container * {
  view-transition-name: attr(id, none);
}

…resulting in weird changes to transitions as folks add/remove IDs from elements for purposes other than view transitions. I also worry about what happens if the ID value is "none", "auto", "initial" etc etc. But at least they're somewhat clearly opting into that behaviour. If I saw a PR with the above, I'd reject it, and ask it to instead use an attribute like data-view-transition-name, so the usage didn't get muddled.

attr(id, match-element) is interesting and it seems ok that it could be supported. However, I would never recommend it to developers, and would reject PRs containing it, and instead ask developers to use attr(data-view-transition-name, none), so we don't encounter difficult to debug differences between same-document and cross-document transitions. It also has the same issues if the ID is "none", "auto", "initial" etc etc.

I think the group should avoid introducing 'quirksmode' like switches in behaviour between same-document and cross-document transitions. That's part of the problem with auto, as it has unexpected behavioural differences between same-document and cross-document transitions.

I think those pushing for this combined auto behaviour are letting themselves be influenced by codepen demos that don't work in production since they're component transitions, whereas the current view transitions spec acts across the whole document. I encourage the group to develop "scoped view transitions" - view transitions that are scoped to a particular element, allowing for concurrent transitions. After that, we might be in a better place experience-wise to discuss how something like auto should behave. I don't see why we need to rush it through now.

@nt1m @fantasai do you object to resolving on match-element as per #10995 (comment), and we can take up the ID behavior to a separate issue?

To be clear, I'm happy with spec'ing and shipping match-element, but I'm not sure about supporting attr(id, match-element) because it would mean match-element generates an actual observable name, or alternatively that attr would have a special behavior as a view-transition-name value.

This is fine; attr() is morally equivalent to a var() that just fetches from an attribute instead of a custom property. So in the case of substitution failure ("id" attribute doesn't exist), the fallback just acts like it was what was specified instead.

(Tho, unless we specify that strings are allowed in 'view-transition-name', you'll have to spell it attr(id type(<ident>), match-element), or at least attr(id type(*), match-element) if you're okay with a non-ident ID just making the property invalid (this should be rare anyway).)

Sounds good @tabatkins. As per previous comment, I'm happy to resolve on match-element for now. Sounds like the proposed behavior with attr would "just work" (and we should of course "just test it"). We can discuss the ID behavior of auto separately.

I'd like to hear @emilio's take on this issue :)