Closed jakearchibald closed 10 months ago
I find this syntax is very confusing. It looks like state is added, yet the descriptors inside it apply when the state is no longer active?
In terms of the duration for when the "reload" state is activated in CSS, that'll be the same irrespective of whether its a media-query or pseudo-class. Can you elaborate why you find the use of pseudo-class more confusing?
It seems a little strange for reloads, specifically, to be handled differently than other trigger qualities; it seems to be just as much a quality of the trigger as "same-origin" vs "cross-origin", I think? I suggest baking this into the trigger syntax itself, and using comma separation, like:
@view-transition {
transition-trigger: none | [ [ reload | no-reload ] || <transition-type> ]#;
}
@view-transition { transition-trigger: none | [ [ reload | no-reload ] ||
]#; }
Is this different from just having a "reload" keyword, since the default and "no-reload" would prumably have the same behavior
The CSS Working Group just discussed Declarative Cross-document View Transitions
.
It seems a little strange for reloads, specifically, to be handled differently than other trigger qualities; it seems to be just as much a quality of the trigger as "same-origin" vs "cross-origin", I think? I suggest baking this into the trigger syntax itself, and using comma separation, like:
@view-transition { transition-trigger: none | [ [ reload | no-reload ] || <transition-type> ]#; }
It's a different quality from same-document/cross-document, as reload could be either. Also, a reload is something that might call for a different customization (class/group), e.g.:
@view-transition :reload {
navigation-trigger: cross-document-same-origin;
/* this would be available in MQs to customize the transition */
transition-group-name: reloading;
}
Re: media query and importantly having the ability to add general css in those blocks (to add/remove view-transition-name
on elements), does it make sense to have a @navigation
(instead of @media
) for this to gate based on navigation type
Eg,
.foo {
view-transition-name: foo
}
@navigation reload {
.foo {
view-transition-name: none
}
}
Or something along those lines? Or is the objection to the media-query style proposal extend to any at-rule style syntax?
Also, presumably @view-transition
opt-in block can also be wrapped in the @navigation
block
Re: media query and importantly having the ability to add general css in those blocks (to add/remove
view-transition-name
on elements), does it make sense to have a@navigation
(instead of@media
) for this to gate based on navigation typeEg,
.foo { view-transition-name: foo } @navigation reload { .foo { view-transition-name: none } }
Or something along those lines? Or is the objection to the media-query style proposal extend to any at-rule style syntax?
Also, presumably
@view-transition
opt-in block can also be wrapped in the@navigation
block
Think of two things:
@view-transition :reload {
navigation-trigger: cross-document;
view-transition-group: refreshing;
}
@media (view-transition-group: refreshing) and (prefers-reduce-motion: no-preference) { }
```js
function refreshView() {
startViewTransition({ groupName: "refreshing", update: async () => { ... });
}
Also having it as an MQ gives us the MQ javascript API for free. I don't see what a new @ rule adds when it acts exactly like a media query.
As I understand it, the point of the @view-transition
rule as it was initially proposed is to configure under which conditions view transitions should be triggered.
It does not cover different view transitions based on those conditions. If there should be different transitions for different conditions, we need a separate feature to detect that.
New media features lend themselves to target this use case. Though if we go that route, I'd suggest to keep them general and only bind them to navigation, not view transitions specifically.
So we'd introduce media features like navigation-type: [ reload | push | replace | traverse ]
, navigation-origin: [ same-origin | cross-origin ]
(plus maybe URL patterns) and navigation-mechanism: [ interaction | api ]
.
So a media query could then look like this:
@media (navigation-type: reload) or (navigation-origin: cross-origin) {
…
}
Sebastian
It seems a little strange for reloads, specifically, to be handled differently than other trigger qualities; it seems to be just as much a quality of the trigger as "same-origin" vs "cross-origin", I think? I suggest baking this into the trigger syntax itself, and using comma separation, like:
@view-transition { transition-trigger: none | [ [ reload | no-reload ] || <transition-type> ]#; }
On second thought, thinking of what @fantasai brought up about specificity, I think perhaps we should go with reload (but not back-forward) in the opt-in. It means we can't customize the transition based on whether this is a reload, but at least it makes the whole specificity thing a lot simpler and perhaps customizing based on reload/not-reload is not an important use-case to begin with.
As I understand it, the point of the @view-transition rule as it was initially proposed is to configure under which conditions view transitions should be triggered. It does not cover different view transitions based on those conditions. If there should be different transitions for different conditions, we need a separate feature to detect that.
Thanks for the feedback @SebastianZ. +1, the point of @view-transition
rule is indeed to configure which conditions view transitions should be triggered for. We inevitably end up talking about view transition customization (what the animation looks like) here to ensure it works well with the rule. reload
is especially tricky because we want transitions to be disabled-by-default for them and also allow authors to customize the transition for this case.
New media features lend themselves to target this use case. Though if we go that route, I'd suggest to keep them general and only bind them to navigation, not view transitions specifically.
Huge +1 to this. Navigation related media feature shouldn't be limited to view transitions. They are a general concept which VT need as a building block since we need to enable authors to use different CSS based on the ongoing navigation.
So we'd introduce media features like navigation-type: [ reload | push | replace | traverse ], navigation-origin: [ same-origin | cross-origin ] (plus maybe URL patterns) and navigation-mechanism: [ interaction | api ].
Our thinking was to limit media features to cases which need to customize the transition, and for now we've only seen use-cases for navigation-type
. Were you proposing that every aspect of the navigation (same-document vs cross-document, same-origin vs cross-origin) should be a media feature? As opposed to part of the opt-in at-rule.
@noamr, regarding the syntax below:
@view-transition :reload {
navigation-trigger: cross-document;
view-transition-group: refreshing;
}
@media (view-transition-group: refreshing) and (prefers-reduce-motion: no-preference) {
}
I'm not seeing the advantage of having an indirection, where :reload
is available on @view-transition
to set a view-transition-group
and then the group is available as a media-query. Why not use reload
directly in the media-query like in @SebastianZ's example. I tend to agree that if we're introducing a CSS syntax for navigation state, there is no reason to tie it to View Transitions.
@noamr, regarding the syntax below:
@view-transition :reload { navigation-trigger: cross-document; view-transition-group: refreshing; } @media (view-transition-group: refreshing) and (prefers-reduce-motion: no-preference) { }
I'm not seeing the advantage of having an indirection, where
:reload
is available on@view-transition
to set aview-transition-group
and then the group is available as a media-query. Why not usereload
directly in the media-query like in @SebastianZ's example. I tend to agree that if we're introducing a CSS syntax for navigation state, there is no reason to tie it to View Transitions.
The indirection is there to support non-navigation SPA (startViewTransition({groupName: "refreshing"}). Otherwise you'd have to bring all this jazz into startViewTransition or make it very coupled with the navigation API
As I understand it, the point of the @view-transition rule as it was initially proposed is to configure under which conditions view transitions should be triggered.
It does not cover different view transitions based on those conditions. If there should be different transitions for different conditions, we need a separate feature to detect that.
Thanks for the feedback @SebastianZ. +1, the point of
@view-transition
rule is indeed to configure which conditions view transitions should be triggered for. We inevitably end up talking about view transition customization (what the animation looks like) here to ensure it works well with the rule.reload
is especially tricky because we want transitions to be disabled-by-default for them and also allow authors to customize the transition for this case.New media features lend themselves to target this use case. Though if we go that route, I'd suggest to keep them general and only bind them to navigation, not view transitions specifically.
Huge +1 to this. Navigation related media feature shouldn't be limited to view transitions. They are a general concept which VT need as a building block since we need to enable authors to use different CSS based on the ongoing navigation.
How would you use navigation media queries outside of VT? And considering that grouping would also be done with VT, this would create a strange situation where you have to compute media queries twice.
I am afraid we might have to resolve transition groups and see the whole picture before we come to a conclusion here.
So we'd introduce media features like navigation-type: [ reload | push | replace | traverse ], navigation-origin: [ same-origin | cross-origin ] (plus maybe URL patterns) and navigation-mechanism: [ interaction | api ].
Our thinking was to limit media features to cases which need to customize the transition, and for now we've only seen use-cases for
navigation-type
. Were you proposing that every aspect of the navigation (same-document vs cross-document, same-origin vs cross-origin) should be a media feature? As opposed to part of the opt-in at-rule.
New media features lend themselves to target this use case. Though if we go that route, I'd suggest to keep them general and only bind them to navigation, not view transitions specifically.
Huge +1 to this. Navigation related media feature shouldn't be limited to view transitions. They are a general concept which VT need as a building block since we need to enable authors to use different CSS based on the ongoing navigation.
How would you use navigation media queries outside of VT? And considering that grouping would also be done with VT, this would create a strange situation where you have to compute media queries twice.
My reason was that media features refer to some specific feature of the user agent, the display device or a user preference. They generally don't refer to a some specific thing defined in CSS.
The indirection is there to support non-navigation SPA (startViewTransition({groupName: "refreshing"}). Otherwise you'd have to bring all this jazz into startViewTransition or make it very coupled with the navigation API
The question is, what are the use cases for SPAs that aren't covered by the existing features?
E.g. reduced motion preferences can be handled like this using the API:
if (!matchMedia('(prefers-reduced-motion)').matches) {
document.startViewTransition(…);
}
Sebastian
I think the idea is that if you have
@media (view-transition-group: refreshing) and (prefers-reduce-motion: no-preference) {
}
then either startViewTransition(type: "refreshing")
or @view-transition :reload { view-transition-group: refreshing }
can trigger that media query.
I'm not convinced that this is a strong reason to avoid having a specific @media (navigation-type: reload)
though, because you can likely combine that with view-transition-group
that would only come from script.
I do see the advantage of @media (navigation-type: foo)
as compared to @navigation foo
since you can compose the former with other media queries
I do see the advantage of
@media (navigation-type: foo)
as compared to@navigation foo
since you can compose the former with other media queries
One reason to prefer @navigation
over @media
could be to limit what is allowed inside of the block. When using @media
, an author can put just about anything in there, and thus conditionally style the page based on the navigation.
If this is not feasible because of whatever reason, then using @navigation
could be a better way, as that could be designed to only accept certain types of nested rules.
A third option is to add these navigation conditions onto a dedicated @view-transition
rule, narrowing the reach of it even more.
One reason to prefer @navigation over @media could be to limit what is allowed inside of the block.
We can limit what's allowed inside the block either way. If you use the navigation: foo
query then that @media
block can activate whatever restrictions are necessary.
The question is, what are the use cases for SPAs that aren't covered by the existing features?
The SPA feature request is at https://github.com/w3c/csswg-drafts/issues/8960. Maybe @ydaniv can provide us the concrete details. I'd say this feature request can apply to cross-document (MPA) cases as well.
At a high level, the transition is from/to a UI state which has a semantic meaning and that's not always visible to the user agent. For example, you can say that if the page's URL is foo.html/home
then its the home page. Providing some way to apply CSS based on the old/new Document's URL is enough to customize a transition from/to the home page. But the home page could have a different UI depending on whether the user is signed in. So we want some API for the author to provide a custom ident identifying a transition and then be able to use it in CSS to customize animations for that transition.
The indirection is there to support non-navigation SPA (startViewTransition({groupName: "refreshing"}). Otherwise you'd have to bring all this jazz into startViewTransition or make it very coupled with the navigation API
That's fine for cases that the user agent can't know about but it seems silly to force the authors to use the pattern below for known cases, instead of being able to use the foo qualifier directly in the media-query (or something else):
@view-transition :foo {
navigation-trigger: cross-document;
view-transition-group: foo;
}
@media (view-transition-group: foo) { ... }
I think the fundamental questions based on the discussion above (and in the meeting) we need to answer before diving into the exact syntax are:
Authors need the capability to conditionally apply any CSS based on the type of navigation to support basic customization. Something like:
@media (navigation: back) {
#back-button { view-transition-name: back-button; }
}
This is being done in SPAs using script since the information is available via the navigate
event. If we don't provide a CSS way, authors will have to use script. Also, while the navigate
event makes it trivial to get this info on the old Document, there is no such event on the new Document. So authors will have to do hacks to pass along this information to the new Document somehow (link decoration, sessionStorage API, etc.).
The options considered are media-queries, pseudo-class, a new @navigation
at-rule. The problem for defining the lifetime of a particular navigation state in the style system is the same regardless of the syntax chosen.
If we want reload to be default off, then there is no way to do that without including it within the opt-in at-rule based on the options being considered in 1. Since reloads are also a potential customization case, and should be one of the nav types in 1 above, ideal way would've been for UA CSS to make it off unless the author explicitly enables it for reloads.
So let's resolve on how we want to handle 1? Whether we want CSS to solve this and how; or recommend that authors use existing script hooks on the old Document and probably introduce a script hook on the new Document which provides that info. @domenic @fantasai for an opinion.
The SPA feature request is at https://github.com/w3c/csswg-drafts/issues/8960. Maybe @ydaniv can provide us the concrete details. I'd say this feature request can apply to cross-document (MPA) cases as well.
The request is to be able to style the VT's pseudo tree based on the state (type) of the transition. There are also concrete examples for setting view-transition-name
's as well.
Using the pseudo-classes from https://github.com/w3c/csswg-drafts/issues/8960#issuecomment-1671986616 should cover the requests above. It's clear how to set them from script, so the only question is how to set them via style, which I think can be done via navigation/media rules.
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:
onNavigation(() => {
if (someConditionsAreMet) {
document.startViewTransition(someParameters);
}
});
When specifying the syntax of this we need to think about it extending in the following ways:
For parameters, this should be 1:1 mapped to what parameters startViewTransition can pass to a transition with #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, 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:
Suggesting something like the following:
@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:
In the future, this can include URLs and navigation-types, however we’re not proposing this yet. A possible syntax can look like this:
@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;
}
In essence a navigation is always qualified by URLs, navigation type, and phase (outgoing vs incoming).
Alternatives considered to URL pattern matching:
a
elements): this is limited, as there are many ways to navigate (javascript, anchors, back/forward, browser buttons...) and all of them would have to be made aware of this extra metadata that's "out of band" from the URL.Points for discussion:
Currently out of scope:
The CSS Working Group just discussed [css-view-transitions-2] Declarative opt-in for cross-document navigations
, and agreed to the following:
RESOLVED: Accept the final syntax proposal.
I'm not sure that
@view-transition same-origin { trigger: <any-value-other-than-navigation> }
makes any sense. Should it maybe be
@view-transition navigation {
origin: same-origin;
}
or something else?
I'm not sure that
@view-transition same-origin { trigger: <any-value-other-than-navigation> }
makes any sense. Should it maybe be
@view-transition navigation { origin: same-origin; }
This doesn't work because it doesn't let you customize classes etc based on URL. The URLs/types need to be in the matcher rather than in the descriptor.
or something else?
Other suggestions?
Perhaps
@view-transition navigation(same-origin) {
behavior: trigger;
}
Later it can be extended like
@view-transition navigation back from same-origin to urlpattern("...") {
behavior: trigger;
}
Some more bikeshedding options:
@nav-transition same-origin { behavior: trigger };
@view-transition same-origin-navigation { behavior: trigger }
@navigation-behavior same-origin { view-transition: trigger; }
I'm not sure that
@view-transition same-origin { trigger: <any-value-other-than-navigation> }
makes any sense.
Wouldn't this just be an explicit opt-out (which is the default).
If an opt-out that's the default seems redundant, could we just omit trigger entirely? (i.e. the existence of the at-rule implies opt-in). Examples:
@view-transition same-origin-navigation;
@view-transition same-origin-navigation and history-back {
typeNames: slide-in reverse;
}
@view-transition same-origin-navigation; @view-transition same-origin-navigation and history-back { typeNames: slide-in reverse; }
It came out in the TAG review that a standalone rule like @view-transition same-origin-navigation;
feels a bit inconsistent with the rest of CSS. It's arguable but I can see that point.
@noamr how does this syntax deal with https://github.com/w3c/csswg-drafts/issues/8784? We want transitions to not occur for reloads by default but let authors configure it. Since this can be done in script using the navigate
event, seems ok if we punt on a declarative hook for it. But I wasn't sure what the plan for that is with this syntax.
@noamr how does this syntax deal with #8784? We want transitions to not occur for reloads by default but let authors configure it. Since this can be done in script using the
navigate
event, seems ok if we punt on a declarative hook for it. But I wasn't sure what the plan for that is with this syntax.
In short, @view-transition reload { trigger: navigation}
(replace with whatever name we end up with for the rule etc).
The nice thing about reload is that it replaces both the URLs AND the navigation type, so we don't have to bother with composing reloads with other qualifier. A VT-navigation rule is either reload
without anything else, or whatever else (same-origin, particular URLs with from/to, back, etc) - mutually exclusive.
I'm trying to understand what our base qualifiers are. IIUC, the idea is that going forward these base qualifiers can be combined with each other (using and/or operators). I was expecting those to be:
same-origin
is simply a shorthand for to: urlpattern(/*)
(any same-origin URL).
But sounds like you're suggesting reload
being another base qualifier which can't be combined with any other qualifier. Is that reasonable? For example, what happens if there is a reload which results in a same-site navigation after redirects. Don't we want authors to be able to express that with something like @view-transition same-site reload { trigger: navigation; }
.
You're right that redirects might make it so that a reload doesn't necessarily mean the same URL/origin, so perhaps it needs to be @view-transition same-origin reload
.
About the qualifiers, I'd prefer to look at them more from a user intent standpoint rather than from technical history/navigation terms like push/replace.
"reload" and "back" are clear user experience intents, also "forward", "jump to some place in history", or "jump to a random URL in this origin" (address bar, bookmark, extension etc), and of course a normal navigation like links/forms.
The way I see it, the opt-in rule applies to some of these intents. By default, probably to navigate+forward+back, and arguably jump. It applies to reload only if explicit. So
@view-transition same-origin
actually means something like @view-transition (navigate or back or forward) from urlpattern("/*") to urlpattern("/*")
and @view-transition same-origin reload
means @view-transition (reload) from urlpattern("/*") to urlpattern("/*")
. We can perhaps keep the same-origin implicit when reload is present, but I'm not sure we have to decide on this now. Perhaps this discussion can continue in #8784? Not sure it affects the default opt-in that much.
Sorry I'm still not following how we're dealing with the combination of nav type + from/to url. Every combination of these 2 is possible. So if an author has CSS like:
@view-transition same-site {
trigger: navigation;
}
@view-transition reload {
trigger: navigation;
}
What happens if there is a reload which results in a same-site navigation? Your comment above sounds like all the qualifiers are a combination of nav type and from/to url. "same-origin" means any same-origin url of type "navigate", "back" and "forward". Presumably "same-site" would cover the same nav types. And "reload" means only same-origin reload navigations?
We can perhaps keep the same-origin implicit when reload is present, but I'm not sure we have to decide on this now.
Asking this right now because IMO "same-origin" should only be about the from/to url. Overloading the nav type into it is not a good idea. So I'd expect @view-transition same-origin { trigger: navigation; }
to include reloads.
My interpretation of what @noamr is saying is that we can treat (navigation, back, forward)
as the implicit default navigation type.
I agree with @khushalsagar that my understand of same-origin is to be specifically about from
/to
, and not the type of getting from from
to to
.
The syntax that I like is something like
@view-transition <<route>> <<navtype>> { ... }
Where
<<route>> = '' | (from: <urlpattern> || to: <urlpattern>) | same-origin | same-site
<<navtype>> = '' | (navigation || back || forward || reload) | including-reload
with an explicit note that explains that if route
is ''
, ie empty, then it is the same as same-origin; if navtype
is empty, then it is the same as navigation back forward
, but not reload
. I've also added including-reload
to mean the default ones, and reload, meaning everything.
So with this syntax, I think we can express everything?
Specifically, @view-transition same-origin
means it doesn't include reloads, and it's about going from /*
to /*
.
To answer @khushalsagar's question, in this syntax @view-transition reload
means "same origin reload only". If you want to capture all same-site navigations including reloads, then that's @view-transition same-site including-reload
.
Sorry I'm still not following how we're dealing with the combination of nav type + from/to url. Every combination of these 2 is possible. So if an author has CSS like:
@view-transition same-site { trigger: navigation; } @view-transition reload { trigger: navigation; }
What happens if there is a reload which results in a same-site navigation? Your comment above sounds like all the qualifiers are a combination of nav type and from/to url. "same-origin" means any same-origin url of type "navigate", "back" and "forward". Presumably "same-site" would cover the same nav types. And "reload" means only same-origin reload navigations?
I think so. Mainly because a reload with cross-origin redirects is something that feels unexpected and uncommon. Edge case?
We can perhaps keep the same-origin implicit when reload is present, but I'm not sure we have to decide on this now.
Yes exactly
Asking this right now because IMO "same-origin" should only be about the from/to url. Overloading the nav type into it is not a good idea. So I'd expect
@view-transition same-origin { trigger: navigation; }
to include reloads.
I see the value in having a clean separation between URLs and types, and having same-origin
mean only the URLs.
But I think there is greater value in reasonable defaults. Putting UX first, view transitions on reload is something unexpected and needs to be handled a bit like an edge case, and in most cases not have a transition there at all unless explicitly requested. This was the tone of this CSSWG resolution.
The same argument for reasonable defaults (which I think is consistent with a lot of CSS) goes for having reloads be same-origin only by default.
As for being conceptually clean, I'd say that in this case same-origin
does mean just the from/to URLs, and since there is no type defined, we go with the specified "default set of navigation types" - which are navigate/back/forward/(maybe also jump? not sure).
The same argument for reasonable defaults (which I think is consistent with a lot of CSS) goes for having reloads be same-origin only by default.
My concern wasn't with the default, but whether the non-default case is possible : reload with a same-site navigation. In general, I'd say our syntax should ensure that any combination of mutually exclusive navigation params (same vs cross doc, from/to url and nav type) can be expressed. We should have a good reason to disallow a combination and it being an edge case is not a good one.
The syntax @vmpstr proposed above sounds good in that regard. One thing I'd say is to include <<doc-change>>
to the qualifier as well.
@view-transition <<route>> <<navtype>> <<doc-change>> { ... }
where
<<doc-change>> = "same-document | cross-document"
A few more clarifications around it:
@noamr does that sound reasonable to you?
If the above sounds good then a couple of questions come to mind:
from: urlpattern(a),urlpattern(b)
. But the relationship between qualifiers is and. So if you want the rule to say "back or navigation to urlpattern(a)", that needs 2 at-rule declarations. That sounds fine to me, just wanted to confirm.The same argument for reasonable defaults (which I think is consistent with a lot of CSS) goes for having reloads be same-origin only by default.
My concern wasn't with the default, but whether the non-default case is possible : reload with a same-site navigation. In general, I'd say our syntax should ensure that any combination of mutually exclusive navigation params (same vs cross doc, from/to url and nav type) can be expressed. We should have a good reason to disallow a combination and it being an edge case is not a good one.
The syntax @vmpstr proposed above sounds good in that regard. One thing I'd say is to include
<<doc-change>>
to the qualifier as well.@view-transition <<route>> <<navtype>> <<doc-change>> { ... }
where
<<doc-change>> = "same-document | cross-document"
I wouldn't do the same-doc thing in CSS at all, rather have this in JS - something like navigation.enableSameDocumentAutoViewTransitions = true
which would make this whole thing somehow work magically with the navigation API
A few more clarifications around it:
- Each at-rule declaration must provide a route, nav type and doc-change. If not supplied, there will be a default.
- The relationship between each qualifier is "and", i.e., the at-rule reads as "navigation to url(a) and back".
- The default for route is same-origin, nav type is all navigations excluding reload and doc-change is cross-document.
@noamr does that sound reasonable to you?
If the above sounds good then a couple of questions come to mind:
- I'm assuming we'll allow an "or" type syntax for each qualifier for use-cases like
from: urlpattern(a),urlpattern(b)
. But the relationship between qualifiers is and. So if you want the rule to say "back or navigation to urlpattern(a)", that needs 2 at-rule declarations. That sounds fine to me, just wanted to confirm.
Not sure yet, I don't think we're there but sounds OK for now.
- Why do we need to require the "same-origin" qualifier? Sounds like similar to nav type, the default value of same-origin avoids the need for it.
It's not strictly necessary. I think it was your suggestion to make it explicit when reading that this only applies to same origin navigation. I'm ok with also making it an implicit default. It wouldn't be the first thing in the web platform that's implicitly same-origin by default.
I wouldn't do the same-doc thing in CSS at all, rather have this in JS - something like navigation.enableSameDocumentAutoViewTransitions = true which would make this whole thing somehow work magically with the navigation API
Ok. I'm fine with punting on this.
Not sure yet, I don't think we're there but sounds OK for now.
Aren't we resolving on a syntax which requires an "and" relationship between the qualifiers? I figured that's why we should make sure this is fine right now.
It's not strictly necessary. I think it was your suggestion to make it explicit when reading that this only applies to same origin navigation. I'm ok with also making it an implicit default.
I suggested this because it wasn't clear to me how the syntax will be extended to support same-site. Now that its more clearly laid out, it makes sense to be able to omit it.
I wouldn't do the same-doc thing in CSS at all, rather have this in JS - something like navigation.enableSameDocumentAutoViewTransitions = true which would make this whole thing somehow work magically with the navigation API
Ok. I'm fine with punting on this.
Not sure yet, I don't think we're there but sounds OK for now.
Aren't we resolving on a syntax which requires an "and" relationship between the qualifiers? I figured that's why we should make sure this is fine right now.
We're not suggesting the qualifiers yet. But I imagine having and/or/() like media queries.
It's not strictly necessary. I think it was your suggestion to make it explicit when reading that this only applies to same origin navigation. I'm ok with also making it an implicit default.
I suggested this because it wasn't clear to me how the syntax will be extended to support same-site. Now that its more clearly laid out, it makes sense to be able to omit it.
Great. Let's suggest this when we discuss the name.
We're not suggesting the qualifiers yet. But I imagine having and/or/() like media queries.
It's likely fine, I'm just convincing myself that we'll be able to add both and/or operators with the qualifiers later. For example, having no qualifiers implicitly expands to both default values + "and" operator between them. But the author will be able to override the defaults by providing an explicit value for each qualifier + whether its "and"/"or".
@view-transition { ... }
/* The above expands to the following */
@view-transition <<route>> and <<navtype>> and /* any other potential qualifiers */ { ... }
@view-transition <<route>> or <<navtype>> { ... }
/* The above will expand to the following */
@view-transition <<route>> or <<navtype>> and /* any other potential qualifiers */ { ... }
Great. Let's suggest this when we discuss the name.
SGTM!
We're not suggesting the qualifiers yet. But I imagine having and/or/() like media queries.
It's likely fine, I'm just convincing myself that we'll be able to add both and/or operators with the qualifiers later. For example, having no qualifiers implicitly expands to both default values + "and" operator between them. But the author will be able to override the defaults by providing an explicit value for each qualifier + whether its "and"/"or".
@view-transition { ... } /* The above expands to the following */ @view-transition <<route>> and <<navtype>> and /* any other potential qualifiers */ { ... }
What are the other potential qualifiers?
@view-transition <<route>> or <<navtype>> { ... }
I think this would expand to (<<route>> and <<default-nav-types>>) or (<<navtype>> and same-origin)
What are the other potential qualifiers?
Same vs cross-doc was the only other one I had, but I can see that being specified in JS instead of CSS. Can't think of anything else but it's good to ensure its possible to add more going forward.
I think this would expand to
(<<route>> and <<default-nav-types>>) or (<<navtype>> and same-origin)
Hmmm, that took me by surprise. Reading the author declaration, that's not what I would've expected. FWIW, @vmpstr pointed out that this use-case can be achieved with 2 blocks like:
@view-tranition <<route>> and all-nav-types { ... }
@view-tranition all-routes and <<navtype>> { ... }
So whichever expansion we take, we won't be limiting authors. We can decide based on what authors would intuitively expect.
One minor comment on
<<navtype>> = '' | (navigation || back || forward || reload) | including-reload
It could be useful to provide an identifier for a multi-entry jump e.g. back(1)
, navigation(-3)
, back(*)
or something like that. Many well-formed transitions+animations rely on a guarantee on which page(s) can be directly connected.
Jumping between two arbitrary pages that are many navigations apart might generate unexpected motion with VT API annotations, and it would be great to have a way to explicitly disable this or specify a simpler animation like a full-page cross-fade.
This could apply to the opt-in here, and would also be useful for the actual CSS styling specified. Using cascading rules to override will give power to customize e.g.
@view-transition same-site (back(*), forward(*) { trigger: navigation }
::view-transition-old(root) back(*),
::view-transition-new(root) back(*) {
animation: simple-back-animation;
}
::view-transition-old(root) back(1),
::view-transition-new(root) back(1) {
animation: advanced-back-animation;
}
(not bikeshedding here with the syntax, just the functionality)
One minor comment on
<<navtype>> = '' | (navigation || back || forward || reload) | including-reload
It could be useful to provide an identifier for a multi-entry jump e.g.
back(1)
,navigation(-3)
,back(*)
or something like that. Many well-formed transitions+animations rely on a guarantee on which page(s) can be directly connected.Jumping between two arbitrary pages that are many navigations apart might generate unexpected motion with VT API annotations, and it would be great to have a way to explicitly disable this or specify a simpler animation like a full-page cross-fade.
This could apply to the opt-in here, and would also be useful for the actual CSS styling specified. Using cascading rules to override will give power to customize e.g.
@view-transition same-site (back(*), forward(*) { trigger: navigation } ::view-transition-old(root) back(*), ::view-transition-new(root) back(*) { animation: simple-back-animation; } ::view-transition-old(root) back(1), ::view-transition-new(root) back(1) { animation: advanced-back-animation; }
(not bikeshedding here with the syntax, just the functionality)
Suggesting that back
is exactly back(1)
, and jump
is everything else (traversing more than +-1 back/forward, or navigating via URL bar etc)
jump is everything else (traversing more than +-1 back/forward, or navigating via URL bar etc)
The idea sounds nice but its unfortunate that navigation type in CSS will diverge from navigation type in JS defined by the navigation API. This might be inevitable if we can't change the JS navigation type in a backwards compatible way but worth trying to keep these consistent to the extent possible. @domenic @natechapin FYI.
Could we organize the CSS navigation types as sub-types of the JS versions?
Cross-document transitions need some way for both the old & new page to opt-in to a transition.
The SPA API uses JS for this, but it would be nice if cross-document transitions didn't depend on JS.
It feels like this should be in CSS, so it can be influenced by media queries, particularly
prefers-reduced-motion
.The tricky part here is it's a "global" setting, so it can't be a CSS property.
Proposal:
However, I'm just making stuff up here. Is there any prior art here for setting 'global' things?