[css-view-transitions-2] Allow an auto-generated view-transition-name that doesn't default to ID

[noamr]

In #8320, we resolved on using view-transition-name: auto as a way to generate names, using the element's id if exists.
In the resolution, we said that we'll have another value for generating the name without falling back to ID, and perhaps yet another one for generating it only from ID.

Proposing:

• Use view-transition-name: self as the keyword for generating the name ignoring ID. Other proposals that were raised were from-element and element-uuid().
• No need for "generate from ID", once we have attr(<ident> id).

[bramus]

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.

[noamr]

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?

[bramus]

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)

[noamr]

• 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.

[bramus]

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)

[tabatkins]

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

[noamr]

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.

[bramus]

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

[nt1m]

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.

[bramus]

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.

[nt1m]

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.

[bramus]

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

[fantasai]

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.

[css-meeting-bot]

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 full IRC log of that discussion

<fantasai> bramus: This issue is about allowing an auto view-transition-name to be generated by specifying a keyword
<fantasai> bramus: a number of keywords suggested, from-element, per-element, self, auto, auto-id
<fantasai> bramus: I asked authors "which keyword conveys using ID and falling back to auto-generated" and "which keyword conveys automatically generated"
<fantasai> bramus: when I asked which is "automatically generated", they picked "auto"
<fantasai> bramus: when I asked about the ID and fallback, the responses ...
<fantasai> bramus: We were thinking 'from-element' but authors expected 'auto' for "automatically generated".
<fantasai> bramus: we could meet developers by reverting previous resolution about auto reading ID and falling back
<fantasai> bramus: and come up with a better keyword
<fantasai> bramus: or push authors towards using attr() function which is suited for this, can use attr(id, auto) for fallback behavior
<fantasai> bramus: or keep previous resolution of using auto for fallback behavior, but then we need to come up with a very good keyword for the autogeneration
<fantasai> bramus: Authors prefer auto-id for autogenerated, and some suggested generated
<fantasai> bramus: and some others said, don't we have attr() for this?
<bramus> fantasai: we can conclude from the poll that there is cnofusion over keywords
<bramus> … wording of poll most likely prompted some of the responses
<bramus> … using “automatically generated id” pushed authors towards `auto`
<bramus> … internally we are generating one, bu thtat is just the meachism
<bramus> … it is an internal detail
<bramus> … the will never see it … we might not even generate one and use poitner identity
<bramus> … its not about automatically generating ids, its about the identify of the element object
<bramus> … poll is propably a but confused on that point
<bramus> … could try to come up with good keywords but maybe need some more ideas
<bramus> … but doesnt mean that we should revert decision on `auto`
<bramus> … in terms of possible keywords: `mathc-elememtn` is an option as we use match in a few other places
<bramus> … but open to ideas
<astearns> q+
<bramus> … at webkit we think `auto` is the right way to define it
<khush> q+
<astearns> ack fantasai
<bramus> … and maybe need other keyword for the other thing
<noamr> I like match-element
<bramus> astearns: the currently specced behavior for auto is to use the id attr and fall back to auto generated one?
<bramus> fantasai: its to use the identity of the element
<bramus> … if there is no id, we look at the element being the same object or not
<bramus> … in that case, the object hasnt been destroyed - its a singular one that you can map between tree versions
<astearns> ack astearns
<astearns> ack khush
<bramus> khush: spec might say to generate one, but conceptually get the point that that is one way to implement it. you don”t need strings to establish identity
<bramus> … of all options maybe self is nice as it doesnt hit at generating something
<florian> q+
<bramus> … your identtity is the nodes identity
<bramus> … auto is confusing. kind of a grab value in css to figure out automatically what to do which is what we doing here as well
<astearns> ack florian
<fantasai> match-element? same-element?
<bramus> florian: explanation fantasai just gave: if that can be used. key point is stability … so maybe akeyword like stable?
<bramus> … if the elemen tis still around it will be the same
<noamr> q+
<bramus> … dont describe what we do but the why
<astearns> ack noamr
<bramus> noamr: I like match-element. we match not just the id, but the actual elements
<bramus> … matching two state of the same element
<bramus> q+
<khush> i'm ok with match-node or match-element
<fantasai> bramus: I like all these suggestions just now, `stable` and `match-element`.
<fantasai> bramus: doesn't seem confusing
<astearns> ack bramus
<fantasai> bramus: `from-element` implies reading from the element, but matching is matching so seems like a good suggestion
<fantasai> bramus: wrt `auto` part, as DevRel we can hammer on this point, means "try to get a name" not "automatically generate one"
<fantasai> astearns: which method do we expect authors to use most?
<fantasai> noamr: It depends
<fantasai> noamr: Likely use explicit names. Otherwise likely to use auto, it will just work.
<fantasai> noamr: But if they want to specifically say that id attrs don't participate, then use match-element
<fantasai> noamr: I think auto would be more common, it will usually just work.
<fantasai> noamr: element identity, not observable if generated string
<fantasai> astearns: We have a way of using the ID attribute, specifically, by using attr() function
<fantasai> astearns: we have defined `auto` to match the element by ID if there is one, or using other methods if not
<fantasai> astearns: Is there really a use case for "throw out the IDs and only use the opaque element-matching algorithm" ?
<fantasai> khush: Point came up last time, if these are only two (auto and attr(id)), then there's no way to say "I want to match based on element identity even though I put an ID on it"
<fantasai> noamr: You wouldn't be able to match if element has an ID in only one of the state
<fantasai> khush: or if ID is used for a different reason, and not used in view transitions
<fantasai> astearns: I can see the case, but not expecting authors to run into it much
<fantasai> noamr: cleaner solution to have specific keywords for each behavior
<fantasai> astearns: understand, but that's a theoretical purity argument
<fantasai> khush: We heard from one [missed]
<astearns> ack fantasai
<bramus> fantasai: in terms of the name clashing we might want to consider namespacing ids taken from the element vs names that we put direclty into css
<astearns> s/[missed]/AirBnB where teams use ids for entirely different things
<bramus> … that would avoid name clasing
<bramus> … already have pseudo selelcting syntax but are not using the ! sign for keywords. Could say tha ti fyou pull the id from the attr, then it gets prefixed with the ! sign in the matching.
<noamr> q+
<bramus> … that would namespace it and avoid clashes
<fantasai> s/!/#/g
<bramus> astearns: this would be an additional thing
<bramus> fantasai: would mean for auto and I guess attr() tha twe are generating the namemt hen you would use v-t-g(#id) to select and style it
<bramus> q+
<bramus> khush: not sure about this, but maybe could do it for auto-generated ones. Not for those read from attr.
<bramus> … will be a pain to keep track of where it came fromg
<bramus> fantasai: fair
<astearns> ack noamr
<bramus> noamr: against namespacing because of flexibility of VTs.
<bramus> … take cross-doc VT with #hero id on one side and one with hero v-t-name on other side
<bramus> … would want to transition between those
<bramus> khush: can open issue separately from this
<astearns> ack bramus
<fantasai> bramus: Just realized, we could not tackle this problem as part of view transitions, keep auto as it is, and look at the ident() function and allow it to take a keyword
<fantasai> bramus: so if you want to auto-generate an ident you use it
<bramus> fantasai: so ident() should take wjhat?
<bramus> bramus: `view-transition-name: ident(auto)` to auto-generate an ident
<bramus> … so we dont have to come up with a keyword for this
<bramus> fantasai: but that retrurns an actual observable identifier
<bramus> … which we dont think we want to do
<bramus> … should still have keyword for it
<noamr> q+
<bramus> … can consider is distinguishing between auto keyword actually creating a referencable v-t-n or just an internal matching
<bramus> … can you selec tagainst the generated identifier is an open question
<bramus> … would we do that or just use the id attr to match elements but not to select against it
<bramus> … like `::v-t-g(id)`
<bramus> khush: would be nice if you could do it for for the `[id]` case
<bramus> … pretty convenient
<bramus> fantasai: only downside is that we might have namespace clashes and stuff that you are using for identity in the document
<bramus> noamr: right, mixing things
<bramus> fantasai: can agree on keeping `auto` as it is
<bramus> … and for now add a keyword `match-element` for only looking at element id
<bramus> … and open issue to mix the namespaces
<noamr> q-
<fantasai> s/to mix/about mixing/
<bramus> astearns: Gonna need async resolution as we are low on people attending
<bramus> PROPOSED RESOLUTION: Add `match-element` keyword that will only use element identity and not use id attributes.
<bramus> astearns: will be submitted as an async resolution
<fantasai> RESOLVED: [Pending async confirmation] `auto` will match elements using their ID attributes, falling back to element identity; `match-element` will only use element identity.

[astearns]

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.

[jakearchibald]

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.

[nt1m]

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.

[jakearchibald]

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.

[nt1m]

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.

[jakearchibald]

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

[noamr]

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.

[noamr]

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.

[jakearchibald]

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.

[css-meeting-bot]

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

The full IRC log of that discussion

<TabAtkins> noamr: there was a resolution previously for the behavior of "auto"
<TabAtkins> noamr: where it goes to the ID as a name, then falls back to element-identity
<TabAtkins> noamr: Jake raised some good points
<TabAtkins> noamr: myself and a few other googlers consulted as well
<TabAtkins> noamr: we feel like there's no current good proposal for "auto". we're not against doing something with the word "auto" in the future, but we're not suggesting anything else for "auto" right now.
<TabAtkins> noamr: so our suggestion is to remove "auto" from the spec for now. Leave "match-element"
<TabAtkins> noamr: then get community feedback, and perhaps redo auto in the future
<TabAtkins> noamr: we'll keep "auto" as an invalid name, so we can use it in the future
<astearns> ack fantasai
<JakeA> q+
<TabAtkins> fantasai: our position is we think the current definition provides a useful beahvior to authors
<TabAtkins> fantasai: it does something which is "hey, try to figure out the mapping before and after"
<TabAtkins> fantasai: in the most obvious way
<TabAtkins> fantasai: two obvious ways are, does it match IDs, and is it the same element?
<TabAtkins> fantasai: with ID being more explicit of a signal, so it wins
<TabAtkins> fantasai: I think the polls about "what auto does" mixes up with a concpet of auto-generated string
<bramus> q+
<TabAtkins> fantasai: if you think about identity about a string, auto could be thought of as genning such a string
<TabAtkins> fantasai: but that's not what "auto" usually means in CSS.
<TabAtkins> fantasai: here it's just "if there's some reasoanble auto notion of matching, use that"
<TabAtkins> fantasai: and this lets us use the same view transition for a bunch of elements without ahvin to name them individuall
<TabAtkins> astearns: so would you object to removing auto for now?
<TabAtkins> fantasai: yes
<astearns> ack JakeA
<TabAtkins> JakeA: match-element, I think people think it's more useful than it actually is
<TabAtkins> JakeA: if you think fo them as page transitions, that's what they're for right now...
<noamr> sorry, I have to go. I think this is going beyond the scope of the time-boxed discussion
<TabAtkins> JakeA: they don't work in pratice, because parts of the UI get...
<TabAtkins> JakeA: we had an overlay in the list we reordered, we ahd to put that int he VT as well, but because it becomes inert that didn't work for us
<TabAtkins> JakeA: we need scoped VTs for reordering
<TabAtkins> astearns: noam had to leave and we're at timebox - i think i'll cut you off and we'll move on
<TabAtkins> bramus: i'll defer to the issue as well
<TabAtkins> astearns: so take this back to the issue. It wasn't a quick discussion, we'll bring it up again.

[astearns]

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?)

