@preemptive-view-transition vs. preemptive-trigger descriptor

[bokand]

The API needs some way to specify an animation timeline that will trigger the view transition. I can think of two high level options:

1) Add a separate @-rule that's specific to preemptive view transitions

2) Add a descriptor in the existing @view-transition at-rule

Option 1 means we'd have to duplicate any other kinds of descriptor parsing between the two @-rules, for example types. With option 2 it's also convenient for authors to handle both discrete and gesture-triggered transitions with the same style:

@view-transition {
  navigation: auto; /* filter to back-navigations in pageswap */
  preemptive-trigger: -ua-gesture-back;
  types: backnavigation;
}

OTOH, I'm not sure yet the two can co-exist - the responsibility is on the author would to filter out navigations that don't apply to the preemptive trigger. Any kind of setup they do for the navigation-triggered transition won't apply since we won't be able to fire pageswap (when gesture, and thus the transition, start) for a preemptive transition (see #2) .

[khushalsagar]

I was originally in favour of the separate @-rule option. Based on the assumption that navigation won't make sense for the pre-emptive case since the author can't control where the gesture will navigate to.

But the purpose of navigation isn't to clarify where a transition should navigate. Its that if there is a navigation of this type, then this rule should apply. So actually having premptive-trigger to @view-transition makes sense. The author can say that if the specified premptive-trigger navigates to the navigation specified via navigation, then there should be VT tied to that gesture? This will fit nicely with other descriptors like from/to planned for this at-rule.

[bokand]

Right - my view of the at-rule is that it's a filter for navigation properties that will match this view-transition. By that interpretation, I think it could make sense to put it in here.

thinking ahead a bit - if a gesture push navigates (e.g. carousel to next page) it'll have to have the URL associated with it. @flackr argued, and I agree, that the navigation should happen automatically so we'd need something like this:

@view-transition {
  navigation: auto;
  preemptive-trigger: --forward-scroll-timeline url(https://example.com/next.html);
  to: url(https://example.com/foo.html);
}

(-ua-gesture-back implicitly has the URL from the session history)

since the author can't control where the gesture will navigate to.

The author does control this? -ua-gesture-back is always session history back. Other timelines will always be push/replace I think with an author specified URL.

I guess the question is how it interacts with the other descriptors. I think OR semantics make sense since the trigger is a combination of to URL and navigation-type.

So something like:

@view-transition {
  navigation: none;
  preemptive-trigger: --forward-scroll-timeline url(https://example.com/next.html);
  preemptive-trigger: -ua-back-gesture;
}

Would disable all MPA transitions except those triggered by the given timeline and back gesture. Does that make sense?

[bokand]

One other (maybe bad) idea is to make it an input into to:

@view-transition {
  navigation: auto;
  to: preemptive(--forward-scroll-timeline, url(next.html)),
      url(home.html);
}

[khushalsagar]

@flackr argued, and I agree, that the navigation should happen automatically

Agreed with this!

I still find it somewhat confusing to add the target URL to the at-rule, because I like the way you phrased how it is understood today: "my view of the at-rule is that it's a filter for navigation properties that will match this view-transition".

I'm wondering if we should have separate syntax for the author to specify the action associated with a gesture. At this time the only action I can think of is a navigation but maybe you have more use-cases in mind. It could be something like:

@gesture-action {
   trigger: --ua-timeline-name;
   navigate: url(next.html);
}

And using the back/fwd timeline here would be invalid since we don't allow overriding the action for those. Then the semantics would be that an overscroll gesture specified by trigger performs the given action. And whether that gesture is also accompanied by a visual animation via ViewTransition is defined by @view-transition. This allows you to completely declaratively specify types as well. For example:

@view-transition {
  navigation: auto;
  preemptive-trigger: -ua-gesture-back;
  to: url(back-1.html);
  types: back-1;
}

@view-transition {
  navigation: auto;
  preemptive-trigger: -ua-gesture-back;
  to: url(back-2.html);
  types: back-2;
}

Also also not run a ViewTransition if the user has prefers-reduced-motion, instead adding a simple chevron for instance.

[khushalsagar]

One other thought, we should allow authors to trigger a same-document ViewTransition as well for these gestures. Currently @view-transition is limited to cross-document transitions.

I can see 2 ways an author could do this:

• The event which informs the author that a gesture has started is used to call document.startVT and then the timeline allows scrubbing all the animations using it. This is not ideal because it requires updating the DOM before the gesture commits. But still a mode we should support in case the author doesn't want to use VT for their animations.

• We expand the @view-transition rule to include same-document navigations. This did come up as a potential addition to the navigation descriptor. I'm not sure if its doable for all same-document navigations since they can be done synchronously, but should definitely be doable for the gesture case.

  This would allow the browser to provide the cached screenshot for the pre-nav DOM state so the transition model can be the same for both same-document and cross-document cases.

[bokand]

Re your proposal:

@gesture-action {
   trigger: --ua-timeline-name;
   navigate: url(next.html);
}

And using the back/fwd timeline here would be invalid since we don't allow overriding the action for those. Then the semantics would be that an overscroll gesture specified by trigger performs the given action

Can you help me understand this...would this be useful/usable on its own? i.e. without a view transition, would the navigation be triggered when the the currentTime of the timeline starts to move or when it reaches the end of the timeline? If it's at the start then it doesn't seem very useful as a separate thing from view transitions and feels like odd UX. If it's at the end then it doesn't seem useful for VT since the VT doesn't kick in until the navigation starts.

I'm also a bit confused by your second example:

@view-transition {
  navigation: auto;
  preemptive-trigger: -ua-gesture-back;
  to: url(back-1.html);
  types: back-1;
}

...

Since you mentioned "I still find it somewhat confusing to add the target URL to the at-rule" and it still has a preemptive-trigger so I'm not sure how this interacts with your proposed @gesture-action but I'm maybe not understanding it correctly?

[khushalsagar]

Can you help me understand this...would this be useful/usable on its own?

Yea, I was thinking about how we have the chevron on Android today. There's no visual animation involving the 2 pages but you have this button that animates to indicate what the gesture will do. An author might want to do something similar for prefers-reduced-motion? So it's nice to have the action for a gesture (navigate to foo) be disjoint from whether that action has a view transition.

I'm also a bit confused by your second example

The navigation, to and types descriptor are part of the VT descriptor in general. Following the pattern of the at-rule matches a navigation based on the navigation and to parameters. So the flow I was thinking of was:

• The browser looks at @gesture-action rules to check if an action is associated with a gesture. -ua-gesture-back implicitly has a back navigation action associated with it.
• The browser then looks at @view-transition rules to check if this action has a view transition associated with it. premptive-trigger is then another filter to say if a navigation is started from this gesture then use a view transition for it.

[khushalsagar]

It's also worth considering whether CSS is the right place to declare actions for a gesture. Feels like it should be an html concern?

[bokand]

Ok that makes sense, thanks. I guess in this case the @gesture-action invokes the navigation at the end of the gesture...but preemptive-trigger in @view-transition says "start the transition when the gesture becomes active, before the navigation is invoked.

It's also worth considering whether CSS is the right place to declare actions for a gesture

Good point! There's advantages to something like:

<a href="next.html" gestureTrigger="--next-gesture-timeline">Next Page</a>

In this case you get accessibility since this is in the DOM, even if the author chooses to make it not visible and you can also add other things like rel parameters. And by default, it would make authors consider whether it makes sense to also have a "clickable" alternative which is probably good practice.