- 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