[css-view-transitions-2] How are auto-generated `view-transition-name`s exposed in JS APIs

[noamr]

Requesting a clarification for this resolution.
Do we want ::view-transition-{group|old|new|image-pair}(auto) to match pseudo-elements generated from the auto keywords, or do people need to use only classes to style them?

/cc @nt1m @fantasai @khushalsagar @vmpstr

[khushalsagar]

I'd be fine either way. Ideally authors would use the view transition class but I don't see the harm in allowing auto to match any pseudo with an auto generated name.

Relates question, what should be the name of the pseudo for Animation objects returned by getAnimations. Should it also be ::view-transition-group(auto)?

[nt1m]

Same opinion as Khushal, maybe @fantasai has more opinions?

[noamr]

Also, how should auto pseudo-elements appear in getAnimations({subtree: true})[...].effect.pseudoElement ? Probably also as auto? Or as *?

[bramus]

Exposing these as auto seems fine. Authors shouldn’t try to read the generated name for later use. In that case they should give the element a proper view-transition-name.

The net result is that you can end up with multiple ::view-transition-group(auto) entries in the ::view-transition pseudo, which I believe is OK.

[bramus]

To clarify my previous comment: I'm fine with exposing as auto in case the name was generated. If the name was derived from an attribute, then that attribute value would show up.

[fantasai]

@bramus I wonder if the name derived from an attribute should be in a different namespace, e.g. ::view-transition-group(#name).

[css-meeting-bot]

The CSS Working Group just discussed [css-view-transitions-2] How are auto-generated `view-transition-name`s exposed in JS APIs, and agreed to the following:

• ACTION: Open new issue about whether `auto` exposes the ID from the ID attribute as a view-transition-name for pseudo-element matching
• RESOLVED: [Pending async confirmation] we will use `match-element` in the Animations API when element identity is used

The full IRC log of that discussion

<bramus> noamr: how do autogenerated appear in things like getAnimations?
<khush> q+
<bramus> … what would these auto-generated ones look like? Aavailble as strings? Or give them a name of `match-element` or `*` or not show them at all?
<fantasai> ACTION: Open new issue about whether `auto` exposes the ID from the ID attribute as a view-transition-name for pseudo-element matching
<bramus> bramus: and devtools?
<astearns> ack khush
<bramus> noamr: no, not included
<bramus> khush: two options
<bramus> … if we decied that id based names ar ehidden from css then it makes sense to hide everything from auto
<bramus> … or if name came from id attribute then do expose it but dont expose the identity ones (and expose those as `match-element`)
<bramus> q+
<bramus> astearns: the ids that auto uses could be made opaque but if the author uses the attr() fn then they would be exposed?
<bramus> khush: thats the complication with hiding ids
<bramus> … if you use attr() then you have all those complications of where you get the strings from
<astearns> ack bramus
<bramus> … can punt on this until we decide how to namespace ids
<noamr> q+
<fantasai> bramus: if value derived from ID attribute and expose it, if you have an element with an ID on one page and a different one on a different page with a view-transition-name of hero, then one transitions to the other
<fantasai> bramus: would be useful to expose that name
<fantasai> bramus: if we fall back to match-element strategy, then show that as match-element
<fantasai> bramus: because authors can't target those elements directly
<fantasai> bramus: by having match-element there, clearly can't target
<bramus> fantasai: q about whether id on one page would match a v-t-n on other is part of the namespacing discussion
<bramus> … dont have an opionion on direction
<bramus> … if that worked, then we should make pseudos match that
<bramus> … but q is then should that work in the first place?
<bramus> … do we want to expose the name derived from an id in the first place? no opinion right now.
<bramus> … obviously should not expose autogenerated names
<astearns> ack noamr
<bramus> noamr: strong opinion about keeping things simple… if generated by id its just that name
<bramus> … already doing complicated things that look different
<bramus> … if the v-t-name comes from an id, then that should be the v-t-n
<bramus> … if author dont want that, they should do other things
<bramus> … lets keep things flat
<khush> q+
<bramus> … regardless we can resolve to use the name `match-element` in `getAnimations`
<astearns> ack khush
<bramus> khush: since we are going here … my alignment is wit noam on this. keep it simpel and treat them as names
<bramus> … dont have author feedback on this though
<bramus> … not a super strong opinion
<bramus> … if this pattern is adopted like anchor-name and there is no matching concept, do we want to have this namespacing concept across css props then?
<bramus> … then VT wont have this own special thing
<bramus> q+
<bramus> … concept would make sense across CSS
<bramus> fantasai: none of the others have a way of pulling element id
<bramus> khush: but can imagine anchor-pos doing the same over time
<astearns> ack bramus
<noamr> I like that auto === id ? attr(id) : match-element
<bramus> bramus: missed
<bramus> astearns: but flatness isnt part of the issue
<bramus> khush: lets thing about that a bit more
<bramus> s/khush/noamr
<bramus> noamr: lets resolve on exposing them as `match-element`
<bramus> astearns: is ther ea conclict there?
<bramus> noamr: its just in getAnimations
<bramus> astearns: which is wrapped in a pseudo
<bramus> khush: compat risk for users that have used `match-element`
<bramus> bramus: dont think anyone has used that yet
<bramus> khush: so if you use auto and we use the id attr then we expose the id attr as string, and if we use identity then we expose match-element
<bramus> noamr: and tbd if these id-based names are namespaced or not
<bramus> astearns: should open an issue that
<bramus> khush: can do that
<bramus> PROPOSED RESOLUTION: we will use `match-element` in the Animations API when element identity is used
<bramus> astearns: objections?
<bramus> (silence)
<bramus> RESOLVED: [Pending async confirmation] we will use `match-element` in the Animations API when element identity is used

[bramus]

@bramus I wonder if the name derived from an attribute should be in a different namespace, e.g. ::view-transition-group(#name).

@khushalsagar filed #11112 for that :)

[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: we will use match-element in the Animations API when element identity is used