Re: [csswg-drafts] [css-view-transitions-2] Syntax for navigation-matching (#8925)

@khushalsagar 

> * Not allowing media queries on the old Document to depend on any state parsed from the new Document.

Yeah, I understand the technical limitations around this.

> * It's better if we can enable these queries for same-document navigations, irrespective of whether there is a transition. We'll need to think through the lifetime of the queries with respect to the navigation lifecycle but I don't see the advantage of limiting it to navigations which have a ViewTransition (unless constrained by implementation).

There are pros and cons to that. The pros are it becomes a general navigation feature, which feels nice in terms of platform structure (although view transitions would still have an impact on the lifetime of these rules), but some cons:

- Could there be cases where a cross-document transition should be reused in an SPA, but in the SPA it doesn't really make sense as a navigation? In this case we'd be forcing the developer to create a dummy navigation just to activate these rules.
- Being able to control when the URL changes in an SPA navigation is currently an [experimental feature in the navigation API](https://github.com/WICG/navigation-api/issues/66#issuecomment-1527047126). It isn't possible with the history API as the process is synchronous. Since this is limited to the navigation API, uptake in routing libraries might be slow.
- Could this result in developers changing the URL at a sub-optimal point because it's what the view transition needs?

@noamr 

> with an option to enable automatic navigation detection later when we allow declarative SPA transitions (something I'm really keen to do in the future)

Given the issues around the URL change, I don't think declarative SPA transitions offer a lot of value. The developer would need to use the opt-in, switch their routing to the navigation API, enable manual entry committing, and ensure they commit the entry at the correct point. This seems like orders of magnitude more work than just using `document.startViewTransition`.

> Perhaps for SPA transitions we don't even need to pass the URLs, but rather just the navigation names, e.g.
> 
> ```js
> startViewTransition({update: () => {...}, navigations: ["foo-to-bar"]})
> ```

I don't think these navigation definitions should include both the old and new URL patterns. I see the benefit of defining a bunch of paths as a particular page type, but forcing the rule to include both patterns just reintroduces the repetition in a different place.

For example, if you have 4 page types, "index", "article", "gallery", "search-results", and some customisation of transitions between them, you now have 16 definitions:

1. index-to-index
1. index-to-article
1. index-to-gallery
1. index-to-search-results
1. article-to-index
1. article-to-article
1. article-to-gallery
1. article-to-search-results
1. gallery-to-index
1. gallery-to-article
1. gallery-to-gallery
1. gallery-to-search-results
1. search-results-to-index
1. search-results-to-article
1. search-results-to-gallery
1. search-results-to-search-results

Unless I'm missing something, you'd end up declaring the same URL patterns 5 times each.

Instead, it seems better if there's a way to define a page type from a bunch of URL patterns, then they're only defined once each.

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


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

Received on Monday, 12 June 2023 09:09:49 UTC