[css-view-transitions-2] Namespacing id vs css based view transition names

[khushalsagar]

In https://github.com/w3c/csswg-drafts/issues/10995, we resolved that auto will figure out the name for an element based on its id (if available) or fallback to node identity. The question is how the id based name interacts with css based names set up as view-transition-name: foo. A possible edge case is where the id on an element collides with the name specified for a different element in CSS.

So the options here are:

1. Id based names are not special, they are treated same as custom idents directly specified in CSS.
2. Id based names are namespaced separately by the UA. The name has a # prefix to indicate that it's ID based to be used in CSS and script APIs. For example, ::view-transition-group(#foo) for an ID based name instead of ::view-transition-group(foo) for a CSS based name.

I'm more in favour of (1). It's simple to understand, doesn't require knowing the customization code to understand how naming is being done. And I can't think of a use-case where the author would want/need this distinction. They'd likely be sticking to a consistent naming strategy. OTOH, this means that it won't be possible to match an ID based name on one Document with a CSS based name on another Document.

@fantasai @nt1m @emilio @noamr @bramus

[bramus]

I’m all for option 1:

• It’s much much simpler to reason about.
• There are a demos that currently do #card-n { view-transition-name: card-n; } so authors are fine with the names being shared.
• I would expect the outcome of auto to be the same as attr(id <ident>) on an element with an [id] attribute set.
• It allows transitions from view-transition-name: hero on page A to img#hero on page B. Think of page A being an overview page with lots of items and the author setting the view-transition-name on the fly to make sure that the clicked thumbnail morphs into the img#hero on page B

[jakearchibald]

I really think 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 ID behaviour should be left to attr(id <ident>), which also gives you the answer to this issue.

[noamr]

I really think 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 ID behaviour should be left to attr(id <ident>), which also gives you the answer to this issue.

How would you fall back to match-element here?

[jakearchibald]

How would you fall back to match-element here?

I don't see the need for this. These are two very different behaviours. I want to pick the one I want.

[noamr]

How would you fall back to match-element here?

I don't see the need for this. These are two very different behaviours. I want to pick the one I want.

I personally never felt strongly about the ID thing so leaving this to @fantasai and @nt1m. I do feel that it creates complexity and inconsistency and I am not sure if the MPA benefit is worth it

[jakearchibald]

I guess it's off-topic here, so I posted my thoughts in https://github.com/w3c/csswg-drafts/issues/10995#issuecomment-2449805338