[noamr]

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

[bramus]

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)

[noamr]

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.

[bramus]

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.

[astearns]

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?

[noamr]

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.

[jakearchibald]

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.

[noamr]

@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?

[tabatkins]

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

[noamr]

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.

[noamr]

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

[bramus]

This conversation has stalled, so let’s bring it back to life.

Summary up until now is that auto should be put on hold until we get a better idea about what it should do, and that match-element is to be used for identity matching. Input is being asked from @nt1m, @fantasai, and @emilio.

---

Personally I would like to not use match-element to generate an internal identifier (unobservable by authors) but assign that behavior to the auto keyword.

This for two reasons:

1. You can get the originally requested auto-behavior (the one that first tries the id attribute, falling back to an internally generated identifier) using attr():

   view-transition-name: attr(id type(<ident>), auto);

   Yes, it’s a bit of extra typing but:
   - It works with attributes other than id too
   - Authors are being very explicit about what they want
   - It can always be backported into a keyword (or function preferably, see “feature detection” point below)

2. Feature detection

   If you feature detect view-transition-name: match-element with @supports/CSS.supports it currently returns true.

   @supports (view-transition-name: match-element) {
     .item {
       view-transition-name: match-element;
     }
   }

   The snippet above will pass in both Chrome and Safari today already (uhoh!), resulting in multiple elements getting a view-transition-name set to match-element which will prevent the View Transition from running.

   Unexpected duplicate view-transition-name: match-element
   <div class=​"item" id=​"item-1">​…​</div>​
   <div class=​"item" id=​"item-2">​…​</div>​
   <div class=​"item" id=​"item-3">​…​</div>​
   <div class=​"item" id=​"item-4">​…​</div>​
   <div class=​"item" id=​"item-5">​…​</div>​
   

   As a result an author can not safely feature detect support for match-element.

   When feature detecting view-transition-name: auto it returns false (*), which would allow author to feature-detect auto having some magic behavior instead of it being the actual view-transition-name that gets assigned.

   (*) Unfortunately only in Safari. Chrome returns true here, which would need to get fixed – see https://crbug.com/383409588 which I filed just now. Chrome does correctly return false. I was wrong here because I ran my test in Canary with flags, which has experimental support for view-transition-name: auto

   (Alternatively changing match-element to become a function (i.e match-element()) would also fix this feature detection issue)

