[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 #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.

[fantasai]

@jakearchibald It's not good to fixate on complex websites with complex underlying infrastructure. Sure, there a many websites that use a framework that can enable SPA or MPA rendering, and will switch between them. But there are also many smaller sites that are not so complicated, designers who are working in much simpler environments, and we want CSS to be designed to be simple and easy for them to use, too.

In CSS we try to make it easy to do the obvious thing. If I gave you (a human, not a computer system) a DOM tree and a change function, and said, "do the obvious thing to match the elements across the changes I made", then using whichever of element identity or element ID was available would be pretty reasonable, right?

If you want to do something specific, there's syntax to do that specific thing. If that syntax feels awkward, we can improve it. But purpose of an auto keyword is to make the obvious thing easy to request, and have the UA figure it out. And that's what it's doing here.

[noamr]

@jakearchibald It's not good to fixate on complex websites with complex underlying infrastructure. Sure, there a many websites that use a framework that can enable SPA or MPA rendering, and will switch between them. But there are also many smaller sites that are not so complicated, designers who are working in much simpler environments, and we want CSS to be designed to be simple and easy for them to use, too.

I don't think it's correct to treat this as a dichotomy. We want CSS to work well for the simple cases while not creating inconsistent and confusing behavior for the more complicated ones. A lot of developers find themselves somewhere in between.

In CSS we try to make it easy to do the obvious thing. If I gave you (a human, not a computer system) a DOM tree and a change function, and said, "do the obvious thing to match the elements across the changes I made", then using whichever of element identity or element ID was available would be pretty reasonable, right?

Still, CSS has a clear separation between DOM and styling, with a new and very explicit exception (attr).

If you want to do something specific, there's syntax to do that specific thing. If that syntax feels awkward, we can improve it. But purpose of an auto keyword is to make the obvious thing easy to request, and have the UA figure it out. And that's what it's doing here.

I'm not sure if "match elements by ID and fallback to per-element matching" is "obvious" (on top of a same-document match-element behavior). I'd call it "particular". It does the obvious thing only under specific simplified conditions, and that thing is not similar to anything else in CSS. Using a keyword like auto to do something this particular and novel doesn't seem right.

(I was not entirely at peace with what we ended up with when we resolved but didn't want to pick that battle, but @jakearchibald's arguments here are good I think).

[jakearchibald]

@jakearchibald It's not good to fixate on complex websites with complex underlying infrastructure

I don't think I am. My point is that auto will behave confusingly different on MPA vs SPA. The complexity is hidden behind the word auto.

In CSS we try to make it easy to do the obvious thing

I agree with this, which is exactly why I'm arguing against the behaviour of auto here. It's in no way obvious. It'll work in SPA and be kinda faulty in difficult-to-figure-out ways on MPA.

The separate features of attr(id ident) and match-element don't have this issue. One works the same on MPA and SPA, and another doesn't work on MPA. It avoids the "kinda works, but doesn't in weird ways" issue that auto gives us.

[nt1m]

The complexity is hidden behind the word auto.

This has kind of always been the point of the auto value fwiw. Here are some examples:

• outline-style: auto hides the complexity of the native focus outline
• text-spacing-trim: auto/text-autospace: auto lets the UA pick high quality spacing values
• animation-duration: auto computes the complex duration for scroll-driven animations

I'd be open to tweaking the definition of the auto value, but I think removing it completely is counterproductive. Maybe an improvement could be SPA ? "match-element" : "attr(id ident)".

[jakearchibald]

I think the design goal of view transitions should be to minimise the difference between MPA and SPA as much as possible.

match-element is an unfortunate exception to that, but it's understandable why it's an exception.

It should be obvious when you're choosing to use an SPA only part of view transitions, and I feel match-element does that, since there's no element equality between documents.

auto does not make this obvious at all. If auto produces difficult-to-understand differences between MPA and SPA, it's a bad design.

[noamr]

I'd be open to tweaking the definition of the auto value, but I think removing it completely is counterproductive. Maybe an improvement could be SPA ? "match-element" : "attr(id ident)".

This would be an improvement from how we define auto in the resolution, but I still think the MPA behavior here is too surprising given that nothing else in CSS uses IDs directly in that way, and given that sometimes MPA would match SPA and sometimes it wouldn't if we adopt this.

[bramus]

Maybe an improvement could be SPA ? "match-element" : "attr(id ident)".

Deciding this automagically for authors based on Same-Document VT being used or not would not work on pages that are mainly MPA but also do some SPA things. Think of sites that SPA-ify their MPA with the Navigation API when available. Would be very surprising to suddenly no longer be able to target the div#hero through ::view-transition-*(hero) because of how the VT was triggered.

[jakearchibald]

Summary of my position:

Minimising the difference between MPA and SPA

A goal of the view transition API design should be that, if all else is equal, you get the same transition between two same-document states as different-document states.

The reason for this goal is simply to make the API easy to understand. Assuming this API continues to grow in terms of usage, developers will be working on some projects that use SPA transitions, some that use MPA transitions, or some that use a mix of both (these exist already). Ideally a view transition pseudo, or a view transition property/value pair should mean one thing, rather than requiring the developer to learn lots of behavioural forks between MPA and SPA transitions. The problem with these forks is, without full system knowledge, the results will look like unexpected partial breakages, and be hard to debug.

This applies as much to simple usage as complex usage.

If this isn't the goal, 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. I don't think this is necessary or a good idea, as I think the goal is reasonable, and should be upheld.

The issue with the auto proposal

match-element breaks the above goal, because there's no equivalent between documents. Because of this, it should be kept as an exception. Developers should ideally know they're using part of the API that's only designed for SPA.

auto is an inviting "we'll do the right thing" keyword that hides complexity. That isn't unusual in CSS, and often it's a good thing. But in this case it's taking in that inconsistent match-element behaviour, hiding it behind an inviting keyword, and mixing in some of the attr(id ident) behaviour so breakages are even less consistent and harder to debug.

I get that the intent is for auto is to be obvious and simple, but I do not think that's the case with the current proposal. Developers will take some code that worked great in their project with SPA transitions (or from an article, or from sigh an LLM), and adapt it for their MPA project. But due to view-transition-name: auto, they'll get a partially broken result. Partially, because some parts will work by coincidence due to IDs. According to the spec and implementations, this will be a successful transition, so it will be hard for the developer to figure out what went wrong. This is not obvious and simple.

Proposal for match-element

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. This will make it clear to developers that they're using a feature that doesn't work for these kinds of transitions.

Proposal for auto

Either drop the proposal, or:

For elements, auto uses the element's id attribute value as the transition name. For pseudo-elements, auto uses a combination of the element's id and the pseudo-element name as the transition name.

If the element doesn't have an id attribute (or it's invalid, or the empty string), the transition should fail with the reason reported to the console.

This does more than attr(id ident), but still works equally between MPA and SPA.

[noamr]

I feel better about this proposal than about what's in the spec.

However, for the sake of moving forward, I suggest we ship match-element as per last week's resolution (chrome is nearly ready with implementation/WPTs), and see what kind of community feedback we receive. I would be interested to see if people are surprised that it doesn't work across documents, and how people feel about using attr() for that purpose.

We would be in a better position to make a decision then about what is the obvious behavior of auto.

[jakearchibald]

Another concern with auto, is how it would handle id values of:

• none
• auto
• match-element

[bramus]

That needs to be given some thought beyond the use of auto, as the same problem applies to attr(id <ident>). Food for a new issue I believe?

[jakearchibald]

Yeah, it's a problem with attr too, but in that case I think it's clear that "I want to use the value of the id attribute as the value for view-transition-name", whereas auto does not make that clear.