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.

Not exactly sure what you mean.

> * 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

I think we should advance declarative same-document transitions once the navigation API gets into shape. Yes, it has a few issues but I think it would be amazing if "some day" we could have same-document experiences that don't require loads of JS.

> 
> > 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`.

Yup, right now it is. I hope that on top of some of the primitives of the navigation API we could make some of this stuff declarative in the future, where transitions between routes/hashes are declarative. But I wouldn't rush to it.

> 
> > 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
> 2. index-to-article
> 3. index-to-gallery
> 4. index-to-search-results
> 5. article-to-index
> 6. article-to-article
> 7. article-to-gallery
> 8. article-to-search-results
> 9. gallery-to-index
> 10. gallery-to-article
> 11. gallery-to-gallery
> 12. gallery-to-search-results
> 13. search-results-to-index
> 14. search-results-to-article
> 15. search-results-to-gallery
> 16. search-results-to-search-results
> 
> Unless I'm missing something, you'd end up declaring the same URL patterns 8 times each.

Probably 8:
```css
@media (navigation: from-search-results) and (navigation: to-gallery) {
}
```

The alternative is perhaps nicer:
```css
@media (navigation: from search-results to gallery) {
}
```
I was proposing the former because it is perhaps more extendable in terms of defining things about the navigation itself rather than the page type (e.g. opt-in for back-forward, or special-casing cross-document). We should examine if those customizations are common enough to be part of the definition, or if putting them directly in the media-query is sufficient.



-- 
GitHub Notification of comment by noamr
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8925#issuecomment-1587786151 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 17:42:51 UTC