- From: Noam Rosenthal via GitHub <sysbot+gh@w3.org>
- Date: Wed, 14 Jun 2023 05:59:56 +0000
- To: public-css-archive@w3.org
> > I still prefer `(navigation: from search-results)` > > Ok, but please talk to the CSSWG and CSS-knowledgeable folks about it. > For width, media queries use `(min-width: value)`, not `(width: min value)`, so make sure you have a good justification for breaking existing patterns. Naturally we'll discuss it at the WG. Given `10px <= width <= 100px`. I don't think we HAVE to limit ourselves to `(key: value)`. But anyway, I think the syntax conversation is more of a detail, and the bigger discussion is the relationship between a view-transition and a navigation. I feel that we should have a strategy around it, even if we don't implement everything in the first go. In #8677 we defined that one of the goals is that SPA & MPA don't diverge more than necessarry. In the MPA case, every transition is a navigation, so does that mean that (document-scoped) SPA transitions should also be navigation-oriented? In a way, because document-scoped view transitions block rendering for the entire page, they feel "navigation-y" even if they don't change the URL. The problem with treating every transition as a "navigation" is that soft navigations are not a well defined term and don't have a specified lifecycle but rather a concept that described multiple JS operations (see #8300), and the navigation API which attempts to define these terms is still experimental. I see several directions we could go with this: 1. leave this to userland JS, see what patterns emerge. Experiment with polyfills for this with e.g. the navigation API or something like [this](https://github.com/noamr/h0/blob/with-view-transitions/src/vtnav.ts). Note that almost everyone using view-transitions for navigations would have to use a polyfill similar to this, or count on the routing framework (Next etc) to include that functionality. 2. Give names to transitions/navigations, allow to declaratively link them with navigations in the MPA case, and specify them explicitly in the SPA case (some version of [this](https://github.com/w3c/csswg-drafts/issues/8925#issuecomment-1582517771). Think about making this declarative for SPA when we get to #8300. 3. Specify an initial version #8300 now. In a way, an app that supports both SPA and MPA *does* have a pattern: capturing link clicks and `popstate` in the SPA case and not capturing them in MPA. But this might be a bit leaky until we resolve some things around the navigation API. Doing (1) is the easiest but might lead to footguns/antipatterns, and potentially a lot of over-capturing. It's perhaps a risk we can take and mitigate it with a lot of documentation/education, and making sure frameworks do the right thing. OTOH, I think that (2) could be feasible with the right naming choices. Would love to have more opinions here... @tabatkins, @khushalsagar? -- GitHub Notification of comment by noamr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8925#issuecomment-1590521908 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 14 June 2023 05:59:58 UTC