[css-view-transitions-1] Disallow the name auto as view-transition-name

[nt1m]

Currently the name auto is allowed as view-transition-name. Given the talk about view-transition "classes" in #8319. I think it would be good to resolve on reserving the "auto" keyword so it can be leveraged if needed.

I'm opening this as a separate issue since this is probably something we want to change in VT level 1 rather than level 2.

@khushalsagar @fantasai @tabatkins @noamr

[tabatkins]

Yup, sounds good to me.

[noamr]

I'm not sure if we'll have to use `auto for #8319, but I'm fine with disallowing it as a vt name.

[bramus]

Agenda+’ing this. The sooner we do this, the better.

[css-meeting-bot]

The CSS Working Group just discussed [css-view-transitions-1] Disallow the name `auto` as `view-transition-name` , and agreed to the following:

• RESOLVED: disallow auto for view-transitions-name/view-transitions

The full IRC log of that discussion

<frances__> bramus: right now the property transition view name accepts custom in #8319, might be feasible to add alternate shorthand name, use value of auto in that case
<fantasai> bramus: this would create a conflict with view-transition-name, so propose to disallow auto
<bramus> s/custom/custom-ident
<frances__> RESOLUTION: disallow auto for view transitions
<fantasai> s/RESOLUTION/RESOLVED/
<fantasai> s/view transitions/view-transition-name/
<frances__> RESOLUTION: disallow auto for view-transitions-name/view-transitions
<frances__> rossen: keep going to next issue

[noamr]

@bramus @nt1m what do you expect when someone uses auto today? Same as none/having no view-transition-name?

[nt1m]

@bramus @nt1m what do you expect when someone uses auto today? Same as none/having no view-transition-name?

It should be rejected until it does something useful. I would expect it to provide a name automatically for view transitions. It's useful in the case you have a class for instance and but don't want to provide a name to every single element that is affected by that class.

[noamr]

@bramus @nt1m what do you expect when someone uses auto today? Same as none/having no view-transition-name?

It should be rejected until it does something useful. I would expect it to provide a name automatically for view transitions. It's useful in the case you have a class for instance and but don't want to provide a name to every single element that is affected by that class.

"Rejected" as in reject the whole transition?

[noamr]

btw I don't think the name auto would be a solution for generating names because it's not something that can effectively work across documents. I think it would have to be something that generates a name from capturing attributes along the element's ancestor chain. envisioning something like:

section.list li.item[:id] img { view-transition-name: item-[:id]  }

or some such

[nt1m]

"Rejected" as in reject the whole transition?

"Rejected" as in rejected by the CSS parser, so if you set it on the root, then it won't override view-transition-name: root set by the UA stylesheet. If you set it on another element, it'll just behave as view-transition-name: none.

It should be pretty obvious for the developer they're using an unsupported value as it'll be striked out in the DevTools.

[nt1m]

btw I don't think the name auto would be a solution for generating names because it's not something that can effectively work across documents. I think it would have to be something that generates a name from capturing attributes along the element's ancestor chain. envisioning something like:
section.list li.item[:id] img { view-transition-name: item-[:id] }
or some such

Sounds effectively like attr().

[noamr]

btw I don't think the name auto would be a solution for generating names because it's not something that can effectively work across documents. I think it would have to be something that generates a name from capturing attributes along the element's ancestor chain. envisioning something like:
section.list li.item[:id] img { view-transition-name: item-[:id] }
or some such

Sounds effectively like attr().

Yea, something like that was proposed in #8320 (comment). In either case it probably won't be a single keyword that generates a name.

[nt1m]

In any case, I don't think leaving auto as a valid ident value does any service to developers fwiw.

[noamr]

In any case, I don't think leaving auto as a valid ident value does any service to developers fwiw.

OK. The only difference between having it as an invalid value and having it behave the same as none is that it would serialize as none.

[nt1m]

The other differences are:

• It won't participate in the cascade (so it won't override another name like root)
• It'll be clearly striked out in DevTools as an invalid value
• The auto keyword can be reused for something else (if ever needed)

[bramus]

(#) Sounds effectively like attr().

Key difference here is that you’re able to capture an attribute from a parent element and use it in a child element. With attr() you’d need to store the [id] of the li into a variable to pass it onto the child img element.

/* Proposal by noamr */
section.list li.item[:id] img {
  view-transition-name: item-[:id];
}

/* Reworked using attr() and ident() from https://github.com/w3c/csswg-drafts/issues/9141 */
section.list li.item[id] {
  --id: attr(id);

  img {
    view-transition-name: ident("item-" var(--id));
  }
}

[nt1m]

WPT PR: web-platform-tests/wpt#44035