- From: Noam Rosenthal via GitHub <sysbot+gh@w3.org>
- Date: Tue, 12 Sep 2023 16:19:02 +0000
- To: public-css-archive@w3.org
Summarizing current thinking/proposal for the breakout + discussion. The “opt-in” is in fact about defining a *behavior*: a navigation triggers a view transition. A declarative version of the following: ```js onNavigation(() => { if (someConditionsAreMet) { document.startViewTransition(someParameters); } }); ``` When specifying the syntax of this we need to think about it extending in the following ways: - Customize the parameters of the transition if it is indeed triggered - Customize the conditions under which this behavior is triggered: - Conditions based on the navigation - Conditions based on the environment For *parameters*, this should be 1:1 mapped to what parameters startViewTransition can pass to a transition with [#8960](https://github.com/w3c/csswg-drafts/issues/8960), this includes a set of idents (or some such) that classify which transition this is. If more parameters are added to startViewTransition, they should also be added to the behavior declaration. For *environment conditions*, this is well covered by media-queries. For *navigation conditions*, the initial condition is to scope this behavior to same-origin navigations only, with a syntax that can extend later to conditions based on URLs and on navigation types (e.g. back/forward). At first, developers can achieve the more complex navigation-based customization using JS. As [discussed in the last F2F](https://github.com/w3c/csswg-drafts/issues/8048#issuecomment-1640574446), the basis for this should be a new @ rule. To make it environment-aware, it should be possible to nest this rule inside media-queries. Potential names for this rule could be @navigation or @view-transitions, or perhaps @auto-view-transitions or @page-transitions. The rule should include two descriptors: - A behavior descriptor that says “if the conditions are met, start a view transition” - A parameters descriptor that matches parameters we add to startViewTransition. The naming for this should match what we choose in [#8960](https://github.com/w3c/csswg-drafts/issues/8960) - e.g. classNames. Suggesting something like the following: ```css @navigation same-origin { view-transition-behavior: activate; view-transition-classnames: slide-in reverse; } ``` Instead of @navigation, if this is too generic, we can call it something like @view-transitions or @page-transitions. A few points about this: - This rule would be read twice: when navigating away from the document and when ready to render the first frame after navigation. - Currently proposing to not allow @navigation without any qualifier. The developer has to specify which URL qualifies the navigation, with same-origin being the default (and at first, the only supported value). - By default, the navigation qualifier excludes reload. When we enable navigation types, it would be a way to opt-in to reloading. In the future, this can include URLs and navigation-types, however we’re not proposing this yet. A possible syntax can look like this: ```css @navigation back from urlpattern(/home/*) { view-transition-behavior: trigger; } /* or with url patterns defined separately */ @routes { --home: urlpattern(/home/); } @navigation back from --home { view-transition-behavior: trigger; } ``` Points for discussion: - Are we seeing this as a “general navigation configuration” rule, or something specific to view transitions? How can we derive naming from this? - Based on our resolution of [#8960](https://github.com/w3c/csswg-drafts/issues/8960), how would it look like to pass parameters/classnames to the transition declaratively? How do we handle composition in this case? (Add vs. replace) - How do envision declarative navigation conditions? Currently out of scope: - Using @navigation as a “state” rather than a “behavior”, i.e. something that can nest other rules. There are use cases for this, but they seem mutually exclusive from view transitions (e.g. loading indicators). - Fully defining the whole syntax with URLs and navigation types. -- GitHub Notification of comment by noamr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8048#issuecomment-1716035713 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 12 September 2023 16:19:05 UTC