[css-view-transitions-2] Decide on naming for navigation-triggered view-transition rule

[noamr]

For context, see TPAC discussion as well of the rest of the conversation at #8048.

The resolution was that we would have an at-rule that defines the relationship between a navigation and a view-transition - for start, it would allow you to specify that any same-origin navigation results in triggering a view transition.
The final naming was left open.

The at rule is supposed to be extended in the future to convey the following things:

1. A name of the feature. The feature is something like "trigger a view transition on a navigation"
2. Which navigations activate this rule?
   1. type of navigaiton: normal/back/forward/reload/jump.
   2. old/new URL (URL patterns, or keywords that represent them like "same-origin")
   3. potentially, same-document or cross-document navigation, though this would probably be defined in JS.
3. Given these conditions, should the transition be triggered?
4. What transition type names should be active?

To structure this all into an @ rule, it would look something like

@name-of-rule navigation-conditions { 
  should-be-triggered: yes | no;
  types: list of names;
}

The previous resolution led us to

@view-transition same-origin { trigger: navigation }

A few cons of the current resolution:

• It seemed strange that "same-origin" applies to a "view-transition".
• trigger: navigation might be confusing, as currently the trigger is only cross-document navigations. However, when we want to enable same-document navigation transitions in the future, we probably don't want to have to change all the CSS that applies to it.

Suggesting that:

• The name should be distinct enough to be "the name of the feature", which describes something like "navigation-triggered view transition"
• "same-origin" can be a default, and not a required keyword.
• "cross-document" is still implicit.

Current suggestions (but open for more!):

1. @view-transition { trigger: navigation } (what we settled on temporarily in the TPAC resolution).
2. @view-transition-behavior { trigger: navigation }
3. @navigation-behavior { view-transition: trigger }
4. @nav-transition { behavior: trigger }
5. @view-transition navigation(same-origin) { behavior: trigger }
6. @auto-view-transition { trigger: navigation }
7. @navigation-view-transition { behavior: trigger; }
8. @navigation-view-transition { trigger: * } (where * means the default type)

If types are specified, it would look e.g. like @navigation-view-transition { behavior: trigger; type: slide-in; }

I am currently leaning towards (7) as it conveys that it's a distinct feature.

@navigation-view-transition {
   behavior: trigger;
}

which can later be extended to (for example):

@navigation-view-transition from "/article/" to "home" {
  behavior: trigger;
  type: slide-in;
}

@navigation-view-transition back {
  type: slide-reverse;
}

/* or combined, and overriden, e.g. with conditionals */
@navigation-view-transition back {
  behavior: none;
}

@media (max-width: 600px) {
  @navigation-view-transition back to "/article/" {
    behavior: trigger;
  }
}

[bokand]

I'll add one to the list for consideration:

• @navigation-view-transition same-origin { behavior: trigger; }

This remains specific to view-transitions but makes it clear it applies only to navigation-initiated and makes more sense for same-origin to be a qualifier.

[noamr]

I'll add one to the list for consideration:

• @navigation-view-transition same-origin { behavior: trigger; }

This remains specific to view-transitions but makes it clear it applies only to navigation-initiated and makes more sense for same-origin to be a qualifier.

Yea, this is kind of like (4), I like it. will add to the list. thanks!

[noamr]

@fantasai @jakearchibald @tabatkins @vmpstr @khushalsagar if you'd like to weigh in or add more options, and we can try to resolve this in one of the next WG calls.

[vmpstr]

It's between 1. and 3. for me, with a slight preference to 3.

The way I see this problem is we're either declaring something about the view transition, or we're declaring something about the navigation. 7 and 8 also blur the lines a bit and declare something about both.

My preference is to talk about navigation here, and qualify it with something like same-origin or some other mechanism in the future. After we have sufficiently defined which navigation we're targeting, inside of it we say what we'd like to happen and here's where view-transition: trigger comes in.

[bokand]

One thing I've pointed out elsewhere but want to record here. If we make this about the navigation then other navigation features may require adding qualifiers that view-transitions doesn't support. E.g.

@navigation cross-origin {
  view-transition: trigger;
  some-other-feature-that-supports-cross-origin: enable;
}

In this case I'm not sure how we'd surface the fact that the VT trigger isn't effective in this case? In a view-transitions syntax we'd simply disallow non-supported qualifiers (like cross-origin) so they would fail at parse.

[noamr]

Beginning to agree that trying to support future unknown things with this key rule is YAGNI that might end up creating more confusion than value.
The feature here is navigation view-transitions, so maybe that's what the name of the rule should be. Also makes feature-detection with @supports(at-rule) more explicit (rather than having to invent elaborate things like @font-feature-detection).

[khushalsagar]

My favourite option so far is @navigation-view-transition same-origin { behavior: trigger; }. The at-rule is about navigation triggered view transitions which is clearer with this.

[noamr]

Proposing for the WG call:
@navigation-view-transition { behavior: trigger } (without same-origin), following recent discussion at #8048.

[noamr]