[jakearchibald]

The reason I don't like view-transition-name: auto for this behaviour is it only works in same-document transitions, and doesn't in any way describe how the feature works. I think this behaviour should come with a more cautionary name than "hey just do it for me".

match-element() seems fine.

[bramus]

The reason I don't like view-transition-name: auto for this behaviour is it only works in same-document transitions

Maybe that’s OK? I don’t think we could ever make an auto work for cross-document (but of course would like to be proven wrong … discussion for later)

match-element() seems fine.

This gives me another idea: if it’s a function then it can optionally take an argument … which could totally be an attribute name – i.e. when using match-element(id) it would return the [id] value. If no [id] exists, you get none.

[bramus]

Summary up until now is that auto should be put on hold until we get a better idea about what it should do

That ship has sailed: https://webkit.org/blog/16301/webkit-features-in-safari-18-2/#:~:text=WebKit%20for%20Safari%2018.2%20adds%20support%20for%20view%2Dtransition%2Dname%3A%20auto

[jakearchibald]

That's awful. @astearns does the CSS working group support that kind of behaviour?

[astearns]

@fantasai can you comment on auto in your 18.2 release?

[jakearchibald]

When I was working more closely on this feature, I put a lot of care into making sure folks across the group were happy with the design and spec of this feature, same with other features like linear(). It's really disappointing to see that Apple's way of operating is just to disengage and ship whatever they want.

[vmpstr]

I appreciate all of the discussion about auto on this thread and happy to see it continue. However, I also want to ensure that we add match-element/match-element() as a keyword for non-id matching behavior. I believe we have consensus on that across all parties (correct me if I'm wrong).

Agenda+ to add match-element, with a choice of functional syntax match-element() which allows for better feature detection, or plain keyword match-element which better matches long term desired form.

[fantasai]

@fantasai can you comment on auto in your 18.2 release?

I believe what happened is that there was agreement on adding it as re-iterated in the OP above, it was added to the spec, the WebKit team promptly implemented it in good faith as published in the spec and tested in WPT, and the objection subsequently raised here was too late to make any changes to the release.

However, I also want to ensure that we add match-element/match-element() as a keyword for non-id matching behavior. I believe we have consensus on that across all parties (correct me if I'm wrong).

Not an objection, but, what is the use case for match-element if we already have auto? Like, what's a realistic example of a page which would need match-element with the ID-matching behavior specifically disabled?

[bramus]

Not an objection, but, what is the use case for match-element if we already have auto?

Fallback value for attr(), when you specifically don’t want [id] to be used should one ever be added.

[data-view-transition-name] {
  view-transition-name: attr(data-view-transition-name type(<custom-ident>), match-element);
}