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

I was asked to comment here but don't quite understand the design goals. Some general principles and observations that might help:

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

- In terms of what authors expect, I think there's really only two meaningful tiers: link clicks/author-initiated JS navigations, and literally-everything. Saying that authors expect back button presses but don't expect manual same-origin URL hacking seems wrong to me. (In part, because once you've done the URL hacking to generate an arbitrary X -> Y push navigation, you can click the back button to generate an arbitrary Y -> X traverse navigation.)

- In the navigation API, we expose to authors the ability to be notified of [almost all navigations](https://github.com/wicg/navigation-api#appendix-types-of-navigations), except for browser-UI non-traverse. The reasoning there was not really about what authors expect, but instead about whether we could meaningfully allow cancelation or interception. For browser-UI non-traverse we do not offer cancelation or interception, because that wasn't possible before the navigation API existed and we didn't want to introduce a new capability.

  Even if the reasoning isn't the same, aligning on that same boundary might make things easier to understand for authors.

- In terms of what we see authors filtering out, we see lots of usage of these `NavigateEvent` properties: `hashChange`, `formData`, and `downloadRequest`. Authors mostly don't want to intercept those kinds of navigations. (Although intercepting `formData` is relatively popular.)

- It seems like you're trying to do two things: summarize the full power of the navigation API into a set of easy keywords for common use cases, and figure out the default auto behavior.

  For the former, I'd be cautious and minimal. Since you're not going to be able to give developers the full power of `e.destination.url.endsWith("/foo") && !e.hashChange && e.userInitiated && e.info === "bar"` in CSS, the default assumption should be that developers use JS to connect up their CSS appropriately. So it's only for truly-simple cases, where you have web developers explicitly saying "I really want to filter out the X transitions with no special cases", that you want to create new CSS keywords. `back`, `forward`, and `reload` are good guesses, but it'd be best if you could point to explicit developer demand, ideally in the form of building a realistic demo. In particular, to show that "I really want to filter out the back transitions" doesn't end up being "I really want to filter out the back transitions, except when going back to the homepage" or something like that.

  For the latter, whichever route you go, I really appreciate the efforts to phrase it in terms of the navigation API. Keep that up :)

-- 
GitHub Notification of comment by domenic
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8783#issuecomment-1815575692 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 01:08:00 UTC