@fantasai @tabatkins since we didn't get to this in the CSSWG calls for several weeks, would you like to chime in here?

[dbaron]

One thought is that the naming likely depends in some ways on how you expect to extend this in the future. One concern about many of the proposals here is that it feels like they have a lot of future extension points (argument to at rule, adding new descriptors, adding new values to existing descriptors) and it's not clear to me how the possible uses of those extension points differ.

The extension types that I see mentioned in #8048 are:

• extending to specific URL patterns, possibly cross-origin, in addition to just same-origin
• distinguishing based on navigation types or back/forward
• in item 8 above there also seems to be another suggestion for a future extensibility point, but I don't understand what it is.

It might be helpful for group discussion to have a summary of the possible future extension areas and where you'd expect each one to fit in. (In particular, when I look at the above syntax options, I wonder whether there might be too many possible extension points, particularly when I see three places where there could later be multiple values but right now there's only one.)

(I'm also a little confused by the term navigation-triggered, and curious when a navigation-triggered view transition is different from a cross-document view transition. Is one a subset of the other?)

[noamr]

Thanks @dbaron, let me try to summarize.

The extension points we see to this are what you mentioned:

• qualifying based on URL patterns
• qualifying on navigation types (back/forward/reload etc)
• extending to declare transition types. Option 8 above is simply that, it says that * means "any transition type".

To answer your other question, this is currently being triggered by cross-document navigations only, but an extension point could be enabling this for same-document navigations via the navigation API. My thought about that in particular is that it would probably not belong in CSS, but rather by some sort of JS opt-in that enables CSS navigation-triggered transitions for same-document navigaiton-API navs. It would be awkward if the author had the word cross-document sprinkled all over the CSS, and when we allow same-document navigations they would have to rename everything.

So in short, this is about navigation-triggered view-transitions, where at this point it's enabled only for cross-document.

See the OP for examples.

[fantasai]

+1 to dbaron, I think we need to think about the syntax with these extensions in mind.

Wrt syntax proposals, here's a rough one:

@view-transition {
  navigation: auto;
}

@view-transition {
  navigation: reload;
  type: shimmer;
}

@view-transition {
  from: "/foo/*";
  to: "/bar/*";
  type: slide-out;
}

This is pulling all the selection information into declarations, which gives us a bit more syntax to play with, and will probably make more complicated expressions easier to write.

[css-meeting-bot]

The CSS Working Group just discussed [css-view-transitions-2] Decide on naming for navigation-triggered view-transition rule, and agreed to the following:

• RESOLVED: take the descriptors in the at-rule block

The full IRC log of that discussion

<bramus> noamr: continuation of TPAC convo about opt-in for VT on navigation
<bramus> … we need to name it, and be clear how to extend int he future
<bramus> … also worked with dbaron on this (thanks!)
<bramus> … see the original post for code
<bramus> … VT on navigation can be extended to a few diffferent parts
<bramus> … 1 is name of the feature
<bramus> … i call it “navigation-view-transition”
<bramus> … other one is, if there any nav-performed VT, the way it can be extended is which navs does it supply to?
<bramus> … from article to home?
<bramus> … also type o fnavigation (reload, back, etc)
<bramus> … so that is the first 2 things
<bramus> … other one is “is this nav going to trigger a VT or not?” which is sort of a boolean you could say
<bramus> … we might want to say it is, and then override with MQ (see example)
<bramus> … from article to home it is one, but with a back navigation is off
<bramus> …last thing is to extend for types. you can set a few idents to that classify the transition type and then use that in selectors
<bramus> … elika proposed to also have the conditionals for navigation inside the rule
<bramus> … which is also an option
<bramus> … i think the conditional should b e outside (cfr. media query) but it is debatable
<Rossen_> ack fantasai
<bramus> fantasai: I tweaked the examples in the issue, so reload
<bramus> … given conditioanals can be failry complicated: type, whereto, … – trying to cram that in the at-rule prelude is gnarly
<bramus> … font is kinda a different concept: it is declaring a bunch of props that go together to define a conceptual font
<bramus> … might make sense to take that mental model here
<bramus> … define a transition with type+condition+etc as one package
<bramus> … you end up with a pile of these, and take the last one that matches
<bramus> … in terms of checking for navigation type (fwd, back, etc) is one thing, then there is also a URL-pattern scenario which can be a long list
<emilio> q+
<bramus> … shoving all that in the prelude is going to be a mess I think
<khush> q+
<bramus> astearns: OK, I see the problem you are outlining
<bramus> noamr: proposal is to have a VT but no boolean but to say which navs trigger it and have a from-to and perhaps a list of types
<astearns> s/astearns/Rossen_ /
<bramus> Rossen_: I see
<Rossen_> q?
<bramus> fantasai: that resolves the awkwardness i thiknk
<Rossen_> acm emilio
<bramus> emilio: elika’s proposal sounds elegant. we are fine with not combininig different transition blocks
<bramus> … we need to define an order, but one of them will match
<bramus> fantasai: yeah, they should not cascade into each other
<noamr> q+
<bramus> emilio: if you ahve different types (e.g reload then do this), my understanding was that the types would be added together
<bramus> … with this proposal they would not?
<bramus> fantasai: yeah. if you cascade them together you have a very big complex list.
<bramus> … for navigating from there to here you don’t want to do ???
<bramus> … combining multiple types should be fine (cfr classes); i dont think they should cascade together
<bramus> emilio: sgtm
<Rossen_> ack khush
<Rossen_> ack emilio
<emilio> ack emilio
<bramus> khush: the qualifiers after the at-rule, i wast hinking of them as a pseeudo-class that activates or not and depending on that the at-rule applies
<bramus> … vs things inside the at-rule is what th eauthor is supplying
<bramus> … if from and to are descriptors in the at-rule, is the mental model still the same?
<bramus> … ???
<bramus> fantasai: from grouping at-rules, the conditioanls are on the outside yes
<bramus> … other at-rules less strict, e.g. font-face
<bramus> … the pile of properties that define the thing go in the block
<bramus> … for VT this is something similary: navigation-vt has a bunch of info: url patterns, type of navigation, etc
<bramus> … the UA should figure out which one that matches
<bramus> … from the bottom up (i.e. last one wins)
<emilio> q+
<bramus> khush: sounds like ??? which one matches latst value and apply that. we are thinking the same on this. if i try to read these values in JS, what from value would I read?
<bramus> fantasai: might be nicer to read here: vtRule.from or vtRule.navigation or … i think this is easier as they are individual declarations
<bramus> … they have accessors to each
<bramus> Rossen_: let’s go over qeuue now
<Rossen_> ack noamr
<bramus> noamr: I like the idea, aligning with font-face is probably better than aligning with at-page
<fantasai> s/grouping at-rules/grouping at-rules, which contain style rules inside them,/
<bramus> … i don’t know what the off-value would be. maybe `navigation: none`?
<bramus> … i can see how this would work
<Rossen_> ack dbaron
<bramus> dbaron: im ok with it but want to call out one thing about analogy to font-face
<bramus> … f-f rules are building up a dictionary or library that is then examinded by the font matching algo
<bramus> … (explains)
<bramus> … i am still ok with something that looks like it
<Rossen_> ack emilio
<bramus> emilio: if we go with condition in prelude or inside, we need to decide how complex it would be
<bramus> … for simple conditions the prelude looks simpler, but many conditions seems easier in the block
<bramus> … there could be 4 or 5 conditions
<bramus> q+
<TabAtkins> +1 to emilio. Putting a name, or *one* type of check (a selector, a MQ, etc), in the prelude makes sense. More than that, keep things in the body for better syntax.
<bramus> … i think i prefer fantasai’s proposal
<Rossen_> ack fantasai
<bramus> fantasai: to respond to dbaron: it is a good analogy. most ??? are conditional. the content you are pulling in is the src descriptor. font-style and font-weight are just conditionals. basically doing the same here.
<TabAtkins> (I think @font-face *should* have put its family name in the prelude, but oh well, it was one of our first at-rules and we didn't have a consistent design yet.)
<TabAtkins> s/???/declarations in the block/
<TabAtkins> scribe+
<fantasai> (Yeah, agreed, I'd have put font-family in the prelude also. But anyway...)
<TabAtkins> bramus: If you put it in the prelude, you can most likely nest the various at-rules, which isnt' possible with a big block
<Rossen_> ack bramus
<TabAtkins> bramus: So if you want to change one param you have to duplicate everything and change one value
<bramus> Rossen_: sounds like most ppl are agreeing …
<khush> q+
<bramus> … should we take resolution?
<Rossen_> ack khush
<bramus> khush: fine with going the suggestion by fantasai. would be nice to take 2 separate resolutions: 1/ descriptors in at-rule block, 2/ names of things
<bramus> PROPOSED RESOLUTION: take the descriptors in the at-rule block
<bramus> RESOLVED: take the descriptors in the at-rule block
<bramus> Rossen_: names should be bikeshed?
<bramus> noamr: maybe resolve on current names? navigation: auto | none and the type
<khush> q+
<Rossen_> ack khush
<bramus> khush: `navigation-name` for the nav type? dont thikn we need that righ tnow
<bramus> noamr: idea is we dont have all of them. right now would be a boolean (auto or none) which can be extended in the future
<bramus> khush: rathe rnot name that navigation
<bramus> … (missed)
<bramus> Rossen_: let’s take back to the issue
<bramus> noamr: OK

[khushalsagar]

For the upcoming naming discussion, @noamr clarified the idea on chat. Here it is with the proposed names:

@view-transition {
  navigation: auto;
  type: foo;
}

• @view-transition is the name of the at-rule.
• navigation is the descriptor with the list of navigations that should trigger a transition. The proposed values for now are auto and none. auto means all navigations except reload, aligning with the resolution at [css-view-transitions-2] Should ViewTransitions be triggered for reloads? #8784, and none means no navigations. More navigation types will be introduced going forward.
• type is equivalent to the same parameter in startViewTransition here.