[css-view-transitions-2] Allow changing `types` using JS after (MPA) transition started?

[noamr]

Currently we're only allowing to set the transition types at startViewTransition, and they can get changed when revealing the new document in a cross-document view transition.

But perhaps we can allow the author to read or change the types programmatically, as a DOMTokenList on the VT object?
Something like this:

document.addEventListener("pagereveal", event => {
  const {viewTransition} = event;
  const hasSlideIn = viewTransition.typeList.has("slide-in");
  if (heroImage.loaded) {
     viewTransition.typeList.toggle("expand-hero", true);
  }
});

Note that this is possible to do today using the CSSOM, but not dynamically while the VT is already running.

[noamr]

Proposed resolution from internal sync: have a typeList attribute in a ViewTransition object that can mutate types at any point.

[css-meeting-bot]

The CSS Working Group just discussed [css-view-transitions-2] Allow changing `types` using JS after (MPA) transition started?, and agreed to the following:

• RESOLVED: Add a mutable .typeList to the VT object

The full IRC log of that discussion

<TabAtkins> noamr: These issues are related, and not very big, just finishing up
<TabAtkins> noamr: We want to make types mutable.
<TabAtkins> noamr: Refresher, types let you define a "masterclass" for the whoel transition. Set a type when you start the VT, can pass types to the function, then can select based on that type with the VT pseudos
<TabAtkins> noamr: So you can use several transition styles in the same page without having to manually swap them out with JS
<TabAtkins> noamr: So we wanted to allow changing those types on the VT object.
<TabAtkins> noamr: Proposed resolution has details, but it's to have .typeList on the VT object, a DOMTokenList like .classList
<TabAtkins> noamr: And it works just like changing classes
<astearns> q+
<TabAtkins> noamr: We foudn this useful for cross-document VTs
<TabAtkins> noamr: sometimes, only after you get the reveal event you know what the type is gonna be
<TabAtkins> noamr: maybe some image you expected has or hasn't loaded in the new page, etc
<TabAtkins> noamr: So changing the types seems flexible enough
<TabAtkins> astearns: when you change the typelist in JS, it will no longer match what was specified in your CSS for the VT
<TabAtkins> astearns: I'm guessing that's okay and intended, because as the VT is going you maynot have access to that CSS anymore
<khush> q?
<astearns> ack astearns
<TabAtkins> noamr: Right. First for SPA VTs you define the types in JS anyway. For cross-doc tho, you're correct
<TabAtkins> noamr: We read the VT from CSS in exactly two places - when you're ready to leave the old doc, and ready to present the new doc.
<bramus> q+
<TabAtkins> noamr: In these cases we'll read the CSS, then in the events you can change the types via the VT object
<astearns> ack bramus
<TabAtkins> bramus: Like this in general.
<TabAtkins> bramus: Maybe we should also rename the types property that we pass into the VT starting function
<TabAtkins> bramus: it's "types" in one function, "typeList" on the VT object
<TabAtkins> noamr: Yeah, it's called "type" when you start the VT, but there it's an array, here it's a token list. This is equivalent to "class" and "classLIst"
<TabAtkins> bramus: Ah then there's a typo in the spec saying "types"
<TabAtkins> noamr: Ah I'll fix
<TabAtkins> astearns: proposed resolution: mutable .typeList on the VT object. Objections?
<TabAtkins> RESOLVED: Add a mutable .typeList to the VT object

[bramus]

Follow-up issue about the type argument which was brought up in the meeting: #10070