Re: [csswg-drafts] [css-view-transitions-2] Behavior of mismatching types between old and new document (#9526)

> Hmm, since there's no Javascript API, are you thinking authors will use CSSOM to insert the appropriate @view-transition (or modify an existing) rule? I suspect this might be non-trivial in complex cases given they might have to pick out the correct one manually.

Good point. That's what I was thinking but didn't realize the clunkiness of using CSSOM. One idea based on a couple of related issues: #9542 and #9595. Add a couple of attributes to the ViewTransition IDL and keep the timing for parsing the CSS opt-in [here](https://drafts.csswg.org/css-view-transitions-2/#ref-for-document-resolve-cross-document-view-transition:~:text=Let%20transition%20be%20the%20result%20of%20resolving%20cross%2Ddocument%20view%2Dtransition%20for%20document.) as-is.

```
interface ViewTransition {
  readonly attribute oldTypes;
  attribute types;
};
```

- Before dispatching the `reveal` event, browser parses the opt-in rule to get the declarative types. `oldTypes` is types from the old Document. `types` is from the new Document and the list which is currently being applied.
- In the `reveal` event, the developer can overwrite `types` to whatever value they want. So by default (and with no script) you get option 1. But authors can trivially use `oldTypes` and `types` to implement option 2, 3 or 4.
- In the SPA case, `oldTypes` and `types` will start off with the same value but authors can similarly overwrite `types` whenever needed.

-- 
GitHub Notification of comment by khushalsagar
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9526#issuecomment-1811768008 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 15 November 2023 03:52:55 UTC