Re: [csswg-drafts] [css-view-transitions-2] Declarative opt-in for cross-document navigations (#8048)

> One reason to prefer @navigation over @media could be to limit what is allowed inside of the block.

We can limit what's allowed inside the block either way. If you use the `navigation: foo` query then that `@media` block can activate whatever restrictions are necessary.

> The question is, what are the use cases for SPAs that aren't covered by the existing features?

The SPA feature request is at https://github.com/w3c/csswg-drafts/issues/8960. Maybe @ydaniv can provide us the concrete details. I'd say this feature request can apply to cross-document (MPA) cases as well.

At a high level, the transition is from/to a UI state which has a semantic meaning and that's not always visible to the user agent. For example, you can say that if the page's URL is `foo.html/home` then its the home page. Providing some way to apply CSS based on the old/new Document's URL is enough to customize a transition from/to the home page. But the home page could have a different UI depending on whether the user is signed in. So we want some API for the author to provide a custom ident identifying a transition and then be able to use it in CSS to customize animations for that transition.

> The indirection is there to support non-navigation SPA (startViewTransition({groupName: "refreshing"}). Otherwise you'd have to bring all this jazz into startViewTransition or make it very coupled with the navigation API

That's fine for cases that the user agent can't know about but it seems silly to force the authors to use the pattern below for known cases, instead of being able to use the foo qualifier directly in the media-query (or something else):

```css
@view-transition :foo {
  navigation-trigger: cross-document;
  view-transition-group: foo;
}

@media (view-transition-group: foo) { ... }
```

I think the fundamental questions based on the discussion above (and in the meeting) we need to answer before diving into the exact syntax are:

1. Authors need the capability to conditionally apply any CSS based on the type of navigation to support basic customization. Something like:
   
   ```css
   @media (navigation: back) {
      #back-button { view-transition-name: back-button; }
   }
   ```
   
   This is being done in SPAs using script since the information is available via the `navigate` event. If we don't provide a CSS way, authors will have to use script. Also, while the `navigate` event makes it trivial to get this info on the old Document, there is no such event on the new Document. So authors will have to do hacks to pass along this information to the new Document somehow (link decoration, sessionStorage API, etc.).
   
   The options considered are media-queries, pseudo-class, a new `@navigation` at-rule. The problem for defining the lifetime of a particular navigation state in the style system is the same regardless of the syntax chosen.

2. If we want reload to be default off, then there is no way to do that without including it within the opt-in at-rule based on the options being considered in 1. Since reloads are also a potential customization case, and should be one of the nav types in 1 above, ideal way would've been for UA CSS to make it off unless the author explicitly enables it for reloads.

So let's resolve on how we want to handle 1? Whether we want CSS to solve this and how; or recommend that authors use existing script hooks on the old Document and probably introduce a script hook on the new Document which provides that info. @domenic @fantasai for an opinion.

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


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

Received on Thursday, 10 August 2023 20:00:10 UTC