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

[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);
}

[noamr]

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?

Complex web-apps (think AirBnb), where different teams are responsible for different parts of the document, and the team working on view transitions does not want the transitions to be changed beneath their feet by unrelated changes made in the DOM. match-element() gives them much cleaner guarantees.

[jakearchibald]

@fantasai

the objection subsequently raised here was too late to make any changes to the release

Is it too late to remove it from the next release?

[jakearchibald]

At Shopify we have the same case @noamr mentions, but also we don't want cases where it half-works when we choose to do a cross-document transition.

It's much more reliable to have a feature like match-element that is designed to work same-document only, and the trade-offs are clear. And, have a way to do it that works consistently same-document and cross-document. We already have the latter, but I don't mind a feature that allows attributes to be involved.

auto's current behaviour is unreliable between cross-document and same-document. match-element is at least consistently not intended to work cross-document, and as such I'm glad the name of that feature isn't auto.

[jakearchibald]

Here's an example of the case @noamr is talking about:

Imagine a list of items, where the first is a bigger "main" one. The list is reordered, and the developer wants to create a transition between them.

The developer uses view-transition-name: auto because they read in the Safari release notes that it's great and lets the browser figure out the details. It works!

Then, another team wants to create a skip-link to the main item, so they add id="main-item" to the first item in the list, and ensure that the ID is 'moved' to the new first item when the list is reorganised. As far as this team is aware, IDs are unrelated to view transitions. They haven't seen anything that suggests transitions are tied to IDs in the codebase.

The transition is now broken.

[fantasai]

@jakearchibald As you know, Apple does not comment on future releases. :)

Thanks for the concrete example, that helps.

