Re: [csswg-drafts] [css-view-transitions-2] Should ViewTransitions be triggered for browser initiated navigations (#8783)

Thanks for the feedback @domenic. Putting a CSS snippet for the resolved syntax for context on the replies below. This would be valid CSS for both the old and new Documents.

```css
/* This rule is used to decide whether a View Transition will be done for a navigation */
@view-transition {
   /* This is a transition opt-in for all navigations classified as "auto" */
   navigation: auto;
   
   /* This is a developer provided custom ident to conditionally apply CSS specific to a transition */
   type: home-to-back;
}

@media (prefers-reduced-motion) {
    @view-transition {
       /* This is a transition opt-out for all navigations */
       navigation: none;
    }
}

/* Example of how type is used to activate CSS specific to a transition */
html:active-view-transition(home-to-back) #target {
   view-transition-name: target;
}
```

> I think there are some implicit filters here that are not stated. Something like, cross-document, and same-origin? Can someone confirm?

Just to clarify why this isn't obvious. We broke down the parameters to identify a navigation as-follows:

- Source or destination URL
   This implicitly identifies whether the navigation is same-origin. Currently the CSS opt-in applies to all same-origin URLs. Authors will have to use script if they need to enable transitions to specific URLs. We'll eventually add from/to descriptors to the at-rule to make it declarative.

- Same vs cross document
   Currently the CSS opt-in only applies to same-document navigations. Authors can trigger a transition via `document.startViewTransition()`. We've discussed opening this up to same-document navigations but how is TBD. Should be a new descriptor if it needs to be in the at-rule.

- Everything else
   This is what the `navigation` descriptor is supposed to cover.

The goal of this issue it to define the values for the `navigation` descriptor and which navigation each one matches with. Based on your feedback, I think the following keywords makes sense:

* `all`: This matches all navigations that are observable with the `navigation` API and is an opt-in. Authors would use this if they are setting up the opt-in via script events (like `navigate`) on the old Document and `activationInfo` on the new Document.

* `none`:  This matches all navigations that are observable with the `navigation` API and is an opt-out.

* `auto`: This matches all navigations the author is guaranteed to expect: link clicks/author-initiated  (IIUC the spec way to say this would be user navigation involvement != "browser UI") *except* reload. We're excluding reload based on developer feedback (see https://github.com/w3c/csswg-drafts/issues/8784).

> So it's only for truly-simple cases ... that you want to create new CSS keywords

Agreed. Btw, since the CSS at-rule is both an opt-in and a setter for type, the latter is another motivation for new CSS keywords. For example, it would be common to customize a directional animation based on whether its a back or fwd navigation. But I agree that we should add it once there's been enough use of the JS API and we see what the common patterns are.

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


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

Received on Friday, 17 November 2023 22:33:28 UTC