[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: use the `match-element` keyword for this and disallow it as a value in vt1 spec

The full IRC log of that discussion

<bramus> noamr: we have a way to generate v-t-names with the keyword `auto`.
<bramus> … auto generates name based on the id attribute or element identity when two elements on both end of the VT are the same.
<bramus> … the id approach also works cross-document
<bramus> … are proposing other value where it does not try to do the `[id]` check first. only uses element identity, only working in same-doc VTs
<JakeA> q+
<bramus> … in the breakout for VTs a few weeks ago elika proposed match-element which we like
<bramus> … are proposing to put that as a function for the purpose of feature detection
<bramus> … because right now `v-t-n: match-element` parses as supported
<bramus> … important to ship both things together. bigger groups of people who ship sites need a better layering.
<Rossen1> q?
<bramus> … auto has a better default behavior, but want to allow people to use a cleane rseparation if they so choose
<Rossen1> ack fantasai
<Zakim> fantasai, you wanted to comment on parsin and to comment on parsing
<bramus> fantasai: so the v-t-n accepts none an dcustom ident, which start with double dash
<bramus> … browsers should be rejecting any value that does not start with --
<bramus> … dont think we should introduce `()`
<bramus> bramus: dashed idents are subset of custom idents
<emilio> q+
<vmpstr> +1
<bramus> fantasai: oh, right. still dont like the parenthesis
<Rossen1> ack JakeA
<fantasai> fantasai: implies there's argument, but definitely there's none
<bramus> JakeA: I think we should unship/unspec `auto` as it exists now
<bramus> … aim of VTs was to have same behavior for same-doc and cross-doc
<bramus> … `match-element` is a useful departure from that but need to make it clear that the behavior only works in one of the two
<bramus> … `auto` muddies the water as it has `match-elemetn` but also `[id]` and creates this half-working feature but definitely different between MPA and SAP
<bramus> … I dont think that `auto` as “will do it all for you” here
<bramus> … might come up with other triggers like hover - should make sure definition of a transition is the same
<Rossen1> ack emilio
<bramus> emilio: strong agree with fantasai. no need for (). lot of other props with similar syntax restrict which idents they can parse
<JakeA> q+
<noamr> q+
<bramus> … am sure we can come up with an ident that is not a compat conceren
<Rossen1> ack fantasai
<bramus> fantasai: like to focus on noam’s ask of whether we add match element.
<bramus> … lets discuss meaning of auto later
<Rossen1> ack JakeA
<bramus> JakeA: i want to make sure that `match-element` is not as useful as people think it is
<bramus> … similar in codepen/tech demos
<bramus> … but if you are doing a page transition, its common for simple case to replace large parts of the DOM using innerHTML, which are different elements
<bramus> … element equality is not guaranteed
<Rossen1> ack noamr
<JakeA> That's an argument for not adding this behaviour into something like `auto`
<bramus> noamr: regarding compat: we could go back to CSS vt-1 and make it an illegal keyword
<JakeA> …because it's a complex behaviour and you need to know what you're opting into
<bramus> … think about compat is not about whether sites use it, its whether sites would catch it
<dbaron> For what it's worth, I think I have different opinions about element equality: https://dbaron.org/log/20200221-dom-identity
<JakeA> q+
<bramus> … to go back to vt-1 then say that its illegal, then new implementations can do that
<bramus> … instead of try and parsing it as a name
<bramus> … but right now in current implementations it does parse
<bramus> q+
<Rossen1> ack fantasai
<bramus> fantasai: there is a wide grey area in types of ?? and web apps between a demo page and sth that is using a particular framework style
<bramus> … we should be designing CSS to be usable and comfortable to it
<bramus> … I reject his argument that element identity is not useful at all
<Rossen1> ack JakeA
<bramus> JakeA: didnt say it wasnt usefull at all, but that it is less useful
<fantasai> s/at all/at all on real websites/
<bramus> … I covered other ground of simple page changes that fetch data and innerHTML it
<noamr> agree that match-element is useful for a lot of the spectrum, but attr() and ident() can cover a lot of the more complex/frameworky cases
<bramus> … in all simple demos I created they use innerHTML
<bramus> … widely used pattern, outside of frameworks
<bramus> JakeA: I am worrried about kicking the auto discussion down the road
<bramus> … concerns were raised in october and safari shipped in december
<bramus> … not covering now could leave us stuck with it
<bramus> fantasai: given that chrome is not even shipping can indicatate that its a really useful feature
<astearns> -1 to the practice of allowing browsers to ship things and then see if compat issues come up
<bramus> … if we both shippped it and it was harmful then ???
<bramus> … fine to discuss, but dont think we need to resolve
<JakeA> q+
<fantasai> s/???/it would be urgent to remove/
<fantasai> s/resolve/resolve today necessarily/
<Rossen1> ack JakeA
<bramus> JakeA: agree with it just being safari then there is less of a riks
<bramus> … but dont like that being used as an excuse
<bramus> … more worried about that if it does get used, it’s sold as a “we’ll do things for you” but it has footguns detailed in the thread
<astearns> q+
<bramus> … could block us from doing useful things in the future
<Rossen1> ack bramus
<noamr> bramus: re match-element being a function, it solves a short term, while in the long term a keyword would be best
<noamr> bramus: fine with match-element as a keyword, even without it being feature-detectable
<fantasai> +1 let's design for hte ong term
<fantasai> s/hte ong/the long/
<Rossen1> ack astearns
<bramus> astearns: at the very least I would appreciate it if the Safari would stop talking about the `auto` value until we figure out whether we can support it long term or want it to go away
<noamr> astearns: at the very least I would appreciate it if the Safari folks would not talk about the auto value until we figure out if we want to support it long term
<bramus> … the less it gets evanglized the more options we have in the future
<bramus> Rossen1: ok, let’s see if we can wrap this up
<bramus> noamr: proposed resolution would be then to have match-element as keyword and thus to disallow it as a name in v-t-1
<JakeA> +1 to `match-element`
<bramus> Rossen1: Any additional feedback or objections?
<bramus> fantasai: overall sounds good
<bramus> … did we call the other names? `self` and `match-element`
<bramus> … tab commented we should have a keyword that also works equally well in `random()`
<bramus> Rossen1: which one of the two is currently being used int he issue or spec?
<bramus> fantasai: mostly `match-element` is used
<bramus> Rossen1: can we stick to that for now and bikshed later?
<vmpstr> +1 to `match-element`
<Rossen1> ack fantasai
<bramus> noamr: this is already result of a lot of bikshedding inthe issue and a breakout before
<bramus> … I suggested `self` but like `match-element` today
<bramus> Rossen1: OK
<JakeA> (I'm not tied to the name `match-element`, as long as it's a name that suggests the behaviour as much as possible)
<bramus> RESOLVED: use the `match-element` keyword for this and disallow it as a value in vt1 spec

[jakearchibald]

@fantasai you've mentioned a few times that I'm not thinking about a broad range of web site builds in my arguments here. I really don't think that's the case.

Build style 1: a component demo in codepen

match-element and therefore auto works well here. However, the reason it works well is because it's a demo of a component in isolation. Once you try and make it work as part of a page, you run into issues relating to view transitions operating over the whole document, when you're really trying to make a component transition.

What we really need here is scoped view transitions, and I think match-element becomes much more interesting in this case. Since scoped view transitions are always same-document, I don't think we need auto's ID behaviour.

Build style 2: a simple no-framework page transition

The most common way people hand-roll SPA style page loads, in a progressive enhancing way, is to load the HTML of the target page and inject it into the current page via something like innerHTML. This is kinda AJAX 101, but it's been packaged up and called various things, such as TurboLinks.

I used this style for my basic view-transition demos because it only takes a couple of lines of JS using the navigation API.

But, the result of this is that some things that are intended to be the same are different elements, such as the header in the example above.

match-element isn't useful here. I could make auto work by adding IDs, but they're vulnerable to the footguns already outlined in this thread.

A more stable solution here would be assigning unique view-transition-names deliberately, which are as easy to add as IDs. But I'm interested in the proposals that allow names to be built up using attributes from the current element and its ancestors.

Build style 3: VDOM frameworks

I know there's a lot of distaste for frameworks in this group, and I recognise their issues, but they are popular. In this system you sometimes get element equality, but sometimes you don't. It's mostly an optimisation.

If an element stays within the same parent, you can usually keep the same element instance intentionally. However, folks often get this wrong, and end up with new elements, or worse, element equality with something else.

match-element is kinda tricky in this case, but will work in some cases. Again, auto could work by adding IDs, but there are footguns that can be avoided by assigning a unique view-transition-name, and the latter doesn't have the footguns that auto has.

---

I promise you I'm not coming at this from a framework-first perspective. I've built sites by dragging HTML files into an FTP client, and PHP with progressive enhancement, and all the way up to big horrible framework sites. I'm drawing on all of those styles in my recommendation here.

It looks to me like view-transition-name: auto has been designed after looking at a couple of codepen demos, because the design isn't helpful when you try and scale it beyond that. We shouldn't be designing APIs that are only useful in tech demos, and we definitely shouldn't be using a "this is what you want" name like auto for those patterns.

I'm happy that we're shipping match-element, because it will be useful in some cases, including tech demos. I think it'll be more useful in scoped view transitions. But it shouldn't be the first thing you reach for unless you know how it works.